Linuxトラブルシューティング Linux

この記事のポイント

・pmap PID でプロセスの仮想メモリを領域ごとに確認できる
・-x オプションで各マッピングのKbytes・RSS・Dirtyを表示できる
・タイミングをずらして2回実行し差分を見るとメモリリークの兆候を掴める
・RSS合計がOOMキラー発動判断の指標になり、事前の予防的監視に使える

この記事のポイント

・OOM Killerの発動は dmesg | grep -i oom で即確認できる
・Kill対象はoom_scoreが高いプロセス（/proc/PID/oom_scoreで確認）
・oom_score_adjを-1000にするとそのプロセスはKill対象から外れる
・systemdサービスはユニットに OOMScoreAdjust=-1000 を追記して永続化する

この記事のポイント

・kdumpはkexecで第2カーネルを起動しvmcoreを保存するLinux標準機能
・crashkernel=パラメータとkexec-toolsのインストールで有効化できる
・crashコマンドのbt/log/sysでパニック原因とスタックを特定できる
・本番投入前にsysrq+cでテストクラッシュし動作確認を済ませること

この記事のポイント

・coredumpctl listでコアダンプの一覧と詳細を確認できる
・coredumpctl gdb [PID]でgdbを直接起動しクラッシュを解析できる
・/etc/systemd/coredump.confでコアダンプの保存先とサイズを制御する
・btコマンドとprintでスタックトレースとNULLポインタを特定できる

この記事のポイント

・Magic SysRqはカーネルレベルの緊急操作機構で、/proc/sys/kernel/sysrqで有効化する
・REISUBシーケンス（R-E-I-S-U-B）はファイルシステムを守りながら安全に再起動できる
・sysctl -w kernel.sysrq=1 で即座に有効化、/etc/sysctl.d/で永続化する
・SSHが繋がる場合は /proc/sysrq-trigger へのechoコマンドでリモート操作が可能

この記事のポイント

・sosreport（sos report）はRHEL系で障害情報を一括採取する標準ツール
・採取ファイルは /var/tmp/ 配下に .tar.xz で保存され、そのままサポートへ送付できる
・プラグイン指定で採取範囲を絞れば、短時間・軽量での採取が可能
・Red Hat社員番号（caseNumber）を指定すると、ファイル名にケース番号が入り管理しやすくなる

この記事のポイント

・df -i でinode使用率（IUse%）が100%かどうかが最初の確認ポイント
・inodeはフォーマット時に数が固定されるため、ブロック容量とは独立して枯渇する
・find /var -xdev -printf '%h\n' | sort | uniq -c | sort -rn | head -20 で大量ファイルの場所を特定できる
・PHPセッションファイル・メールキュー・/tmpの蓄積がinode枯渇の三大原因

この記事のポイント

・削除直後はディスクへの書き込みを止めることが最優先——追記するほど復元率は下がる
・testdisk/photorec コマンドで ext4・XFS から削除ファイルを復元できる
・プロセスが開いていれば lsof + /proc/[pid]/fd で即時・確実に復元できる
・extundelete は長期メンテ停止のため実務では testdisk/photorec が主流

この記事のポイント

・faillock コマンドでアカウントロック状態を即確認できる
・faillock --reset --user ユーザー名 でロックを即時解除できる
・ロック条件は /etc/security/faillock.conf で一元管理されている
・SSH鍵認証や sudo が使える場合は別経路で緊急対処できる

この記事のポイント

・ssh -vvvで接続試行の詳細ログを確認できる
・sshd -Tでサーバーの有効な設定値を即確認できる
・「connection refused」はポートとsshdの起動状態を最初に確認
・鍵認証失敗は~/.ssh/authorized_keysのパーミッションが原因なことが多い

この記事のポイント

・ゾンビ（defunct/Z）は「終了済みの残骸」でシグナルを受け取れない
・Dステートは「カーネルI/O待ちで割り込み不可」のため kill が効かない
・ゾンビ解消には kill ではなく「親プロセスへの SIGCHLD か親の終了」が正解
・DステートはNFS・ストレージのI/O根本原因を取り除かないと解消しない

この記事のポイント

・grub rescue> が出たら ls でパーティション確認 → insmod normal で起動できる
・emergency modeはjournalctl -xbでエラーを特定してから対処する
・fstab誤設定はblkidでUUID確認 → findmnt --verifyで書式検証が基本
・再発防止にはnofailオプションとGRUB設定ファイルのバックアップが有効

この記事のポイント

・read-only file systemの原因はまずdmesgとjournalctlで確認する
・軽微な不整合はmount -o remount,rwで即時復旧できる
・fsckはアンマウント後またはシングルユーザーモードで実行する
・XFSはxfs_repair、ext4はe2fsckで修復する

この記事のポイント

・systemctl status → journalctl -xe の順で調査すれば原因の9割が特定できる
・failed の多くは ExecStart のパス誤り・実行権限・依存サービスの未起動が原因
・ユニットファイルを編集したら必ず daemon-reload を実行してから再起動する
・依存関係エラーは After/Requires の見直しか、依存先サービスの修正で解消できる

この記事のポイント

・まず top/uptime でロードアベレージの傾向を掴む
・CPU 高負荷なら top の %us/%sy/%wa の内訳で方向を絞る
・メモリ不足は free -h の available 欄とスワップ使用量で判断する
・ディスク待ちは iostat -x で %iowait と %util を確認する

この記事のポイント

・cronのログを journalctl -u crond で即座に確認する
・「手動でOK・cronでNG」はほぼ PATH 未設定が原因
・実行権限（chmod +x）と行末の改行コードも必ず確認
・/var/log/cron が空なら crond 自体が停止していないか確認する

この記事のポイント

・dfコマンドで「どのパーティションが満杯か」を最初に把握する
・duコマンドで「容量を食っているディレクトリ」を絞り込む
・ログ・コアダンプ・古いバックアップが原因の大多数を占める
・削除前に必ずファイルの用途を確認してから実施する

この記事のポイント

・ rsyslog.conf はファシリティ.プライオリティ＋アクションの組み合わせで書く
・ @@サーバーIPでTCP転送、@サーバーIPでUDP転送を切り替えられる
・ filterとtemplateでログの整形・選別・個別ファイル保存が可能
・ トラブル時は rsyslogd -N1 で設定ファイルの構文エラーを検出できる

この記事のポイント

・ログは「エラー行前後30行」に絞り、コンテキストとセットで渡す
・journalctl -xe --no-pager でページング解除して貼り付け可能な形式にする
・IPアドレス・ホスト名・パスは貼る前にマスキングする
・AIは「原因候補の列挙」には強いが「確定診断・対処コマンドの実行」には使わない

この記事のポイント

・fuser /mnt でマウントポイントを掴むプロセスを特定できる
・fuser -v でユーザー・コマンド名付きの詳細表示になる
・fuser -k -TERM /mnt でプロセスにSIGTERMを送って終了できる
・fuser 80/tcp でポート占有プロセスを特定できる（要root）

この記事のポイント

・RHEL10でrootパスワードを復旧する2つの方法を解説
・GRUBから init=/bin/bash を使ったシングルユーザー的な起動手順
・ISOレスキューモードから chroot でパスワード再設定する手順
・SELinuxの .autorelabel が必要な理由と忘れた場合の影響

この記事のポイント

・htopはtopの上位互換、カラー表示と矢印キー操作で直感的に使える
・F9でシグナル送信、F6でソート基準変更が即時にできる
・treeビュー(F5)で親子関係を追えば暴走プロセスの根元が分かる
・RHEL系はEPELリポジトリ、Ubuntu系はapt1発でインストール可能