AlmaLinux 10 総合ガイド
付録B: トラブルシューティングフローチャート

この付録の使い方

この付録は、問題発生時にすぐに参照できるフローチャートをまとめたものです。各フローチャートでは「何を確認するか」「どのコマンドを実行するか」「次に何をすべきか」を順を追って示しています。

使い方のポイント:

Step 1から順番に進める
各ステップの「判断」を確認し、該当する分岐に従う
コマンドはそのままコピペして実行できる形式
詳細な解説が必要な場合は、本編（第8章）を参照

注意: [サービス名]、[ホスト名]などのプレースホルダーは、実際の値に置き換えて実行してください。

コンテンツ

この付録の使い方

B.1 サービスが起動しない
B.2 ネットワークに繋がらない
B.3 ディスク容量不足
B.4 パーミッションエラー
- Step 1: 通常のパーミッション確認
- Step 2: SELinuxコンテキスト確認
B.5 一般的なトラブルシューティング手順
クイックリファレンス: 問題別コマンド一覧

B.1 サービスが起動しない

サービスが起動しない場合の調査手順です。systemdで管理されているサービス全般に適用できます。

[問題発生: サービスが起動しない]
    │
    ▼
[Step 1: 状態確認] ─→ active (running) ─→ [サービスは正常。別の問題を調査]
    │
    │ failed / inactive
    ▼
[Step 2: ログ確認] ─→ エラーメッセージあり ─→ [メッセージに従い対処]
    │
    │ 情報不足
    ▼
[Step 3: 設定ファイル構文チェック] ─→ エラーあり ─→ [設定を修正]
    │
    │ OK
    ▼
[Step 4: パーミッション確認] ─→ 問題あり ─→ [chmod/chownで修正]
    │
    │ OK
    ▼
[Step 5: SELinux確認] ─→ 拒否あり ─→ [restorecon/semanageで修正]
    │
    │ OK
    ▼
[Step 6: ポート競合確認] ─→ 競合あり ─→ [競合プロセスを停止/ポート変更]
    │
    │ なし
    ▼
[Step 7: 依存サービス確認] ─→ 詳細は第8章参照

Step 1: サービスの状態を確認

[実行ユーザー: 一般ユーザー]

$ systemctl status [サービス名]

確認結果	判断	次のアクション
`Active: active (running)`	正常	サービスは起動済み。問題は別の箇所にある
`Active: failed`	異常	→ Step 2へ
`Active: inactive (dead)`	停止中	→ Step 2へ

Step 2: ログを確認

[実行ユーザー: 一般ユーザー]

$ journalctl -xe -u [サービス名]

直近のエラーのみ確認する場合:

$ journalctl -u [サービス名] -p err --since "10 minutes ago"

確認結果	判断	次のアクション
具体的なエラーメッセージが表示された	原因判明	エラーメッセージに従って対処
情報が不足している / よくわからない	要調査	→ Step 3へ

Step 3: 設定ファイルの構文チェック

多くのサービスには構文チェック用のコマンドがあります。

サービス	構文チェックコマンド
Apache (httpd)	`sudo apachectl configtest`
Nginx	`sudo nginx -t`
sshd	`sudo sshd -t`
named (BIND)	`sudo named-checkconf`
Postfix	`sudo postfix check`

[実行ユーザー: 一般ユーザー（sudo使用）]

# Apache の例
$ sudo apachectl configtest
Syntax OK   # 正常
# または
AH00526: Syntax error on line 42 of /etc/httpd/conf/httpd.conf:   # エラー

確認結果	判断	次のアクション
`Syntax OK` など正常メッセージ	正常	→ Step 4へ
`Syntax error` などエラーメッセージ	異常	指摘された行を修正

Step 4: パーミッション確認

サービスが使用するファイル・ディレクトリのパーミッションを確認します。

[実行ユーザー: 一般ユーザー]

# 設定ファイルのパーミッション
$ ls -la /etc/[サービス名]/

# ログディレクトリのパーミッション
$ ls -la /var/log/[サービス名]/

# データディレクトリのパーミッション（サービスによる）
$ ls -la /var/lib/[サービス名]/

確認結果	判断	次のアクション
所有者/グループが適切でない	異常	`sudo chown` で修正
パーミッションが不足（読み取り不可など）	異常	`sudo chmod` で修正
パーミッションに問題なし	正常	→ Step 5へ

Step 5: SELinux確認

SELinuxがアクセスを拒否している可能性を確認します。

[実行ユーザー: 一般ユーザー（sudo使用）]

# SELinuxの状態確認
$ getenforce
Enforcing   # 有効

# 直近のSELinux拒否を確認
$ sudo ausearch -m AVC -ts recent

# または audit.log を直接確認
$ sudo grep "denied" /var/log/audit/audit.log | tail -10

確認結果	判断	次のアクション
`avc: denied` のログがある	SELinux拒否	コンテキスト修正（下記参照）
拒否ログなし / `<no matches>`	正常	→ Step 6へ

SELinux問題の対処:

# コンテキストをデフォルトに復元
$ sudo restorecon -Rv /path/to/directory

# カスタムパスの場合はコンテキストを設定
$ sudo semanage fcontext -a -t [タイプ] "/path/to/files(/.*)?"
$ sudo restorecon -Rv /path/to/files

Step 6: ポート競合確認

他のプロセスが同じポートを使用していないか確認します。

[実行ユーザー: 一般ユーザー（sudo使用）]

# 特定ポートを使用しているプロセスを確認
$ sudo ss -tlnp | grep :[ポート番号]

# 例: ポート80を確認
$ sudo ss -tlnp | grep :80
LISTEN 0      128          *:80          *:*    users:(("nginx",pid=1234,fd=6))

確認結果	判断	次のアクション
別のプロセスがポートを使用中	競合	競合プロセスを停止、またはポート番号を変更
該当ポートを使用しているプロセスなし	正常	→ Step 7へ

Step 7: 依存サービス確認

サービスが依存している他のサービスを確認します。

[実行ユーザー: 一般ユーザー]

# 依存関係を確認
$ systemctl list-dependencies [サービス名]

# 依存サービスの状態を確認
$ systemctl status [依存サービス名]

💡 詳細は第8章「8.4 ケーススタディ1: サービスが起動しない」を参照してください。

B.2 ネットワークに繋がらない

ネットワーク接続ができない場合の調査手順です。レイヤーの低い部分（物理層）から順に確認していきます。

[問題発生: ネットワークに繋がらない]
    │
    ▼
[Step 1: インターフェース状態] ─→ DOWN ─→ [nmcli connection up で有効化]
    │
    │ UP
    ▼
[Step 2: IPアドレス確認] ─→ 未設定 ─→ [DHCP/静的IPを設定]
    │
    │ 設定済み
    ▼
[Step 3: ゲートウェイping] ─→ 失敗 ─→ [ローカルネットワーク問題を調査]
    │
    │ 成功
    ▼
[Step 4: 外部ホストping] ─→ 失敗 ─→ [ルーティング/上流ネットワーク問題]
    │
    │ 成功
    ▼
[Step 5: DNS解決] ─→ 失敗 ─→ [DNS設定を確認・修正]
    │
    │ 成功
    ▼
[Step 6: ファイアウォール確認] ─→ ブロックあり ─→ [firewall-cmdで許可]
    │
    │ OK
    ▼
[Step 7: 特定サービスの疎通確認] ─→ 詳細は第8章参照

Step 1: インターフェース状態確認（ip link）

ネットワークインターフェースが有効（UP）になっているか確認します。

[実行ユーザー: 一般ユーザー]

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> ...
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> ...   # UP = 有効
# または
2: enp0s3: <BROADCAST,MULTICAST> ...               # UP がない = 無効

確認結果	判断	次のアクション
`state UP` または `<...,UP,...>`	正常	→ Step 2へ
`state DOWN` または UP がない	無効	下記コマンドで有効化

インターフェースを有効化:

[実行ユーザー: 一般ユーザー（sudo使用）]

# 接続プロファイルを確認
$ nmcli connection show

# 接続を有効化
$ sudo nmcli connection up [接続名]

Step 2: IPアドレス確認（ip addr）

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

[実行ユーザー: 一般ユーザー]

$ ip addr show [インターフェース名]
# 例
$ ip addr show enp0s3
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
    link/ether 08:00:27:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.100/24 brd 192.168.1.255 ...   # ← IPアドレス

確認結果	判断	次のアクション
`inet x.x.x.x/xx` の行がある	正常	→ Step 3へ
`inet` の行がない	未設定	IPアドレスを設定（DHCP or 静的）

IPアドレスを取得（DHCP）:

$ sudo nmcli connection up [接続名]

Step 3: ゲートウェイへのping

ローカルネットワーク内のゲートウェイに到達できるか確認します。

[実行ユーザー: 一般ユーザー]

# ゲートウェイのIPアドレスを確認
$ ip route | grep default
default via 192.168.1.1 dev enp0s3 ...

# ゲートウェイにping
$ ping -c 3 192.168.1.1

確認結果	判断	次のアクション
応答あり（`64 bytes from ...`）	正常	→ Step 4へ
応答なし / `Destination Host Unreachable`	異常	ケーブル、スイッチ、ゲートウェイを確認
`default via` の行がない	未設定	ゲートウェイを設定

Step 4: 外部ホストへのping

インターネット上のホストに到達できるか確認します。

[実行ユーザー: 一般ユーザー]

# Google Public DNS にping（名前解決を使わずIPアドレスで確認）
$ ping -c 3 8.8.8.8

確認結果	判断	次のアクション
応答あり	正常	→ Step 5へ
応答なし / `Network is unreachable`	異常	ルーティング設定、上流ネットワークを確認

Step 5: DNS解決確認

ドメイン名からIPアドレスに変換（名前解決）できるか確認します。

[実行ユーザー: 一般ユーザー]

# digコマンドでDNS解決を確認
$ dig google.com +short
142.250.196.110

# または nslookup
$ nslookup google.com

確認結果	判断	次のアクション
IPアドレスが表示された	正常	→ Step 6へ
`connection timed out` / 解決失敗	DNS問題	下記でDNS設定を確認

DNS設定の確認:

# 現在のDNSサーバーを確認
$ cat /etc/resolv.conf

# NetworkManagerで管理されている場合
$ nmcli device show | grep DNS

Step 6: ファイアウォール確認

ファイアウォールが通信をブロックしていないか確認します。

[実行ユーザー: 一般ユーザー（sudo使用）]

# 現在のファイアウォール設定
$ sudo firewall-cmd --list-all

# 特定のサービスが許可されているか
$ sudo firewall-cmd --list-services

確認結果	判断	次のアクション
必要なサービス/ポートが許可されている	正常	→ Step 7へ
必要なサービス/ポートがない	ブロック	firewall-cmd で許可を追加

サービス/ポートを許可:

# サービスを許可（永続）
$ sudo firewall-cmd --add-service=[サービス名] --permanent

# ポートを許可（永続）
$ sudo firewall-cmd --add-port=[ポート]/tcp --permanent

# 設定を反映
$ sudo firewall-cmd --reload

Step 7: ルーティング確認

ルーティングテーブルに問題がないか確認します。

[実行ユーザー: 一般ユーザー]

$ ip route
default via 192.168.1.1 dev enp0s3 proto dhcp metric 100
192.168.1.0/24 dev enp0s3 proto kernel scope link src 192.168.1.100 metric 100

default via の行がない場合は、デフォルトゲートウェイが設定されていません。

💡 詳細は第8章「8.5 ケーススタディ2: ネットワークに繋がらない」を参照してください。

B.3 ディスク容量不足

ディスク容量が不足している場合の調査・対処手順です。

[問題発生: No space left on device]
    │
    ▼
[Step 1: 容量確認 (df -h)] ─→ どのパーティションが満杯か特定
    │
    ▼
[Step 2: 大まかな特定 (du -sh /*)]
    │
    ▼
[Step 3: 詳細特定 (du -sh /xxx/*)]
    │
    ▼
[Step 4: 削除対象の判断]
    │
    ├─→ ログファイル肥大化 ─→ [truncate で切り詰め]
    │
    ├─→ 一時ファイル ─→ [古いものを削除]
    │
    └─→ パッケージキャッシュ ─→ [dnf clean all]
    │
    ▼
[Step 5: 容量回復確認 (df -h)]
    │
    ▼
[Step 6: 恒久対策] ─→ logrotate設定、監視設定

Step 1: ディスク容量を確認（df -h）

どのパーティションが容量不足かを特定します。

[実行ユーザー: 一般ユーザー]

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3        50G   50G     0 100% /        ← 問題のパーティション
/dev/sda2       960M  224M  736M  24% /boot
/dev/sda1       599M  7.0M  592M   2% /boot/efi

Use%	判断	次のアクション
100%	緊急	即座にStep 2へ
90%以上	警告	早急に対処が必要
80%未満	正常	定期監視で十分

Step 2: 大まかな使用場所を特定（du -sh /*）

どのディレクトリが容量を消費しているか大まかに把握します。

[実行ユーザー: 一般ユーザー（sudo使用）]

$ sudo du -sh /* 2>/dev/null | sort -rh | head -10
35G     /var        ← 最も大きい
8.5G    /usr
2.1G    /home
1.2G    /opt
...

Step 3: 詳細な使用場所を特定

Step 2で特定したディレクトリをさらに掘り下げます。

[実行ユーザー: 一般ユーザー（sudo使用）]

# /var の内訳を確認
$ sudo du -sh /var/* 2>/dev/null | sort -rh | head -10
32G     /var/log    ← ログが原因
1.5G    /var/cache
800M    /var/lib
...

# さらに詳細
$ sudo du -sh /var/log/* 2>/dev/null | sort -rh | head -10
30G     /var/log/httpd
1.2G    /var/log/messages
...

# 具体的なファイルを確認
$ sudo ls -lhS /var/log/httpd/
total 30G
-rw-r--r--. 1 root root  28G Jan 15 14:30 access_log    ← 原因特定
-rw-r--r--. 1 root root 2.0G Jan 15 14:30 error_log

Step 4: 削除可能なファイルの対処

ログファイルが肥大化している場合

🚨 重要: サービスが使用中のログファイルは rm ではなく truncate で空にしてください。rm で削除すると、ファイルハンドルが残りディスク容量が解放されないことがあります。

[実行ユーザー: 一般ユーザー（sudo使用）]

# ログファイルを空にする（削除ではない）
$ sudo truncate -s 0 /var/log/httpd/access_log

# 容量が解放されたか確認
$ df -h /

一時ファイルが溜まっている場合

[実行ユーザー: 一般ユーザー（sudo使用）]

# 7日以上前の一時ファイルを削除
$ sudo find /tmp -type f -mtime +7 -delete
$ sudo find /var/tmp -type f -mtime +7 -delete

パッケージキャッシュが大きい場合

[実行ユーザー: 一般ユーザー（sudo使用）]

# キャッシュサイズを確認
$ sudo du -sh /var/cache/dnf
1.5G    /var/cache/dnf

# キャッシュをクリア
$ sudo dnf clean all

# 確認
$ sudo du -sh /var/cache/dnf
12K     /var/cache/dnf

Step 5: 容量回復を確認

[実行ユーザー: 一般ユーザー]

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3        50G   22G   28G  44% /    ← 回復

Step 6: 恒久対策

同じ問題が再発しないよう、ログローテーションを設定します。

[実行ユーザー: 一般ユーザー（sudo使用）]

# logrotate設定の確認・編集
$ sudo vi /etc/logrotate.d/httpd

推奨設定例:

/var/log/httpd/*log {
    daily              # 毎日ローテーション
    rotate 7           # 7世代保持
    compress           # 古いログを圧縮
    size 100M          # 100MBを超えたらローテーション
    missingok
    notifempty
    sharedscripts
    postrotate
        /bin/systemctl reload httpd.service > /dev/null 2>/dev/null || true
    endscript
}

💡 詳細は第8章「8.6 ケーススタディ3: ディスク容量不足」および第9章「9.7 ログローテーションの設定」を参照してください。

B.4 パーミッションエラー

「Permission denied」エラーが発生した場合の調査・対処手順です。

[問題発生: Permission denied]
    │
    ▼
[Step 1: 対象ファイルのパーミッション確認 (ls -l)]
    │
    ├─→ パーミッション不足 ─→ [chmod で修正]
    │
    ├─→ 所有者/グループが違う ─→ [chown で修正]
    │
    └─→ パーミッションは正常
            │
            ▼
[Step 2: SELinuxコンテキスト確認 (ls -Z)]
    │
    ├─→ コンテキストが不適切 ─→ [restorecon/semanage で修正]
    │
    └─→ コンテキストは正常 ─→ [その他の原因を調査]

Step 1: 通常のパーミッション確認

[実行ユーザー: 一般ユーザー]

# ファイル/ディレクトリのパーミッションを確認
$ ls -la [対象のパス]
-rw-------. 1 root root 1234 Jan 15 10:00 config.txt

# 自分のユーザー/グループを確認
$ id
uid=1000(developer) gid=1000(developer) groups=1000(developer),10(wheel)

確認項目	問題の例	対処
読み取り権限がない	`-rw-------` で他者が読めない	`sudo chmod o+r [ファイル]`
書き込み権限がない	`-r--r--r--` で書き込めない	`sudo chmod u+w [ファイル]`
実行権限がない	`-rw-r--r--` でスクリプトが実行できない	`chmod +x [ファイル]`
所有者が違う	root所有で一般ユーザーが書けない	`sudo chown [ユーザー] [ファイル]`

パーミッション修正の例

[実行ユーザー: 一般ユーザー（sudo使用）]

# 所有者を変更
$ sudo chown developer:developer /path/to/file

# パーミッションを変更（644 = rw-r--r--）
$ sudo chmod 644 /path/to/file

# ディレクトリを再帰的に変更
$ sudo chown -R developer:developer /path/to/directory
$ sudo chmod -R 755 /path/to/directory

Step 2: SELinuxコンテキスト確認

通常のパーミッションに問題がない場合、SELinuxを確認します。

[実行ユーザー: 一般ユーザー]

# ファイルのSELinuxコンテキストを確認
$ ls -Z [対象のパス]
unconfined_u:object_r:user_home_t:s0 config.txt

# プロセスのコンテキストを確認
$ ps -Z | grep [プロセス名]
system_u:system_r:httpd_t:s0    1234 ?        00:00:01 httpd

ファイルのタイプ（user_home_tなど）と、アクセスしようとしているプロセスのタイプ（httpd_tなど）が合っていないと、SELinuxに拒否されます。

SELinuxコンテキストの修正

[実行ユーザー: 一般ユーザー（sudo使用）]

# デフォルトのコンテキストに復元
$ sudo restorecon -Rv /path/to/file

# カスタムパスの場合、適切なタイプを設定
# 例: Webコンテンツの場合
$ sudo semanage fcontext -a -t httpd_sys_content_t "/var/www/custom(/.*)?"
$ sudo restorecon -Rv /var/www/custom

よく使うSELinuxタイプ

用途	SELinuxタイプ
Webコンテンツ（読み取り専用）	`httpd_sys_content_t`
Webコンテンツ（書き込み可能）	`httpd_sys_rw_content_t`
SSHの鍵ファイル	`ssh_home_t`
ホームディレクトリ	`user_home_t`

💡 詳細は第2章「パーミッションの基礎」および第7章「7.4 SELinuxの基礎」を参照してください。

B.5 一般的なトラブルシューティング手順

特定の問題に限らず、あらゆるトラブルに適用できる汎用的な問題解決プロセスです。

トラブルシューティングの基本原則

原則	説明
まずログを確認する	問題の原因は多くの場合ログに記録されている
一度に一つずつ変更する	複数の変更を同時にすると、何が効いたかわからなくなる
変更前の状態を記録する	元に戻せるように、変更前の設定をメモまたはバックアップする
思い込みで判断しない	「たぶんこれが原因だろう」で決めつけず、証拠を集める

問題解決の9ステップ

[Step 1] 問題の特定
    │     「何が起きているか」を正確に把握する
    ▼
[Step 2] 情報収集
    │     ログ確認、状態確認、エラーメッセージの記録
    ▼
[Step 3] 仮説の立案
    │     「原因はおそらく〇〇だろう」と推測する
    ▼
[Step 4] 仮説の検証
    │     一つずつ確認して仮説を検証する
    ▼
[Step 5] 原因の特定
    │     検証の結果、原因を特定する
    ▼
[Step 6] 対処の実施
    │     原因に対する対処を行う
    ▼
[Step 7] 動作確認
    │     問題が解決したか確認する
    ▼
[Step 8] 再発防止策の検討
    │     同じ問題が起きないようにする
    ▼
[Step 9] 記録の作成
          何が起きて、どう解決したかを記録する

基本的なログ確認コマンド

目的	コマンド
systemdサービスのログ	`journalctl -xe -u [サービス名]`
直近のエラーのみ	`journalctl -p err --since "1 hour ago"`
リアルタイム監視	`journalctl -f`
システム全般のログ	`sudo tail -100 /var/log/messages`
認証関連のログ	`sudo tail -100 /var/log/secure`
SELinux拒否のログ	`sudo ausearch -m AVC -ts recent`
カーネルメッセージ	`dmesg -T \| tail -50`

基本的な状態確認コマンド

確認対象	コマンド
サービスの状態	`systemctl status [サービス名]`
ネットワークインターフェース	`ip link`, `ip addr`
ディスク使用量	`df -h`
メモリ使用量	`free -h`
CPU・プロセス	`top`, `htop`
開いているポート	`sudo ss -tlnp`
ファイアウォール	`sudo firewall-cmd --list-all`
SELinuxの状態	`getenforce`, `sestatus`

エラーメッセージの調べ方

エラーメッセージをそのまま検索エラーメッセージをダブルクォートで囲んでGoogle検索すると、同じ問題に遭遇した人の情報が見つかることが多い
```
"AH00526: Syntax error on line 42"
```
公式ドキュメントを確認AlmaLinux、Red Hat、各ソフトウェアの公式ドキュメントで、エラーコードやメッセージを検索
manページを確認
```
$ man [コマンド名]
```

💡 詳細は第8章「8.3 トラブルシューティングの基本手順」を参照してください。

クイックリファレンス: 問題別コマンド一覧

よくある問題に対する最初に実行すべきコマンドをまとめました。

問題	最初に実行するコマンド
サービスが起動しない	`systemctl status [サービス名]` `journalctl -xe -u [サービス名]`
ネットワークに繋がらない	`ip link` `ip addr` `ping 8.8.8.8`
ディスクが満杯	`df -h` `sudo du -sh /* \| sort -rh \| head`
Permission denied	`ls -la [対象パス]` `ls -Z [対象パス]`
プロセスが重い	`top` または `htop`
ポートが使えない	`sudo ss -tlnp \| grep :[ポート]`
SSH接続できない	`systemctl status sshd` `sudo firewall-cmd --list-services`
名前解決できない	`dig [ホスト名]` `cat /etc/resolv.conf`

📌 ヒント: このページをブックマークしておくと、緊急時にすぐ参照できます。また、各フローチャートはPDF化して印刷しておくことも有効です。

AlmaLinux 10 総合ガイド 付録B: トラブルシューティングフローチャート

この付録の使い方

B.1 サービスが起動しない

Step 1: サービスの状態を確認

Step 2: ログを確認

Step 3: 設定ファイルの構文チェック

Step 4: パーミッション確認

Step 5: SELinux確認

Step 6: ポート競合確認

Step 7: 依存サービス確認

B.2 ネットワークに繋がらない

Step 1: インターフェース状態確認（ip link）

Step 2: IPアドレス確認（ip addr）

Step 3: ゲートウェイへのping

Step 4: 外部ホストへのping

Step 5: DNS解決確認

Step 6: ファイアウォール確認

Step 7: ルーティング確認

B.3 ディスク容量不足

Step 1: ディスク容量を確認（df -h）

Step 2: 大まかな使用場所を特定（du -sh /*）

Step 3: 詳細な使用場所を特定

Step 4: 削除可能なファイルの対処

ログファイルが肥大化している場合

一時ファイルが溜まっている場合

パッケージキャッシュが大きい場合

Step 5: 容量回復を確認

Step 6: 恒久対策

B.4 パーミッションエラー

Step 1: 通常のパーミッション確認

パーミッション修正の例

Step 2: SELinuxコンテキスト確認

SELinuxコンテキストの修正

よく使うSELinuxタイプ

B.5 一般的なトラブルシューティング手順

トラブルシューティングの基本原則

問題解決の9ステップ

基本的なログ確認コマンド

基本的な状態確認コマンド

エラーメッセージの調べ方

クイックリファレンス: 問題別コマンド一覧

AlmaLinux 10 総合ガイド
付録B: トラブルシューティングフローチャート