linux-troubleshooting
Linuxシステム問題の診断と解決
Linux管理者は複雑なシステム障害に直面し、構造化された診断が必要です。このワークフローは、根本原因を体系的に特定し、検証済みの修正を実装するための7段階アプローチを提供します。
スキルZIPをダウンロード
Claudeでアップロード
設定 → 機能 → スキル → スキルをアップロードへ移動
オンにして利用開始
テストする
「linux-troubleshooting」を使用しています。 Server is running slowly. Start troubleshooting.
期待される結果:
- Phase 1 - Initial Assessment Complete:
- - System uptime: 45 days
- - OS: Ubuntu 22.04 LTS
- - Recent kernel update detected in dmesg
- Phase 2 - Resource Analysis:
- - CPU: 95% usage by process java (PID 4521)
- - Memory: 7.8GB/8GB used, heavy swap activity
- - Disk: /var at 92% capacity
- Recommended action: Investigate Java process memory leak and clear disk space in /var/log
「linux-troubleshooting」を使用しています。 nginx service failed to start after config change
期待される結果:
- Phase 6 - Service Troubleshooting Results:
- - systemctl status nginx: Failed with exit code 1
- - journalctl -u nginx: 'nginx: [emerg] unknown directive' at line 47
- - Configuration test: nginx -t shows syntax error in /etc/nginx/sites-enabled/default
- Root cause: Invalid directive introduced in recent config edit
- Fix: Restore previous config from backup and reload nginx
セキュリティ監査
安全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)
リスク要因
品質スコア
作れるもの
本番サーバー障害対応
7段階のワークフローに従って、本番サーバーが応答しなくなった根本原因を特定し（リソース枯渇、サービス障害、またはネットワーク問題）、検証済みの修正を実装します。
パフォーマンス低下の調査
リソース分析とプロセス調査フェーズを使用して、過度にCPUやメモリを消費しているプロセスを特定し、サーバー管理スキルと協力して問題を解決します。
サービス障害の診断
サービストラブルシューティングフェーズを適用してsystemdサービスが起動しない理由を診断し、error-detectiveスキルでログを確認し、設定の問題を修正します。
これらのプロンプトを試す
Use the linux-troubleshooting workflow to check system health. Start with Phase 1 (Initial Assessment) and Phase 2 (Resource Analysis). Run uptime, check CPU and memory usage with top and free, and report disk space with df -h.
A critical service is failing to start. Follow Phase 6 (Service Troubleshooting) to check systemctl status, review logs with journalctl -u service -f, and identify configuration issues. Then use Phase 4 (Log Analysis) to search for related errors in /var/log/.
Users cannot reach our web server. Execute Phase 5 (Network Diagnostics) to check network interfaces with ip addr, verify listening ports with ss -tulpn, test connectivity with curl, and check DNS resolution with dig. Correlate findings with firewall rules.
Production server is experiencing critical issues. Run the complete seven-phase linux-troubleshooting workflow: (1) Initial Assessment, (2) Resource Analysis, (3) Process Investigation, (4) Log Analysis, (5) Network Diagnostics, (6) Service Troubleshooting, (7) Resolution. Document findings at each phase and implement verified fixes.
ベストプラクティス
- 次のフェーズに進む前に、各フェーズの発見事項を常に文書化してください
- 修正を検証するために診断コマンドを再実行して解決を確認してください
- 解決後に予防計画を作成して問題の再発を防止してください
回避
- 根本原因を診断せずにフェーズをスキップして直接再起動する
- 特定した根本原因を最初に確認せずに修正を実装する
- 解決を適用した後、システム安定性を監視しない