AlmaLinux自宅サーバーのトラブル対応集｜ログ解析と復旧手順

運営：リナックスマスター.JP（代表 宮崎智広）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ Linuxtips ＞ AlmaLinux自宅サーバーのトラブル対応集｜ログ解析と復旧手順
自宅で稼働させているAlmaLinuxサーバーが突然つながらなくなった、サービスが起動しない、ディスクがいっぱいになった。そんなトラブルに直面したとき、どこから調査すれば原因にたどり着けるのか。

この記事では、AlmaLinux 9系～10系を想定環境として、自宅サーバー運用で発生しやすいトラブルの診断から復旧までの手順を解説します。ログ解析（journalctl・dmesg）を起点に、ネットワーク障害・サービス起動失敗・ディスク不足・SELinux拒否の確認と対処法を体系的にまとめています。

この記事のポイント

・トラブル調査の起点は journalctl -xe と dmesg の2コマンド
・ネットワーク疎通不可はfirewalld→SELinux→ルーティングの順で確認する
・サービス起動失敗は systemctl status でエラー行を直接確認できる
・ディスク不足は df→du→journald の上限設定の順で絞り込む


「このままじゃマズい」と感じていませんか？
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

AlmaLinux自宅サーバーで多いトラブルの全体像

AlmaLinuxは企業での利用を想定したRHELクローンのため、自宅サーバー用途では設定の初期状態が「セキュリティ優先」になっている。そのため、Ubuntu Serverやラズパイ環境に慣れたユーザーが移ってくると、最初の壁としてよく挙がるのが次の4パターンだ。

・ネットワーク疎通不可：firewalldのデフォルト設定でSSH以外のポートが閉じている
・サービス起動失敗：SELinuxのコンテキストミスやユニットファイルの誤記
・ディスク容量不足：journaldやWebサーバーのログが静かに肥大化している
・起動不能・起動遅延：ネットワーク待機やfailed unitが積み重なってタイムアウト

これらに共通するのは、「ログを読む」という基本動作が解決の糸口になる点だ。まずログ解析の手順を押さえておきたい。

ログ解析の基本｜journalctlとdmesgの使い方

1. journalctlでサービスエラーを調べる

systemdベースのAlmaLinuxでは、ほぼすべてのサービスログがjournaldに集約されている。起動直後に何が失敗したかは journalctl -xe で確認するのが最速だ。

# 最新のエラーを優先度付きで表示（-x: 補足説明付き、-e: 末尾から表示）
journalctl -xe

# 特定サービスのログのみ絞り込む
journalctl -u httpd.service

# 直近1時間のログを表示
journalctl --since "1 hour ago"

# 起動失敗したユニット一覧を確認する
systemctl --failed
出力例（環境により異なります）:

Nov 02 09:15:32 myserver systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE
Nov 02 09:15:32 myserver systemd[1]: Failed to start The Apache HTTP Server.
「Failed to start」の行が出た場合、同じ出力の前後数行に具体的なエラー内容（設定ファイルの構文エラーやSELinuxのAVCメッセージなど）が出ていることが多い。落ち着いてスクロールして確認しよう。

2. dmesgでカーネル・ハードウェアのログを確認する

dmesgはカーネルレベルのメッセージを表示するコマンドだ。ハードウェア障害（ディスクエラー、メモリエラー）やネットワークドライバの問題は、journalctlより先にdmesgに現れることが多い。

# 最新のカーネルメッセージを表示（-T: 人間が読める時刻形式）
dmesg -T | tail -50

# エラー・警告だけを絞り込む
dmesg -T --level=err,warn

# ディスクエラーが疑われる場合
dmesg -T | grep -i 'error\|fail\|sda\|sdb\|nvme'
出力例（環境により異なります）:

[Nov 2 09:10:05] ata1.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[Nov 2 09:10:05] ata1.00: failed command: READ FPDMA QUEUED
[Nov 2 09:10:05] sd 0:0:0:0: [sda] FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
上のような出力が出た場合、ディスクの物理障害が疑われる。続けて smartctl -a /dev/sda（smartmontools パッケージが必要）で S.M.A.R.T. 情報を確認し、Reallocated Sectors や Pending Sectors が増加していないかチェックするとよい。

3. /var/log配下のサービス個別ログも確認する

Apache・Nginx・MySQL など一部のサービスは journald に加えて /var/log 配下にも独自のログを書き出す。systemd-journald の設定によってはログが揮発（再起動で消える）することもあるため、/var/log のファイルも確認しておきたい。

# Apacheのエラーログ
tail -100 /var/log/httpd/error_log

# MySQLのエラーログ
tail -100 /var/log/mysqld.log

# 認証失敗（不正アクセス試行）を確認
grep "Failed password" /var/log/secure | tail -20

ネットワーク疎通が取れない時の診断手順

1. IPアドレスとルーティングを確認する

まず自分自身のIPアドレスが正しく設定されているか確認する。

# IPアドレスとインターフェース状態を確認
ip addr show

# ルーティングテーブルを確認（デフォルトゲートウェイが設定されているか）
ip route show

# ゲートウェイへの疎通確認
ping -c 3 192.168.1.1

# DNSの名前解決を確認
dig www.google.com
IPは取得できているのにサービスに接続できない場合は、次のfirewalld設定を確認する。ポートが開いているかどうかは ss コマンドで確認できる（Linux ポート確認の全コマンドも参考にしてほしい）。

# LISTEN状態のポートを確認する
ss -tlnp

# 出力例（環境により異なります）
# State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
# LISTEN  0       128     0.0.0.0:22         0.0.0.0:*          users:(("sshd",pid=1234,fd=4))
# LISTEN  0       511     0.0.0.0:80         0.0.0.0:*          users:(("httpd",pid=2345,fd=4))

2. firewalldのポート設定を確認する

AlmaLinuxはデフォルトでfirewalldが有効になっており、多くのポートが閉じた状態だ。外部から接続できないトラブルの大半はここが原因になる。

# 現在の設定を確認する（アクティブゾーンと許可サービス・ポート）
firewall-cmd --list-all

# 特定ポートが許可されているか確認
firewall-cmd --query-port=8080/tcp

# ポートを一時的に開放（--permanent を付けると永続化）
sudo firewall-cmd --add-port=8080/tcp --permanent
sudo firewall-cmd --reload

# サービス名で許可する（例：httpd）
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --reload

3. SELinuxの拒否ログを確認する

firewalldを設定してもまだつながらない場合は、SELinuxが通信をブロックしている可能性がある。SELinuxのdenialログは /var/log/audit/audit.log に記録される。

# SELinuxの状態を確認（Enforcing=有効、Permissive=警告のみ）
getenforce

# 直近のSELinux拒否ログを確認
sudo grep "denied" /var/log/audit/audit.log | tail -20

# audit2whyでわかりやすく翻訳する（setroubleshoothパッケージが必要）
sudo grep "denied" /var/log/audit/audit.log | audit2why

# 一時的にPermissiveモードに切り替えて原因を切り分ける
sudo setenforce 0
# ※テスト後は必ず Enforcing に戻す
sudo setenforce 1
出力例（環境により異なります）:

type=AVC msg=audit(1730549832.123:456): avc: denied { name_connect } for pid=5678
comm="httpd" dest=3306 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:mysqld_port_t:s0 tclass=tcp_socket permissive=0
この出力はApache(httpd)がMySQL(3306番ポート)へ接続しようとしたがSELinuxに拒否されたことを示している。解決策は setsebool -P httpd_can_network_connect_db 1 でブール値を有効化する方法だ。

自宅サーバーでのLinux運用スキルを体系的に学びたい方は、Linux Master Pro Seminarでハンズオン形式でトラブルシューティングの実践的な「型」を習得する方法もある。

サービスが起動しない時の対処法

1. systemctl statusでエラーを確認する

サービスが起動しない場合、まず systemctl status でエラーメッセージを確認する。

# サービスの状態と直近ログを確認
systemctl status httpd.service

# 設定ファイルの構文チェック（Apacheの場合）
sudo apachectl configtest

# サービスの再起動
sudo systemctl restart httpd.service

# 自動起動の設定（再起動後も有効にする）
sudo systemctl enable httpd.service
出力例（環境により異なります）:

* httpd.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; preset: disabled)
     Active: failed (Result: exit-code) since Sun 2026-11-02 09:15:32 JST; 5min ago
    Process: 5001 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
   Main PID: 5001 (code=exited, status=1/FAILURE)
Nov 02 09:15:32 myserver httpd[5001]: AH00526: Syntax error on line 42 of /etc/httpd/conf.d/vhost.conf
Nov 02 09:15:32 myserver httpd[5001]: Invalid command 'ServerAlias2', perhaps misspelled
最後の2行に「Syntax error on line 42」と具体的な場所とエラーが出ている。このように systemctl status は journalctl よりも素早く直近のエラーを把握できるため、最初に叩くコマンドとして有用だ。

2. ユニットファイルの設定ミスを確認する

自作のsystemdユニットファイルを使っている場合、構文エラーで起動が止まることがある。

# ユニットファイルの構文チェック
systemd-analyze verify /etc/systemd/system/myapp.service

# ユニットファイルを編集した後はデーモンの再読み込みが必要
sudo systemctl daemon-reload
sudo systemctl restart myapp.service
よく見る失敗パターンとしては「ExecStart のパスに絶対パスを使っていない」「Environment= の変数名にスペースが入っている」「After= に存在しないユニット名を指定している」などがある。

3. 起動時間が遅い時のブート解析

AlmaLinuxの起動が遅い場合、 systemd-analyze でどのユニットが時間を食っているかを特定できる（systemd-analyze で起動時間計測の詳細もあわせて確認してほしい）。

# 起動全体のタイムライン
systemd-analyze

# ユニット別の起動時間（遅い順）
systemd-analyze blame | head -20

# 依存関係の可視化（SVGファイル出力）
systemd-analyze plot > /tmp/boot.svg
「NetworkManager-wait-online.service」が30秒以上かかっている場合は、ネットワーク待機が原因の可能性が高い。自宅サーバーで固定IPを使わずDHCPにしているケースでは、ネットワークアダプタを起動対象外にするか待機タイムアウトを短縮する設定が有効なことがある。

ディスク容量不足の調査と対処

1. df・duでディスク使用量を確認する

「No space left on device」エラーが出た場合、まず現在のディスク使用状況を把握する。

# ファイルシステム別のディスク使用量
df -hT

# 出力例（環境により異なります）
# Filesystem              Type      Size  Used Avail Use% Mounted on
# /dev/mapper/almalinux-root xfs   50G   49G   1.0G  98% /
# /dev/sda1               xfs       1.0G  248M  753M  25% /boot

# ディレクトリ別のサイズ（大きい順に表示）
du -sh /* 2>/dev/null | sort -rh | head -15

# /var配下を掘り下げる（ログが多いケース）
du -sh /var/* | sort -rh | head -10
dfで /var のUsageが高い場合、次のログ肥大化を確認する。

2. journaldのログ肥大化への対処

AlmaLinuxのデフォルト設定では journald のログがディスク容量の10%まで増大する可能性がある。長期運用の自宅サーバーでは静かにディスクを圧迫していることが多い。

# journaldのログ使用量を確認
journalctl --disk-usage

# 出力例（環境により異なります）
# Archived and active journals take up 4.5G in the filesystem.

# 古いログを削除する（2週間以上前のものを削除）
sudo journalctl --vacuum-time=2weeks

# または使用量の上限を指定して削除
sudo journalctl --vacuum-size=500M

# 上限を永続設定する（/etc/systemd/journald.conf に追記）
# [Journal]
# SystemMaxUse=500M
sudo systemctl restart systemd-journald
journald以外に /var/log/httpd/ や /var/log/nginx/ のアクセスログが肥大化するケースも多い。logrotate の設定（/etc/logrotate.d/配下）を確認し、rotate数や圧縮設定が適切かチェックするとよい。

AlmaLinuxトラブル対処コマンド早見表

よく使うトラブル対処コマンドを一覧にまとめた。
トラブルの症状 最初に叩くコマンド
起動直後のエラー全般 journalctl -xe
ハードウェア・ディスクエラー dmesg -T --level=err,warn
特定サービスのエラー確認 systemctl status サービス名.service
起動失敗したユニット一覧 systemctl --failed
ネットワーク疎通確認 ip addr show && ip route show
firewalldのポート確認 firewall-cmd --list-all
SELinux拒否ログ確認 grep denied /var/log/audit/audit.log | tail -20
ディスク使用量確認 df -hT && du -sh /var/* | sort -rh | head -10
journaldログ使用量確認 journalctl --disk-usage
起動時間の遅延原因特定 systemd-analyze blame | head -20
AlmaLinux自宅サーバーのトラブルは「ログを読む→firewalld確認→SELinux確認」という調査の流れを身につけるだけで、大半の問題に対処できるようになる。企業環境と同じRHELベースの作法を自宅環境でも徹底することが、本番環境でのトラブル対応力に直結する。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、Linux Master Pro Seminarでは、AlmaLinuxをはじめとするRHEL系サーバーのセットアップからトラブルシューティングまでを少人数ハンズオンで習得できます。詳細はセミナーLPをご覧ください。

関連記事

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

Linux無料マニュアル（図解60P） 名前とメールで30秒登録

運営

リナックスマスター.JP（代表 宮崎智広）

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。