Fähigkeiten linux-troubleshooting
🖥️

linux-troubleshooting

Sicher ⚙️ Externe Befehle

Linux-Systemprobleme diagnostizieren und beheben

Linux-Administratoren sehen sich komplexen Systemausfällen gegenüber, die eine strukturierte Diagnose erfordern. Dieser Workflow bietet einen siebenphasigen Ansatz zur systematischen Identifizierung von Grundursachen und Implementierung verifizierter Lösungen.

Unterstützt: Claude Codex Code(CC)
📊 70 Angemessen
1

Die Skill-ZIP herunterladen

2

In Claude hochladen

Gehe zu Einstellungen → Fähigkeiten → Skills → Skill hochladen

3

Einschalten und loslegen

Teste es

Verwendung von "linux-troubleshooting". Server läuft langsam. Fehlerbehebung starten.

Erwartetes Ergebnis:

  • Phase 1 - Erstbewertung abgeschlossen:
  • - System-Laufzeit: 45 Tage
  • - OS: Ubuntu 22.04 LTS
  • - Recent kernel update detected in dmesg
  • Phase 2 - Ressourcenanalyse:
  • - CPU: 95% Auslastung durch Prozess java (PID 4521)
  • - Speicher: 7,8GB/8GB verwendet, starke Swap-Aktivität
  • - Festplatte: /var bei 92% Kapazität
  • Empfohlene Aktion: Java-Prozess-Speicherleck untersuchen und Festplattenspeicher in /var/log bereinigen

Verwendung von "linux-troubleshooting". nginx-Service konnte nach Konfigurationsänderung nicht starten

Erwartetes Ergebnis:

  • Phase 6 - Ergebnisse der Service-Fehlerbehebung:
  • - systemctl status nginx: Fehlgeschlagen mit Exit-Code 1
  • - journalctl -u nginx: 'nginx: [emerg] unknown directive' in Zeile 47
  • - Konfigurationstest: nginx -t zeigt Syntaxfehler in /etc/nginx/sites-enabled/default
  • Grundursache: Ungültige Direktive durch recente Konfigurationsbearbeitung eingeführt
  • Lösung: Vorherige Konfiguration aus Backup wiederherstellen und nginx neu laden

Sicherheitsaudit

Sicher
v1 • 2/25/2026

All 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.

1
Gescannte Dateien
222
Analysierte Zeilen
2
befunde
1
Gesamtzahl Audits
Probleme mit niedrigem Risiko (1)
SKILL.md:42-47SKILL.md:68-73
Documentation Contains Shell Command Examples
The skill documentation includes example shell commands for system diagnostics (uptime, top, df, journalctl, etc.). These are intended for user execution via other skills, not direct code execution by this skill.

Risikofaktoren

⚙️ Externe Befehle (6)
SKILL.md:42-47 SKILL.md:68-73 SKILL.md:94-99 SKILL.md:120-124 SKILL.md:145-150 SKILL.md:171-175
Auditiert von: claude

Qualitätsbewertung

38
Architektur
100
Wartbarkeit
87
Inhalt
32
Community
100
Sicherheit
83
Spezifikationskonformität

Was du bauen kannst

Reaktion auf Produktionsserver-Ausfall

Folgen Sie dem siebenphasigen Workflow zur Diagnose, warum ein Produktionsserver nicht reagiert hat, identifizieren Sie die Grundursache (Ressourcenerschöpfung, Service-Ausfall oder Netzwerkproblem) und implementieren Sie eine verifizierte Lösung.

Untersuchung von Leistungsverschlechterung

Verwenden Sie die Phasen Ressourcenanalyse und Prozessuntersuchung, um zu identifizieren, welche Prozesse übermäßige CPU- oder Speicherauslastung verursachen, und arbeiten Sie dann mit dem server-management-Skill zur Lösung des Problems.

Diagnose von Service-Ausfällen

Wenden Sie die Phase Service-Fehlerbehebung an, um zu diagnostizieren, warum systemd-Services nicht starten, überprüfen Sie Logs mit dem error-detective-Skill und implementieren Sie Konfigurationskorrekturen.

Probiere diese Prompts

Grundlegender System-Gesundheitscheck 
Verwenden Sie den linux-troubleshooting-Workflow zur Überprüfung der Systemgesundheit. Beginnen Sie mit Phase 1 (Erstbewertung) und Phase 2 (Ressourcenanalyse). Führen Sie uptime aus, überprüfen Sie CPU- und Speichernutzung mit top und free, und melden Sie den Festplattenspeicher mit df -h.
Service startet nicht 
Ein kritischer Service startet nicht. Folgen Sie Phase 6 (Service-Fehlerbehebung), um systemctl status zu überprüfen, Logs mit journalctl -u service -f zu prüfen und Konfigurationsprobleme zu identifizieren. Verwenden Sie dann Phase 4 (Log-Analyse), um nach verwandten Fehlern in /var/log/ zu suchen.
Netzwerk-Konnektivitätsprobleme 
Benutzer können unseren Webserver nicht erreichen. Führen Sie Phase 5 (Netzwerkdiagnose) aus, um Netzwerkschnittstellen mit ip addr zu überprüfen, lauschende Ports mit ss -tulpn zu verifizieren, Konnektivität mit curl zu testen und DNS-Auflösung mit dig zu prüfen. Korrelieren Sie Erkenntnisse mit Firewall-Regeln.
Vollständige Incident-Response 
Produktionsserver verzeichnet kritische Probleme. Führen Sie den kompletten siebenphasigen linux-troubleshooting-Workflow aus: (1) Erstbewertung, (2) Ressourcenanalyse, (3) Prozessuntersuchung, (4) Log-Analyse, (5) Netzwerkdiagnose, (6) Service-Fehlerbehebung, (7) Lösung. Dokumentieren Sie Erkenntnisse in jeder Phase und implementieren Sie verifizierte Korrekturen.

Bewährte Verfahren

  • Dokumentieren Sie stets die Erkenntnisse jeder Phase, bevor Sie zur nächsten übergehen
  • Verifizieren Sie Korrekturen durch erneutes Ausführen der Diagnosebefehle zur Bestätigung der Lösung
  • Erstellen Sie nach der Lösung Präventionspläne, um wiederkehrende Probleme zu vermeiden

Vermeiden

  • Überspringen von Phasen und direktes Springen zu Neustarts ohne Diagnose der Grundursache
  • Implementieren von Korrekturen ohne vorherige Verifizierung der identifizierten Grundursache
  • Unterlassen der Überwachung der Systemstabilität nach Anwendung der Lösung

Häufig gestellte Fragen

Welche Skills benötige ich für diesen Workflow?
Dieser Workflow koordiniert mit bash-linux zur Befehlsausführung, performance-engineer zur Ressourcenanalyse, server-management für Prozess- und Service-Management, error-detective zur Log-Analyse und network-engineer für Netzwerkdiagnose. Jede Phase spezifiziert, welche Skills aufgerufen werden sollen.
Kann dieser Workflow Probleme automatisch beheben?
Nein, dies ist ein strukturierter Workflow-Leitfaden. Er bietet systematische Diagnoseschritte und koordiniert mit anderen Skills zur Befehlsausführung. Alle Korrekturen erfordern die Zustimmung des Benutzers vor der Implementierung.
Was ist, wenn ich nur einen bestimmten Bereich überprüfen möchte?
Sie können einzelne Phasen unabhängig voneinander ausführen. Führen Sie beispielsweise nur Phase 5 für Netzwerkprobleme oder Phase 4 für Log-Analyse aus. Der Workflow ist modular und jede Phase ist in sich abgeschlossen.
Wie dokumentiere ich den Fehlerbehebungsprozess?
Phase 1 umfasst das Sammeln erster Erkenntnisse und Phase 7 das Erstellen einer Lösungsdokumentation. Jede Phase enthält einen Schritt 'Erkenntnisse dokumentieren'. Der Workflow ermutigt zur Führung eines Fehlerbehebungs-Logs während des gesamten Prozesses.
Welche Berechtigungen benötige ich für diese Diagnosen?
Die meisten Diagnosebefehle (top, df, ss) funktionieren mit Standard-Benutzerberechtigungen. Einige Befehle wie journalctl -xe, strace und Service-Management erfordern sudo/Root-Zugriff. Stellen Sie sicher, dass Ihre Claude Code-Sitzung über entsprechende Systemberechtigungen verfügt.
Kann ich diesen Workflow für containerisierte Umgebungen verwenden?
Ja, aber einige Befehle können sich in Containern unterschiedlich verhalten. Befehle wie systemctl funktionieren möglicherweise nicht in Containern ohne systemd. Passen Sie den Workflow an, indem Sie containerspezifische Alternativen verwenden (docker top, docker logs), wo anwendbar.

Entwicklerdetails

Autor

sickn33

Lizenz

MIT

Repository

https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/linux-troubleshooting

Ref

main

Dateistruktur

📄 SKILL.md