Linuxトラブルシューティング
Linuxトラブルシューティング:記事リスト
Linuxトラブルシューティングのカテゴリーには以下の記事がリストされています。
SSHで接続できない時の切り分け手順|ssh -vvvとsshd -Tでクライアント・サーバー両面から原因を特定する
夜間にサーバーが応答しなくなって、焦りながら原因を探した経験はないでしょうか。
SSH接続が失敗する原因は複数あります。ファイアウォール、sshdの停止、鍵のパーミッション、sshd_configのAllowUsers制限など、原因は様々ですが、どれも同じ「接続できない」というエラーで現れます。手当たり次第に設定を触るのは逆効果です。
この記事では、クライアント側の詳細ログを取得する
ssh -vvv と、サーバー側の有効設定を出力する sshd -T を組み合わせた、体系的な切り分け手順を解説します。動作確認環境: RHEL 9.4 / Ubuntu 24.04 LTS
この記事のポイント
・ssh -vvvで接続試行の詳細ログを確認できる
・sshd -Tでサーバーの有効な設定値を即確認できる
・「connection refused」はポートとsshdの起動状態を最初に確認
・鍵認証失敗は~/.ssh/authorized_keysのパーミッションが原因なことが多い
続きを読む "SSHで接続できない時の切り分け手順|ssh -vvvとsshd -Tでクライアント・サーバー両面から原因を特定する"
killできないプロセスとゾンビプロセスの調査・対処|Dステート・defunctの見分け方と安全な解消手順
しかし、ゾンビプロセス(defunct)とDステートプロセスに kill コマンドを何度打っても解消しません。どちらもカーネルの仕組み上、シグナルを受け取れる状態にないからです。
この記事では、「ゾンビプロセス kill できない」「Dステート kill できない」という状況の根本原因から、ps・/proc ファイルシステムを使った調査手順と状態ごとの安全な解消方法まで、RHEL 9.4 / Rocky Linux 9 の実際のサーバー出力例を交えて解説します。闇雲に kill を繰り返すのではなく、状態を正確に診断して的確な対処が取れるようになることがゴールです。
この記事のポイント
・ゾンビ(defunct/Z)は「終了済みの残骸」でシグナルを受け取れない
・Dステートは「カーネルI/O待ちで割り込み不可」のため kill が効かない
・ゾンビ解消には kill ではなく「親プロセスへの SIGCHLD か親の終了」が正解
・DステートはNFS・ストレージのI/O根本原因を取り除かないと解消しない
続きを読む "killできないプロセスとゾンビプロセスの調査・対処|Dステート・defunctの見分け方と安全な解消手順"
Linuxが起動しない時の復旧手順|GRUBレスキューモード・emergency modeとfstab誤設定の直し方
Linuxが起動しなくなる瞬間は突然やってきます。カーネルアップデートの直後、/etc/fstab の誤記、ストレージ障害、あるいは原因不明の停電——いずれも復旧を急ぐ状況で、画面に表示されるメッセージだけを頼りに対処しなければなりません。
この記事では、Linux起動障害のうち特に遭遇頻度の高い「grub rescue> プロンプト」「emergency mode / rescue target」「fstab誤設定」の3パターンに絞り、原因の切り分けから実際の復旧コマンドまでを体系的に解説します。Linuxの起動シーケンスの理論(BIOS から systemd まで)は別記事で解説しており、本記事はトラブル発生時の実践的な操作手順に特化しています。
動作確認環境:RHEL 9.4 / Rocky Linux 9 / Ubuntu 24.04 LTS
この記事のポイント
・grub rescue> が出たら ls でパーティション確認 → insmod normal で起動できる
・emergency modeはjournalctl -xbでエラーを特定してから対処する
・fstab誤設定はblkidでUUID確認 → findmnt --verifyで書式検証が基本
・再発防止にはnofailオプションとGRUB設定ファイルのバックアップが有効
続きを読む "Linuxが起動しない時の復旧手順|GRUBレスキューモード・emergency modeとfstab誤設定の直し方"
LinuxのRead-only file systemエラーを復旧する方法|原因の切り分けとfsckによるファイルシステム修復手順
read-only file system エラーは、原因によって対処方法がまったく変わります。軽微なジャーナル不整合なら remount で即時復旧できますが、ファイルシステム破損が疑われる場合は fsck による本格修復が必要です。
この記事では、Read-only file system エラーの原因を切り分ける手順と、fsck(file system check)を使ったファイルシステム修復手順をステップごとに解説します。
RHEL 9.4 / Ubuntu 24.04 LTS・ext4/XFS ファイルシステムで動作確認済みの手順です。
この記事のポイント
・read-only file systemの原因はまずdmesgとjournalctlで確認する
・軽微な不整合はmount -o remount,rwで即時復旧できる
・fsckはアンマウント後またはシングルユーザーモードで実行する
・XFSはxfs_repair、ext4はe2fsckで修復する
続きを読む "LinuxのRead-only file systemエラーを復旧する方法|原因の切り分けとfsckによるファイルシステム修復手順"
systemdサービスが起動しない・failedになる時の調査手順|依存関係とユニット設定の直し方
サーバー管理の現場で、こうした状況は珍しくない。特に自作のユニットファイルを書いた直後や、OS を RHEL 8 系から RHEL 9 系へ移行した際によく発生する。
systemd サービスの起動失敗は、正しい手順でログを追えば、ほとんどのケースで原因を特定できる。闇雲に設定を変更するのではなく、「なぜ failed になっているのか」を確認する順序が重要だ。
本記事では、systemd サービスが起動しない・failed になる時の調査手順を、journalctl のログ確認・依存関係のチェック・ユニットファイルの設定修正まで、現場で即使える手順で解説する。
動作確認環境:RHEL 9.4 / Ubuntu 24.04 LTS で確認済み。
この記事のポイント
・systemctl status → journalctl -xe の順で調査すれば原因の9割が特定できる
・failed の多くは ExecStart のパス誤り・実行権限・依存サービスの未起動が原因
・ユニットファイルを編集したら必ず daemon-reload を実行してから再起動する
・依存関係エラーは After/Requires の見直しか、依存先サービスの修正で解消できる
Linuxサーバーが急に重くなった時の原因切り分け手順|CPU・メモリ・ディスクI・Oを順に調べる
深夜の障害対応でこの状況に陥ると、焦りで頭が真っ白になる人は少なくありません。
この記事では、Linuxサーバーの高負荷が発生した際に CPU・メモリ・ディスクI/O を順番に切り分ける手順 を、コマンドの実行例と出力の読み方とともに解説します。
RHEL 9.4 / Ubuntu 24.04 LTS で動作確認済みです。
この記事のポイント
・まず top/uptime でロードアベレージの傾向を掴む
・CPU 高負荷なら top の %us/%sy/%wa の内訳で方向を絞る
・メモリ不足は free -h の available 欄とスワップ使用量で判断する
・ディスク待ちは iostat -x で %iowait と %util を確認する
Linuxでcronが実行されない時の調査手順|ログ・環境変数・権限の3点を切り分ける
cronのトラブルは、原因が3つのパターンにほぼ絞られます。ログの確認、環境変数の設定、実行権限の確認です。この3点を順番に切り分ければ、大半の問題は30分以内に解決できます。
この記事では、cronが実行されない時の原因切り分け手順を、実際のログ出力例を交えながら解説します。RHEL 9.4 / Ubuntu 24.04 LTSで動作確認済みです。
この記事のポイント
・cronのログを journalctl -u crond で即座に確認する
・「手動でOK・cronでNG」はほぼ PATH 未設定が原因
・実行権限(chmod +x)と行末の改行コードも必ず確認
・/var/log/cron が空なら crond 自体が停止していないか確認する
Linuxでディスクが容量不足になった時の対処手順|原因ファイルの特定から安全な削除まで
容量不足はパニックになりがちですが、手順を知っていれば冷静に対処できます。
この記事では、Linuxでディスク容量が不足した時の対処フロー(原因ファイルの特定から安全な削除まで)を体系的に解説します。
dfコマンドで状況を確認してから、duコマンドで原因を特定し、安全にディスクを空ける具体的な手順まで、ステップごとに説明します。
この記事のポイント
・dfコマンドで「どのパーティションが満杯か」を最初に把握する
・duコマンドで「容量を食っているディレクトリ」を絞り込む
・ログ・コアダンプ・古いバックアップが原因の大多数を占める
・削除前に必ずファイルの用途を確認してから実施する
rsyslog.confの設定ガイド|ログ転送・フィルタリング・テンプレートの実践例
「ログを別サーバーに転送する設定をしたいが、どこに何を書けばいいのか。」
Linuxのログ管理を担うrsyslogは、設定ファイル rsyslog.conf の書き方を知っているかどうかで、運用効率が大きく変わります。
この記事では、rsyslog.conf の基本構造から、ログ転送・フィルタリング・テンプレートの実践的な設定例まで体系的に解説します。RHEL 9 / AlmaLinux 9 / Ubuntu 24.04 LTSで動作確認済みです。
この記事のポイント
・ rsyslog.conf はファシリティ.プライオリティ+アクションの組み合わせで書く
・ @@サーバーIPでTCP転送、@サーバーIPでUDP転送を切り替えられる
・ filterとtemplateでログの整形・選別・個別ファイル保存が可能
・ トラブル時は rsyslogd -N1 で設定ファイルの構文エラーを検出できる
AIにLinuxトラブルを解析させる方法|journalctl・dmesgのログをChatGPT・Claudeに渡すコツ
「ChatGPTに聞いてみたけど、どこに何を貼ればいいか分からない」
AIチャットにLinuxのログを貼って質問する方法は広まっていますが、渡し方を誤ると精度が大幅に下がります。 ログの量が多すぎる、文脈が不足している、機密情報が混入している——こういった問題が、的外れな回答の主な原因です。
この記事では、journalctlやdmesgの出力をChatGPT・Claudeに渡す具体的な方法と、精度を上げるプロンプトの書き方を解説します。
この記事のポイント
・ログは「エラー行前後30行」に絞り、コンテキストとセットで渡す
・journalctl -xe --no-pager でページング解除して貼り付け可能な形式にする
・IPアドレス・ホスト名・パスは貼る前にマスキングする
・AIは「原因候補の列挙」には強いが「確定診断・対処コマンドの実行」には使わない
続きを読む "AIにLinuxトラブルを解析させる方法|journalctl・dmesgのログをChatGPT・Claudeに渡すコツ"
fuserコマンドで使用中のファイル・ポートを占有するプロセスを特定する方法|umount時のtarget is busy解消
そんな場面で、いきなりサーバーを再起動していませんか?
fuserコマンドを使えば、ファイルやディレクトリ、さらにはTCP/UDPポートを占有しているプロセスを一発で特定できます。
必要ならそのプロセスにシグナルを送って終了させることも可能です。
この記事では、RHEL 9.4 / Ubuntu 24.04 LTSで動作確認した上で、fuserコマンドの実践的な使い方を解説します。
umount時のbusyエラー解消、ポート占有プロセスの特定、安全なプロセス終了まで、現場で使う場面を一通りカバーします。
この記事のポイント
・fuser /mnt でマウントポイントを掴むプロセスを特定できる
・fuser -v でユーザー・コマンド名付きの詳細表示になる
・fuser -k -TERM /mnt でプロセスにSIGTERMを送って終了できる
・fuser 80/tcp でポート占有プロセスを特定できる(要root)
続きを読む "fuserコマンドで使用中のファイル・ポートを占有するプロセスを特定する方法|umount時のtarget is busy解消"
Linuxパスワード設定の注意点|特殊文字・PAMルール・レスキュー環境の落とし穴
Linuxのパスワード設定は、一見シンプルですが、特殊文字の扱いやPAMのポリシー、レスキュー環境特有の問題など、ハマりやすいポイントが複数あります。
この記事では、Linuxにパスワードを設定する際の注意点を、特殊文字の挙動・pam_pwqualityのルール・レスキュー環境での落とし穴の3つの視点から整理します。RHEL10 / Rocky Linux 10 を主な対象としますが、基本的な考え方はRHEL9・Ubuntuにも共通します。
・@始まりパスワードはcracklibが「記号を除去」して辞書照合する
・pwscoreコマンドで設定前にパスワード強度をテストできる
・レスキュー環境はUSキーボード配列がデフォルト(jp106要loadkeys)
・特殊文字は「途中か末尾」に入れると辞書ヒットを回避しやすい
RHEL10でrootパスワードを復旧する方法|GRUBとISOレスキューモードの2手順
そんな場面に出くわしたとき、焦ってサーバーを再インストールしようとしていませんか?
実は、RHEL10にはrootパスワードを安全に再設定する方法が2つあります。
どちらも知っておけば、万が一の障害対応でも冷静に動けます。
この記事では、RHEL10でのrootパスワード設定・復旧方法を、実際の手順を交えて解説します。
この記事のポイント
・RHEL10でrootパスワードを復旧する2つの方法を解説
・GRUBから init=/bin/bash を使ったシングルユーザー的な起動手順
・ISOレスキューモードから chroot でパスワード再設定する手順
・SELinuxの .autorelabel が必要な理由と忘れた場合の影響
htopコマンドでプロセスとリソースをインタラクティブに監視する方法|topとの違いや実務活用も
topコマンドの出力は情報量こそ豊富なものの、数値がずらりと並ぶだけでCPUやメモリの偏りを瞬時に掴みにくい場面があります。
この記事では、htopコマンドの実践的な使い方を、topとの違い・色分けの読み方・プロセスの強制終了・実務でのトラブルシュートまで解説します。RHEL 9.4 / Ubuntu 24.04 LTSで動作確認済みの内容で、20年以上サーバーを運用してきた現場感覚でまとめました。
この記事のポイント
・htopはtopの上位互換、カラー表示と矢印キー操作で直感的に使える
・F9でシグナル送信、F6でソート基準変更が即時にできる
・treeビュー(F5)で親子関係を追えば暴走プロセスの根元が分かる
・RHEL系はEPELリポジトリ、Ubuntu系はapt1発でインストール可能
