こんにちは、かつコーチです。
サーバーを運用していると、大なり小なり必ずエラーに遭遇します。
「エラーメッセージは出ているけど、何をどう調べればいいか分からない」という状態は、初中級者がもっともつまずきやすいポイントです。
この記事では、Linuxサーバーでよく発生するエラーのパターンと、原因を突き止めるためのトラブルシューティングの考え方を解説します。
検証環境はUbuntu 26.04 LTSです。
トラブルシューティングとは？
トラブルシューティングの定義
トラブルシューティングとは、発生した問題（エラーや不具合）に対して、原因を特定し解決に導く一連の作業のことです。
やみくもに設定を変更するのではなく、「何が起きているか」「なぜ起きているか」を順序立てて調べていく姿勢が重要です。
なぜ体系立てた手順が必要なのか
初心者のうちは、エラーが出るとすぐに検索して見つけた解決策をそのまま試しがちです。
しかし原因を理解しないまま対処すると、次のような問題が起きます。
- 一時的に直っても、根本原因が残ったまま再発する
- 検索結果の解決策が、自分の環境には当てはまらないこともある
- どこで何を変更したか分からなくなり、余計に状況を悪化させる
L22で紹介したログの確認と組み合わせ、「症状の確認→原因の切り分け→対処→検証」という流れを意識することが、遠回りのようで実は一番の近道です。
基本の調査手順
手順1：エラーメッセージを正確に読む
まず最初にやるべきことは、エラーメッセージを最後まで正確に読むことです。
$ sudo systemctl start myapp
Job for myapp.service failed because the control process exited with error code.
See "systemctl status myapp.service" and "journalctl -xeu myapp.service" for details.
エラーメッセージ自体が、次に何を確認すべきかを教えてくれていることがほとんどです。
「サービスが失敗した」ことだけでなく、「systemctl statusやjournalctlを見ろ」という指示まで読み取ります。
手順2：ステータスとログで詳細を確認する
L17のsystemdとL22のjournalctlを組み合わせて、詳しい原因を探ります。
$ sudo systemctl status myapp.service
● myapp.service - My Application
Loaded: loaded (/etc/systemd/system/myapp.service; enabled)
Active: failed (Result: exit-code) since Tue 2026-09-01 10:15:03 JST
Process: 4021 ExecStart=/usr/bin/myapp (code=exited, status=1/FAILURE)
$ journalctl -u myapp.service -n 50
Sep 01 10:15:03 web01 myapp[4021]: Error: cannot connect to database at 127.0.0.1:5432
このケースでは「データベースに接続できない」という具体的な原因までログから特定できました。
手順3：切り分けを行う
原因の候補が複数ある場合は、1つずつ切り分けて調査します。
# データベース自体が起動しているか確認
$ sudo systemctl status postgresql
# ポートが実際にリッスンしているか確認
$ sudo ss -tlnp | grep 5432
# ネットワークとして到達できるか確認
$ nc -zv 127.0.0.1 5432
「アプリの設定が間違っているのか」「データベース自体が落ちているのか」「ネットワークが遮断されているのか」を1つずつ確認していくことで、原因の範囲を絞り込めます。
手順4：対処後は必ず再現確認する
原因が分かって対処したら、最後に必ず「同じ操作をもう一度行っても問題が起きないか」を確認します。
$ sudo systemctl restart myapp
$ sudo systemctl status myapp
● myapp.service - My Application
Active: active (running) since Tue 2026-09-01 10:30:12 JST
対処して終わりではなく、正常な状態が再現できることまで確認して初めてトラブルシューティングは完了です。
よくあるエラーパターンと対処
Connection refused（サービスが起動していない）
Webサーバーへのアクセス時によく見るエラーです。
❌ Before
$ curl http://localhost:80
curl: (7) Failed to connect to localhost port 80: Connection refused
私が実際にnginxのインストール直後にこのエラーに遭遇したとき、サービス自体が起動していないことが原因でした。
$ sudo systemctl status nginx
● nginx.service - A high performance web server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled)
Active: inactive (dead)
✅ After
$ sudo systemctl start nginx
$ sudo systemctl enable nginx
$ curl http://localhost:80
<!DOCTYPE html>
<html>
<head><title>Welcome to nginx!</title></head>
Connection refusedは「そのポートで待ち受けているプロセスが存在しない」ことを示すエラーです。
インストール後に自動起動しない設定になっていることもあるため、systemctl enableまで忘れずに行うようにしています。
No space left on device（ディスク容量不足）
ログの肥大化などでディスクが埋まると発生するエラーです。
❌ Before
$ sudo apt install nginx
E: Write error - write (28: No space left on device)
df -hでディスク使用状況を確認したところ、ルートパーティションの使用率が100%になっていました。
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 20G 20G 0 100% /
✅ After
# 容量を圧迫しているディレクトリを特定する
$ sudo du -sh /var/log/* | sort -rh | head -5
2.1G /var/log/journal
# journalのログを縮小する
$ sudo journalctl --vacuum-size=200M
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 20G 18G 2.0G 90% /
du -shで容量を食っているディレクトリを特定し、L22で紹介したjournalctl --vacuum-sizeで不要なログを削減して復旧しました。
ディスク容量不足は気づきにくく突然サービス停止につながるため、定期的なdf -hの確認が有効です。
Address already in use（ポートの重複）
サービスを再起動しようとした際によく見るエラーです。
❌ Before
$ sudo systemctl restart myapp
$ journalctl -u myapp -n 10
Sep 01 11:02:10 web01 myapp[5210]: Error: bind: address already in use
同じポート番号を、別のプロセスがすでに使用していることが原因でした。
✅ After
# ポート8080を使っているプロセスを特定する
$ sudo ss -tlnp | grep 8080
LISTEN 0 128 0.0.0.0:8080 0.0.0.0:* users:(("myapp",pid=4890,fd=6))
# 古いプロセスをkillしてから再起動する
$ sudo kill 4890
$ sudo systemctl restart myapp
ss -tlnpでポートを使用しているプロセスIDを特定し、L16で紹介したkillで該当プロセスを終了させてから再起動すると解決しました。
前回の起動プロセスが正しく終了せず残っていたことが根本原因でした。
応用・一歩先の使い方
エラー調査を記録に残す習慣
同じようなエラーは、時間を置いて再発することがよくあります。
調査した内容と対処法を、簡単なメモとして残しておくと、次に同じエラーに遭遇したときの解決速度が大きく変わります。
# 例：トラブルシューティングのメモを残す運用
$ echo "2026-09-01: nginx起動失敗、原因はenable忘れ" >> ~/troubleshooting-log.md
チームで運用している場合は、社内Wikiやissueにまとめておくと、他のメンバーの調査時間も短縮できます。
監視ツールで事前に気づけるようにする
ここまでは「起きてから調べる」対処でしたが、ディスク容量やサービスの死活監視をあらかじめ仕組み化しておくと、障害が発生する前に気づけます。
systemdの標準機能や、Zabbix・Prometheusのような監視ツールと組み合わせる運用が本番環境では一般的です。
まずはdf -hやsystemctl statusを定期的にチェックするcronジョブを組むところから始めてもよいでしょう。
まとめ
この記事のポイント
- トラブルシューティングは「症状の確認→原因の切り分け→対処→検証」の順で進める
- エラーメッセージには次に確認すべき手がかりが含まれていることが多い
Connection refusedはサービス未起動、No space left on deviceはディスク容量不足、Address already in useはポート重複が典型的な原因ss -tlnpやdu -shなど、原因特定に使うコマンドの引き出しを増やしておく- 調査結果を記録に残すと、同じエラーの再発時に対応が早くなる
次に読むべき記事
- L22「ログファイルの見方（/var/log、journalctl）」でログ確認の基本を押さえる
- L16「ジョブ管理（fg・bg・kill）とシグナルの基本」でプロセスの終了方法を学ぶ
- L24「環境変数とPATHの仕組み」で設定まわりのつまずきをさらに減らす
タグ: #Linux #中級者向け #トラブルシューティング