linux-troubleshooting
Diagnostic et résolution des problèmes système Linux
Les administrateurs Linux sont confrontés à des pannes système complexes nécessitant un diagnostic structuré. Ce workflow offre une approche en sept phases pour identifier systématiquement les causes racines et implémenter des corrections vérifiées.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "linux-troubleshooting". Le serveur fonctionne lentement. Commencez le dépannage.
Résultat attendu:
- Phase 1 - Évaluation initiale terminée :
- - Temps de disponibilité système : 45 jours
- - OS : Ubuntu 22.04 LTS
- - Mise à jour récente du noyau détectée dans dmesg
- Phase 2 - Analyse des ressources :
- - CPU : 95% d'utilisation par le processus java (PID 4521)
- - Mémoire : 7,8 Go/8 Go utilisés, forte activité de swap
- - Disque : /var à 92% de capacité
- Action recommandée : Enquêter sur la fuite de mémoire du processus Java et libérer de l'espace disque dans /var/log
Utilisation de "linux-troubleshooting". Le service nginx n'a pas démarré après modification de la configuration
Résultat attendu:
- Résultats de la Phase 6 - Dépannage des services :
- - systemctl status nginx : Échec avec code de sortie 1
- - journalctl -u nginx : 'nginx: [emerg] unknown directive' à la ligne 47
- - Test de configuration : nginx -t montre une erreur de syntaxe dans /etc/nginx/sites-enabled/default
- Cause racine : Directive invalide introduite dans la modification récente de la configuration
- Correction : Restaurer la configuration précédente à partir de la sauvegarde et recharger nginx
Audit de sécurité
SûrAll 47 static analysis findings are false positives. The SKILL.md file is documentation-only (markdown) containing workflow instructions and example commands. The detected 'backtick execution' patterns are markdown code fence markers (```bash), not Ruby/shell backticks. The 'hardcoded URL' and 'reconnaissance' patterns are documented examples for users, not executable code. No actual security risks detected.
Problèmes à risque faible (1)
Facteurs de risque
⚙️ Commandes externes (6)
Score de qualité
Ce que vous pouvez construire
Réponse aux pannes de serveur de production
Suivez le workflow en sept phases pour diagnostiquer pourquoi un serveur de production est devenu sans réponse, identifier la cause racine (épuisement des ressources, défaillance de service ou problème réseau) et implémenter une correction vérifiée.
Investigation de la dégradation des performances
Utilisez les phases d'analyse des ressources et d'investigation des processus pour identifier quels processus consomment un excès de CPU ou de mémoire, puis travaillez avec la compétence server-management pour résoudre le problème.
Diagnostic des défaillances de service
Appliquez la phase de dépannage des services pour diagnostiquer pourquoi les services systemd échouent à démarrer, examinez les journaux avec la compétence error-detective et implémentez les corrections de configuration.
Essayez ces prompts
Utilisez le workflow linux-troubleshooting pour vérifier l'état du système. Commencez par la Phase 1 (Évaluation initiale) et la Phase 2 (Analyse des ressources). Exécutez uptime, vérifiez l'utilisation du CPU et de la mémoire avec top et free, et rapportez l'espace disque avec df -h.
Un service critique échoue à démarrer. Suivez la Phase 6 (Dépannage des services) pour vérifier systemctl status, examinez les journaux avec journalctl -u service -f, et identifiez les problèmes de configuration. Utilisez ensuite la Phase 4 (Analyse des journaux) pour rechercher les erreurs connexes dans /var/log/.
Les utilisateurs ne peuvent pas atteindre notre serveur web. Exécutez la Phase 5 (Diagnostics réseau) pour vérifier les interfaces réseau avec ip addr, vérifier les ports d'écoute avec ss -tulpn, tester la connectivité avec curl, et vérifier la résolution DNS avec dig. Corrélez les résultats avec les règles du pare-feu.
Le serveur de production rencontre des problèmes critiques. Exécutez le workflow linux-troubleshooting complet en sept phases : (1) Évaluation initiale, (2) Analyse des ressources, (3) Investigation des processus, (4) Analyse des journaux, (5) Diagnostics réseau, (6) Dépannage des services, (7) Résolution. Documentez les résultats à chaque phase et implémentez des corrections vérifiées.
Bonnes pratiques
- Documentez toujours les résultats à chaque phase avant de passer à la suivante
- Vérifiez les corrections en réexécutant les commandes de diagnostic pour confirmer la résolution
- Créez des plans de prévention après la résolution pour éviter les problèmes récurrents
Éviter
- Passer des phases et sauter directement aux redémarrages sans diagnostiquer la cause racine
- Implémenter des corrections sans d'abord vérifier la cause racine identifiée
- Ne pas surveiller la stabilité du système après avoir appliqué la résolution