Linuxトラブルシューティング入門｜よくあるエラーと解決手順を実例で解説

「突然サーバーが応答しなくなった」「ディスクが一杯でサービスが停止した」「SSH接続ができなくなった」――Linux環境の運用で、こうしたトラブルに遭遇することは避けられません。問題が発生したとき、冷静に原因を切り分け、適切な手順で解決する力は、IT担当者やエンジニアにとって欠かせないスキルです。

本記事では、Linuxで頻発するトラブルの原因と解決手順を、実例を交えて体系的に解説します。初心者でも対応できるよう、各トラブルについて「症状→原因の特定→解決手順」の流れで説明していきます。

Linuxの基礎がまだ不安な方は、Linuxとは？初心者向け基礎解説を先にご確認ください。

トラブルシューティングの基本アプローチ

Linuxのトラブル対応で最も重要なのは、体系的なアプローチで原因を切り分けることです。闇雲に設定を変更したりサービスを再起動したりすると、問題を悪化させる恐れがあります。

基本的な切り分け手順

1. 症状を正確に把握する: いつから、何が、どう動かないのかを明確にする
2. ログを確認する: 直近のエラーメッセージを調べる
3. 変更履歴を確認する: 直前に何か変更を行ったか確認する
4. 仮説を立てる: ログやエラーメッセージから原因の仮説を立てる
5. 検証する: 仮説を1つずつ検証する（一度に複数の変更を加えない）
6. 記録する: 行った対処と結果を記録する

まず確認すべき5つのコマンド

トラブル発生時にまず実行すべきコマンドを覚えておきましょう。

# 1. システムの稼働状況（CPU負荷、メモリ使用量、稼働時間）
uptime

# 2. ディスク使用量
df -h

# 3. メモリ使用量
free -h

# 4. 直近のシステムログ
sudo journalctl -xe --no-pager | tail -50

# 5. プロセスの状態
top -bn1 | head -20

これらのコマンドの詳細はLinux実践コマンドガイドを参照してください。ログ管理についてはLinuxログ管理ガイドで体系的に解説しています。

ディスク容量不足のトラブルと対処

ディスク容量不足は、Linux環境で最も頻繁に発生するトラブルの一つです。ログの肥大化、一時ファイルの蓄積、アプリケーションの出力データなどが原因となります。

症状

• サービスが起動しない、または異常終了する
• No space left on deviceエラーが発生する
• ファイルの作成や書き込みができない
• パッケージのインストールが失敗する

原因の特定

# パーティションごとの使用量を確認
df -h

# どのディレクトリが容量を消費しているか調査
sudo du -sh /* 2>/dev/null | sort -rh | head -10

# さらに深掘り
sudo du -sh /var/* 2>/dev/null | sort -rh | head -10
sudo du -sh /var/log/* 2>/dev/null | sort -rh | head -10

# 大きなファイルを検索
sudo find / -type f -size +100M 2>/dev/null | head -20

# inode使用率も確認（inode枯渇のケースもある）
df -i

対処手順

# 1. 不要なログの削除
sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-time=7d

# 2. パッケージマネージャーのキャッシュ削除
sudo apt clean
sudo apt autoclean
sudo apt autoremove -y

# 3. 古い一時ファイルの削除
sudo find /tmp -type f -atime +7 -delete

# 4. 古いカーネルの削除（Ubuntu）
sudo apt autoremove --purge -y

# 5. Dockerのイメージ・コンテナのクリーンアップ
docker system prune -af
docker volume prune -f

# 6. 大きなログファイルのローテーション
sudo logrotate -f /etc/logrotate.conf

根本的な対策として、logrotateの適切な設定やディスク使用量の監視・アラート設定を行っておくことが重要です。ディスク管理の詳細はLinuxディスク管理ガイドを参照してください。

プロセス・CPU負荷のトラブルと対処

特定のプロセスがCPUを占有してシステム全体が遅延する問題は、本番環境で深刻な影響をもたらします。

症状

• サーバーの応答が極端に遅い
• SSH接続がタイムアウトする、または極度に遅い
• Webアプリケーションのレスポンスタイムが悪化
• load averageが異常に高い

原因の特定と対処

# ロードアベレージの確認
uptime
# 出力例: load average: 12.50, 10.30, 8.20
# CPUコア数を超えるロードアベレージは高負荷の指標

# CPUコア数の確認
nproc

# CPU使用率の高いプロセスを特定
top -bn1 -o %CPU | head -15

# 特定のプロセスの詳細確認
ps aux | grep プロセス名

# プロセスのCPU使用率を継続的に監視
pidstat -p プロセスID 1 10

# プロセスが何をしているか確認
strace -p プロセスID -c

原因のプロセスが特定できたら、状況に応じて対処します。

# 優先度を下げて影響を軽減（応急処置）
sudo renice 19 -p プロセスID

# CPUコアの割り当てを制限
sudo taskset -cp 0-1 プロセスID

# 安全に停止できる場合
kill プロセスID

# 応答しない場合（強制終了）
kill -9 プロセスID

# ゾンビプロセスの確認と対処
ps aux | grep 'Z'
# 親プロセスを再起動してゾンビを回収

プロセス管理の詳細はLinuxプロセス管理ガイド、パフォーマンス監視はLinuxパフォーマンス監視ガイドで解説しています。

メモリ不足（OOM）のトラブルと対処

メモリ不足はOOM Killer（Out Of Memory Killer）による予期しないプロセス終了を引き起こし、サービス停止の原因となります。

症状

• 特定のプロセスが突然終了する
• システムログにOut of memory: Killed processが記録されている
• システムの応答が極端に遅くなった後にプロセスが消える
• スワップの使用量が急増している

原因の特定

# OOM Killerの発動を確認
sudo dmesg | grep -i "out of memory"
sudo dmesg | grep -i "killed process"
sudo journalctl -k | grep -i "oom"

# 現在のメモリ使用状況
free -h

# プロセスごとのメモリ使用量
ps aux --sort=-%mem | head -15

# メモリ使用量の詳細
cat /proc/meminfo

# スワップの使用状況
swapon --show
cat /proc/swaps

対処手順

# 1. メモリを大量消費しているプロセスの特定と対処
# メモリリークが疑われる場合はプロセスの再起動
sudo systemctl restart 対象サービス

# 2. 不要なプロセスの停止
sudo systemctl stop 不要なサービス
sudo systemctl disable 不要なサービス

# 3. スワップの追加（緊急対応）
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# 永続化（/etc/fstabに追記）
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# 4. OOM Killerの優先度調整（重要なプロセスを保護）
echo -1000 | sudo tee /proc/$(pidof 重要プロセス)/oom_score_adj

# 5. メモリキャッシュの解放（一時的な対処）
sudo sync; echo 3 | sudo tee /proc/sys/vm/drop_caches

長期的な対策として、アプリケーションのメモリ使用量を最適化するか、メモリの増設を検討してください。カーネルパラメータの調整についてはLinuxカーネルチューニング入門も参考になります。

ネットワーク接続のトラブルと対処

ネットワークの問題は「接続できない」「遅い」「不安定」の3パターンに大別されます。それぞれの切り分け方法を解説します。

接続できない場合の切り分け

# 1. ネットワークインターフェースの状態確認
ip addr show
ip link show

# 2. デフォルトゲートウェイの確認
ip route show

# 3. ゲートウェイへの疎通確認
ping -c 3 デフォルトゲートウェイIP

# 4. 外部への疎通確認
ping -c 3 8.8.8.8

# 5. DNS解決の確認
nslookup google.com
dig google.com

# 6. DNS設定の確認
cat /etc/resolv.conf
resolvectl status

# 7. 特定ポートへの接続確認
nc -zv 接続先IP ポート番号
curl -v http://接続先:ポート/

よくある原因と対処

原因1: ネットワークインターフェースがダウンしている

# インターフェースを起動
sudo ip link set eth0 up

# DHCPでIPアドレスを取得
sudo dhclient eth0

# NetworkManagerを使っている場合
sudo nmcli device connect eth0

原因2: ファイアウォールによるブロック

# ufwの状態確認
sudo ufw status verbose

# iptablesのルール確認
sudo iptables -L -n -v

# 一時的にファイアウォールを無効化（テスト用）
sudo ufw disable

# 特定ポートを許可
sudo ufw allow 80/tcp

原因3: DNS解決の失敗

# DNSサーバーを手動で設定
sudo nano /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4

# systemd-resolvedを使っている場合
sudo systemctl restart systemd-resolved

ネットワークコマンドの詳細はLinuxネットワークコマンドを、ファイアウォール設定はLinuxファイアウォール設定ガイドを参照してください。

SSH接続のトラブルと対処

リモートサーバーへのSSH接続トラブルは、業務に直結する重大な問題です。主な原因と対処法を解説します。

接続拒否（Connection refused）

# SSHサービスの状態確認
sudo systemctl status sshd

# SSHが起動していなければ起動
sudo systemctl start sshd
sudo systemctl enable sshd

# SSHのリッスンポート確認
sudo ss -tlnp | grep ssh

# SSH設定ファイルの確認
sudo sshd -t  # 設定のテスト（文法エラーの検出）

認証失敗（Permission denied）

# 秘密鍵のパーミッション確認（600であること）
ls -la ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa

# 公開鍵がサーバーに登録されているか確認
cat ~/.ssh/authorized_keys

# .sshディレクトリのパーミッション確認（700であること）
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

# 認証ログの確認（サーバー側）
sudo tail -f /var/log/auth.log

接続タイムアウト

# サーバーへのネットワーク疎通を確認
ping -c 3 サーバーIP

# SSHポートへの接続を確認
nc -zv サーバーIP 22

# ファイアウォールでSSHが許可されているか
sudo ufw status | grep 22

# 中間のネットワーク機器（ルーター等）の設定を確認
traceroute サーバーIP

SSH接続の詳細な設定方法はLinux SSH接続ガイドで解説しています。パーミッション関連の知識はLinuxファイルパーミッションが参考になります。

サービス起動失敗のトラブルと対処

systemdで管理されているサービスが起動しない問題の対処法です。Nginx、Apache、MySQL、PostgreSQLなど、あらゆるサービスに共通するアプローチです。

原因の特定手順

# 1. サービスのステータス確認
sudo systemctl status サービス名

# 2. 詳細なログの確認
sudo journalctl -u サービス名 --no-pager -n 50

# 3. 設定ファイルのテスト（サービスが対応している場合）
nginx -t                    # Nginxの場合
apachectl configtest        # Apacheの場合
mysqld --validate-config    # MySQLの場合

# 4. ポートの競合を確認
sudo ss -tlnp | grep ポート番号

# 5. パーミッションの確認
ls -la 設定ファイルやデータディレクトリ

# 6. SELinuxの状態確認（RHEL系の場合）
getenforce
sudo ausearch -m avc -ts recent

よくある原因と対処

原因1: 設定ファイルの文法エラー

# 直近の変更を確認（設定のバックアップがある場合）
diff 設定ファイル 設定ファイル.bak

# エラー箇所を修正して再起動
sudo systemctl restart サービス名

原因2: ポートの競合

# 80番ポートを使用しているプロセスを確認
sudo ss -tlnp | grep :80
sudo lsof -i :80

# 競合するプロセスを停止
sudo kill 競合プロセスID
# または
sudo systemctl stop 競合サービス

原因3: パーミッションの問題

# サービスの実行ユーザーを確認
grep 'User=' /etc/systemd/system/サービス名.service

# 必要なディレクトリ・ファイルの所有権を修正
sudo chown -R www-data:www-data /var/www/html
sudo chmod -R 755 /var/www/html

systemdによるサービス管理の詳細はsystemdサービス管理ガイドを参照してください。

トラブル発生を予防するための対策

トラブルを事前に予防する仕組みを構築しておくことが、安定運用の鍵です。

監視とアラートの設定

ディスク容量、メモリ使用量、CPU負荷などの主要メトリクスを監視し、閾値を超えた場合に通知を行う仕組みを整えましょう。

#!/bin/bash
# simple-monitor.sh - シンプルな監視スクリプト

# ディスク使用率の監視
DISK_USAGE=$(df / | awk 'NR==2 {print $5}' | sed 's/%//')
if [ "$DISK_USAGE" -gt 80 ]; then
  echo "WARNING: Disk usage is ${DISK_USAGE}%"
  # メール通知やSlack通知を追加
fi

# メモリ使用率の監視
MEM_USAGE=$(free | awk '/Mem:/ {printf("%.0f"), $3/$2*100}')
if [ "$MEM_USAGE" -gt 90 ]; then
  echo "WARNING: Memory usage is ${MEM_USAGE}%"
fi

# ロードアベレージの監視
LOAD=$(cat /proc/loadavg | awk '{print $1}')
CORES=$(nproc)
if (( $(echo "$LOAD > $CORES * 2" | bc -l) )); then
  echo "WARNING: Load average is $LOAD (cores: $CORES)"
fi

このスクリプトをcronで定期実行することで、簡易的な監視体制を構築できます。定期実行の設定はcron定期実行ガイドを参照してください。

定期バックアップの実施

トラブル発生時に元の状態に復旧できるよう、定期的なバックアップは必須です。

# 設定ファイルのバックアップ
sudo tar czf /backup/etc-$(date +%Y%m%d).tar.gz /etc/

# データベースのバックアップ（MySQLの例）
mysqldump --all-databases > /backup/mysql-$(date +%Y%m%d).sql

# rsyncによる増分バックアップ
rsync -avz --delete /var/www/ /backup/www/

バックアップ戦略の全体像はLinuxバックアップ・リストアガイドで解説しています。

変更管理の徹底

• 設定変更前に必ずバックアップを取る
• 変更内容と理由を記録する
• テスト環境で検証してから本番に適用する
• 変更後の動作確認手順を決めておく
• 問題発生時のロールバック手順を準備しておく

セキュリティ面からのサーバー強化についてはLinuxセキュリティ強化ガイドもご確認ください。

まとめ：体系的なアプローチでトラブルを確実に解決する

Linuxのトラブルシューティングは、焦らず体系的にアプローチすることが最も重要です。本記事のポイントを振り返ります。

• 基本アプローチ: 症状把握→ログ確認→仮説→検証→記録の流れを守る
• ディスク容量: df -hとdu -shで原因を特定し、不要ファイルを削除・ログローテーションを設定
• CPU負荷: topで原因プロセスを特定し、renice/kill/サービス再起動で対処
• メモリ不足: free -hとOOMログで原因を把握し、プロセス最適化やスワップ追加で対応
• ネットワーク: レイヤーごとに切り分け（物理→IP→DNS→アプリケーション）
• SSH接続: サービス状態・ポート・ファイアウォール・認証の順に確認
• サービス起動: systemctl statusとjournalctlでエラーの原因を特定
• 予防: 監視・バックアップ・変更管理の仕組みを事前に整える

トラブル対応のスキルは経験の積み重ねで向上します。日頃からログの見方やパフォーマンス監視に慣れておくことで、いざという時に迅速に対応できるようになります。Linux全般の知識を深めたい方はLinuxとは？初心者向け基礎解説を起点に、関連記事を順に学んでいくことをおすすめします。