Linuxコマンド » Linuxトラブルシューティング総合ハブ｜まず試す簡易対処と詳細ガイド

Linuxトラブルシューティング総合ハブ｜まず試す簡易対処と詳細ガイド

2025.10.03

障害対応は「どこから見るか」を決めておくほど速く、確実になります。

あらかじめ全体像（観測→影響評価→一次対処→恒久対応）を頭に入れ、最初の5分で負荷・ログ・ディスク・ポートだけを確認する型を持てば、多くの不調は迷わず切り分けられます。

Linuxトラブルシューティングの共通手順を押さえておくことは、復旧時間の短縮だけでなく、再発防止策の筋道を早期に描くうえでも有効です。

このページは「まず試す簡易対処」を1画面で示し、必要に応じて詳細ガイドへ自然に進めることを目的にしています。

本記事ではBash環境で実行するLinuxコマンドを使って解説していきます。Bashについての知識に不安がある方は[Bashとは] Linuxコマンド全般についてを網羅している [Linuxコマンド] を参考にしてください。

まず確認：5分で状況把握（top／journalctl／dmesg／df／ss）

障害対応の初動は「広く浅く」。まずは負荷、サービスログ、カーネルメッセージ、ディスク空き、ポート状況の5点だけを一気に確認します。深掘りは後回しにして、いま何が起きているかの当たりをつけることに集中します。

CPUやメモリの偏りは top で即座に把握します。並び替えは o キーでも可能ですが、単発ならオプション指定が速いです。暴走プロセスの有無やロードアベレージの推移を数十秒観察し、異常値かどうかの感覚を掴みます。

top -o %CPU    # CPU使用率で降順表示（必要に応じて -o %MEM）

直近のサービス失敗は journalctl が最短ルートです。時刻を5分に絞ってエラーやワーニングだけを追い、関連ユニット名と発生順をメモします。トレースやExitコードが見えれば、後続の切り分けが一気に楽になります。

journalctl -xe --since "5 minutes ago"

OSレベルの異常は dmesg の末尾で確認します。I/Oエラー、カーネルモジュールの問題、OOM Killerの発動などはアプリ層より先に検知されます。ここで致命的な兆候があれば、アプリの調査より保全を優先します。

dmesg | tail -20

容量逼迫は最短で可視化します。特に /, /var, /var/log の使用率が90％を超えていないかを確認し、逼迫していればログローテーションや一時退避で即応します。

df -h

最後にポートのLISTEN状況を洗い、想定サービスが起動しているか、別プロセスに占有されていないかを確かめます。プロセスIDとコマンド名まで見える表示にして、そのまま原因プロセスへ辿れる形にします。

ss -lntp

この5点を1巡すれば、「高負荷へ進むのか」「Web層かネットワークか」「ディスクか権限か」といった大枠の進路が定まります。より体系だった初動の回し方は、デプロイ直後の確認手順 にまとまっています。

サーバーが重い・遅い：高負荷の最短切り分け

サーバーが「重い」「遅い」と感じたら、最初にどのリソースが詰まっているかを当たり判定します。CPU・メモリ・ディスクI/O・ネットワーク接続のいずれかに偏りがあるケースが大半で、短時間の観測で絞り込みが可能です。

CPU負荷の確認は uptime や top が定番です。ロードアベレージがコア数を大きく超えていれば、プロセスの食い過ぎが疑われます。

uptime
top -o %CPU

メモリの逼迫は vmstat 1 が有効です。フリー領域やスワップ使用状況、ページイン・アウトの数値を追うことで、メモリ不足かどうかが分かります。

vmstat 1

I/O遅延は iostat -x 1 を使います。特定ディスクの %util が常に100％近く張り付いていれば、I/O待ちがボトルネックです。

iostat -x 1

コネクション過多は ss -s で把握します。estab の数やTIME_WAITが極端に多ければ、接続処理に偏りが生じている可能性があります。

ss -s

この4つを順に叩けば、「CPUが飽和しているのか」「メモリ不足なのか」「I/Oが詰まっているのか」「コネクション過多か」が数分で判別できます。深掘りの手順や実例は 高負荷の切り分け にまとめています。

Webが500系を返す：Nginx・PHP-FPM・アプリの所在特定

500エラーが出たときは「どの層で失敗しているか」を順番に切り分けるのが最短ルートです。原因は大きく分けて Nginx、PHP-FPM、アプリケーションコードの3層にあります。アクセスのたびに500が返るのか、特定操作でだけ返るのかも重要なヒントになります。

まずは Nginx のエラーログを確認します。構文エラーやバックエンドへの接続失敗などはここに記録されます。

tail -f /var/log/nginx/error.log

Nginx 側で明確なエラーがなければ、PHP-FPM のユニットログを追います。プロセスの異常終了やリソース不足があればここで検出できます。

journalctl -u php-fpm --since "10 minutes ago"

PHP-FPM に問題が見つからなければ、アプリケーションのエラーログを調べます。たとえば Laravel であれば storage/logs/laravel.log を、WordPress なら wp-content/debug.log を確認し、トレースや未処理例外を探します。

tail -f /path/to/app/logs/error.log

この順番で「Webサーバー → PHPランタイム → アプリ」のどこで止まっているかを押さえれば、余計な切り分けをせずに済みます。さらに再現リクエストを curl -i URL で投げ、レスポンスヘッダや遅延の有無を記録しておくと、後続の調査が効率化します。

レイヤー別の実務的な切り分け手順は 500の所在特定 に詳しく整理しています。

接続できない：ポート競合・別プロセスの占有を解消

「サービスを起動したのにポートが開かない」「接続できない」という場合、多くはポート競合か既存プロセスの占有が原因です。想定したサービスが正しく LISTEN 状態になっているかをまず確認します。

ポートの使用状況を確認するには ss が便利です。

ss -lntp

この出力で、どのポートが LISTEN しているか、そのプロセスIDとコマンド名まで一度に確認できます。想定外のプロセスが 80 番や 443 番を占有していれば、それが原因です。

さらに特定のポートに絞り込む場合は lsof を使います。

lsof -i:80

ここで該当プロセスを特定し、不要なサービスなら停止し、必要なサービスなら設定変更を行います。場合によっては kill -9 PID で強制終了し、正規のサービスを再起動することで解決できます。

競合を解消したら、対象サービスを再起動し、正しくポートが開いているかを再確認します。

systemctl restart nginx
ss -lntp | grep :80

この流れを押さえておけば「接続できない」トラブルの大半は数分で収束します。より整理された手順は ポート競合の解消手順 にまとめています。

空き容量がない：ディスク逼迫（ログ肥大・deletedハンドル）

サーバーで最も多いトラブルのひとつが「ディスクの空き容量が尽きる」ケースです。原因は大きく二つ、ログファイルの肥大化と、削除済みなのにプロセスが握ったまま解放されない deleted ハンドルです。

まずは全体の使用状況を確認します。

df -h

ここで / や /var の使用率が 90% を超えていたら緊急対応が必要です。

次に、どのディレクトリが肥大しているかを探します。

du -sh /var/log/* | sort -h

これで大きなログファイルを特定でき、不要ならログローテーションや圧縮・削除を行います。

容量が戻らない場合は「削除済みだがプロセスが掴んでいるファイル」を疑います。

lsof | grep deleted

ここに大きなファイルサイズが残っていれば、そのプロセスを再起動するまでディスクは解放されません。対象プロセスを特定し、業務影響を見極めたうえで安全に再起動します。

この一連の確認で「ログ肥大」か「deleted ハンドル」かを切り分ければ、空き容量問題は即座に解消できます。さらに詳しい手順は ディスク空きの即確保 にまとめています。

権限で失敗する：所有権・パーミッションの安全修正

「Permission denied」や「Operation not permitted」といったエラーは、所有権やパーミッションの不整合が原因です。闇雲に chmod 777 を当てるのは危険で、動作ユーザーを確認したうえで必要最小限の修正にとどめることが安全です。

まずはプロセスがどのユーザーで動いているかを確認します。

ps -u

あるいはサービスならユニット定義で User= を調べ、実際の実行ユーザーを把握します。

次に対象ファイルやディレクトリの所有権を確認します。

ls -l /var/www/html/index.php

出力のユーザー・グループが、実際に動作しているユーザーと一致していなければ、chown で修正します。

chown www-data:www-data /var/www/html/index.php

パーミッションは「読み・書き・実行」のどれが必要かを考え、最小限で与えます。たとえば PHP ファイルなら実行権限は不要で、640 で十分です。

chmod 640 /var/www/html/index.php

こうした手順を踏めば、権限エラーを無理なく解消でき、セキュリティリスクも最小化できます。詳しい安全適用の流れは chown/chmodの安全適用 に整理されています。

サービスが落ちる：systemdの自動再起動戦略

サービスが繰り返し停止する場合、systemd ユニットの設定を工夫することで復旧の自動化と安定性の両立が可能です。特に Restart と RestartSec、さらにフラッピング防止の StartLimit 系の設定が鍵になります。

最小の雛形は以下のように書けます。

[Unit]
Description=My Service
After=network.target

[Service]
ExecStart=/usr/bin/my-service
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

ここで Restart=on-failure にすることで、異常終了やシグナルで落ちた場合のみ再起動します。RestartSec=5 は再起動間隔を5秒空け、無限ループ的な再起動を避ける効果があります。

さらに連続リスタートを制御するには、ユニットファイルではなく systemd-system.conf またはユニットオーバーライドで以下のように設定します。

StartLimitIntervalSec=60
StartLimitBurst=3

これにより、60秒以内に3回以上落ちた場合は systemd が自動再起動を止め、管理者介入を促します。

このように「落ちたら即座に復旧」しつつ「異常時はフラッピングを防ぐ」設計にすれば、サービスの安定稼働を維持できます。詳細な設計ポイントは systemdユニットの基本と再起動戦略 に整理されています。

ネットが怪しい：DNS→HTTP→経路の順で疎通確認

ネットワークが原因で「つながらない」ときは、DNS・HTTP・経路のどこで止まっているかを順番に切り分けるのが効率的です。名前解決に失敗しているのか、Webサーバーが応答しないのか、あるいは経路途中で詰まっているのかを分けて考えます。

最初に DNS を確認します。

dig example.com

応答がなければ、DNSサーバーの設定や外部のリゾルバ到達性を調べる必要があります。

名前解決ができたら、HTTP レベルの応答を確認します。

curl -I http://example.com

ここで 200 や 302 が返れば Web サーバーは動作しています。500 や 404 が返るならアプリケーション側の問題です。応答がまったく無ければ、ファイアウォールやポート閉塞を疑います。

最後に経路を調べます。

traceroute example.com

途中でタイムアウトする箇所があれば、ネットワーク経路や外部要因の可能性が高いです。

この三段階で「DNS → HTTP → 経路」を順に確認すれば、ネットワーク不調の所在は短時間で特定できます。さらに詳しい切り分けの実例は 疎通確認の基本 を参照してください。

夜間の安全網：バックアップ（tar＋DB＋rsync）の自動化

障害後に復旧できるかどうかは、結局バックアップを取っていたかにかかっています。手動でのコピーでは不十分で、夜間に自動化された仕組みを走らせておくことが安心につながります。最低限でも「設定ファイル」「データベース」「アプリ本体」を押さえ、世代管理と検証まで組み込むのが安全です。

設定ファイルやコードは tar でまとめます。

tar czf /backup/etc-$(date +%F).tar.gz /etc

データベースは mysqldump などで吐き出して保存します。

mysqldump -u root -p mydb > /backup/mydb-$(date +%F).sql

そしてまとめた成果物を別ストレージへ転送するのに rsync が有効です。差分コピーと世代管理を両立でき、回線や時間の節約にもなります。

rsync -avz /backup/ user@remote:/backup/server1/

これらの処理をシェルスクリプトにまとめ、cron に登録して夜間自動実行するのが基本形です。さらに世代数を決めて古いバックアップを削除し、定期的にリストア検証まで回せば「取ったけれど使えない」状況も防げます。

具体的なスクリプト例や設計ポイントは 夜間バックアップの型 に整理されています。

再発を防ぐ：失敗検知のメール／Slack通知

障害が解消しても「気づくのが遅れたために被害が拡大する」ことは少なくありません。再発を防ぐには、失敗を検知して即座に通知する仕組みを入れておくことが重要です。通知があるだけで、復旧までの時間を大幅に短縮できます。

シンプルな方法は、処理の成否を監視スクリプトに組み込み、失敗時にメールを送る形です。

if ! /usr/local/bin/myjob.sh; then
  echo "バッチ処理が失敗しました $(date)" \
  | mail -s "[ALERT] job failed" admin@example.com
fi

メールだけでは気づきにくい環境では、Slack の Incoming Webhook を利用します。Webhook URL を発行しておき、失敗時に curl で POST すれば即座にチャットに通知が飛びます。

if ! /usr/local/bin/myjob.sh; then
  curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"バッチ処理が失敗しました"}' \
  https://hooks.slack.com/services/XXXX/XXXX/XXXX
fi

ここで大切なのは「どんな閾値で通知するか」「どの頻度で通知するか」「誰に通知するか」を事前に設計しておくことです。些細な警告を乱発すると通知疲れを起こし、逆に肝心なアラートを見逃す恐れがあります。

実務にすぐ展開できるテンプレートや具体例は 失敗検知の定型化 にまとめています。

まとめ

Linux の障害対応は「最初の5分で広く状況を把握し、その後に深掘りする」型を持つことで、大半のトラブルを迷わず収束へ導けます。負荷・ログ・ディスク・ポートといった共通チェックから入り、症状ごとに詳細ガイドへ進むのが最短ルートです。

体系だった流れは デプロイ直後の確認手順 から確認できます。

再発防止にはバックアップや通知設計まで含めた運用が欠かせません。気になる症状があれば、各「詳細ガイド」へ進み、実機にあわせて展開してください。

内部リンク

参考リンク