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

この記事のポイント

・vm.swappiness（0～100）でスワップの積極使用度を制御できる
・データベース・キャッシュサーバーには1か10が推奨される
・/proc/meminfoのMemAvailableが「使える空きメモリ」の正しい値
・sysctl -wで即時変更、/etc/sysctl.dに書けば永続化できる

この記事のポイント

・rmでディスクが空かないのは、プロセスがそのファイルをまだ開いているから（inode参照カウント）
・dfとduの差が大きい時は lsof | grep deleted で削除済み・開放待ちファイルを特定する
・プロセスを止めずに解放するには truncate -s 0 /proc/PID/fd/FD を使う
・logrotateのcopytruncateオプションはこの仕組みを応用した設計

この記事のポイント

・RHEL系はupdate-ca-trust、Ubuntu系はupdate-ca-certificatesで追加する
・証明書はPEM形式（BEGIN CERTIFICATE行）が前提、DERは変換が必要
・追加後はopenssl verify / curlで必ず動作確認する
・JavaアプリはOSトラストストアとは独立したkeytoolの設定が別途必要

この記事のポイント

・THP有効時、Redis・DBの周期的遅延・レイテンシスパイクが発生する
・THPはsysfsでneverに設定し、systemdユニットで永続化する
・vm.nr_hugepagesでヒュージページ数を確保し/proc/meminfoで監視する
・PostgreSQLはhuge_pages=onで適用、RedisはTHP無効化のみで警告が消える

この記事のポイント

・/proc・/sys・/dev のbindマウントを先に済ませないとchrootの中でコマンドが失敗する
・LVM構成では vgchange -ay でVGをアクティブにしてからマウントする手順が必須
・rootパスワードリセット・dnf reinstall・grub2-install はchrootの中から実行できる
・exitの後は bindマウントを逆順でumountしてからrebootすること

この記事のポイント

・Type=simpleはフォアグラウンド常駐プロセスに使い、forkするデーモンには使わない
・Type=forkingでは必ずPIDFileを指定しないとsystemdがプロセスを見失う
・Type=notifyはsd_notify()対応プログラムで最も確実な起動確認ができる
・Type=oneshotはRemainAfterExit=yesと組み合わせて一回限り実行スクリプトに使う

この記事のポイント

・dnf provides '*/コマンド名' で提供パッケージを特定できる
・rpm -qf でインストール済みファイルの属するパッケージを確認できる
・which / type コマンドで PATH 問題かパッケージ未導入かを切り分ける
・netstat・ifconfig は net-tools、iostat・sar は sysstat で解決できる

この記事のポイント

・somaxconnのデフォルト128は高負荷サーバーには低すぎる。4096以上を推奨
・tcp_tw_reuseはNATやロードバランサー配下では有効だが設定前に動作確認が必要
・tcp_rmem/tcp_wmemを広げると帯域効率は上がるがメモリ使用量も増える
・変更は/etc/sysctl.d/に.confを置いて永続化し、sysctl -pで即時反映する

この記事のポイント

・fioで「ディスクの実力値」を事前計測しておくと障害時の判断基準になる
・シーケンシャルはbs=1M iodepth=1、ランダムはbs=4k iodepth=32が定番パラメータ
・--direct=1を忘れるとRAMを測定してしまい、実際のディスク性能が分からない
・bw（帯域）・IOPS・clat（完了レイテンシ）の3指標を読めれば実用上十分

この記事のポイント

・nf_conntrack_max枯渇は "table full, dropping packet" というdmesgログで検知できる
・現在の使用数は /proc/sys/net/netfilter/nf_conntrack_count で確認できる
・nf_conntrack_maxはRAM(GB)×65536を目安にsysctlで増やして永続化する
・TCP ESTABLISHED のタイムアウトを短縮するとエントリを大幅に削減できる

この記事のポイント

・TIME_WAIT は正常なTCP終了で発生し、ss -ant | awk '{print $1}' | sort | uniq -c で状態別に集計できる
・TIME_WAIT 大量発生は tcp_tw_reuse 有効化と ip_local_port_range 拡張で緩和できる
・CLOSE_WAIT はアプリ側の close() 漏れが原因で sysctl では根本解決にならない
・Webサーバーの keepalive_timeout を設定し、短命接続の繰り返し自体を減らすのが最も効果的

この記事のポイント

・WindowsのZIPはShift_JIS（CP932）でファイル名を保存するため、Linux展開時に文字化けする
・RHEL系では unzip -O CP932 でエンコーディングを指定して展開できる
・Ubuntu系は標準 unzip が -O を非サポート。unar コマンドで自動判定展開が最も手軽
・展開済みで文字化けしてしまった場合は convmv でファイル名を後から変換できる

# CP932（Shift_JIS）で作成されたZIPをデフォルト設定で展開した場合
$ unzip windows_data.zip
Archive:  windows_data.zip
  inflating: ???_20240901.csv
  inflating: ???_??.xlsx

この記事のポイント

・SSH接続遅延の原因はUseDNS・GSSAPIAuthentication・ネットワーク経路の3パターン
・ssh -vの出力からどのフェーズで止まっているかを正確に特定できる
・UseDNS no / GSSAPIAuthentication noの2行で大多数の遅延が解消する
・繰り返し接続が多い運用ではControlMasterのセッション多重化が効果大

この記事のポイント

・cgroupv2はsystemdと統合済み — UnitファイルでCPU・メモリを制限できる
・CPUQuota=50% でCPU使用率を1コアの50%に上限設定できる
・MemoryMaxを超えたプロセスはOOMKillerによって強制終了される
・systemctl showとsystemd-cgtopで設定値と実使用量を確認できる

この記事のポイント

・/proc/sys/fs/file-nr でシステム全体のFD使用数を即座に把握できる
・lsof でFDを大量消費しているプロセスをPID別に特定できる
・limits.confとLimitNOFILEの2箇所を設定しないと恒久化されない
・上限を「unlimited」に設定するのは危険——必ず具体的な数値を入れる
・FDが時間とともに増え続ける場合はアプリのFDリークを疑う

この記事のポイント

・perf record でサンプリングし perf report で関数レベルのホットスポットを特定できる
・perf stat でキャッシュミス・分岐予測ミスなど CPU イベントを数値で計測できる
・Permission denied は /proc/sys/kernel/perf_event_paranoid を 1 に緩めると解消する
・カーネルシンボルが [unknown] になる場合は debuginfo パッケージの導入が必要

この記事のポイント

・mpstat -P ALL 1 でコア別CPU使用率を1秒ごとに確認できる
・sysstatパッケージをインストールするだけで即使える（RHEL/Ubuntu両対応）
・%iowait高 → I/O待ち、%irq・%soft高 → ネットワーク割り込み集中が疑われる
・sar・iostatと同パッケージで、コア別の過去データ分析も可能

この記事のポイント

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

この記事のポイント

・OOM Killerの発動は dmesg | grep -i "out of memory" で即確認できる
・Kill対象はoom_scoreが高いプロセス（/proc/PID/oom_scoreで確認）
・oom_score_adjを-1000にするとそのプロセスはKill対象から外れる
・systemdサービスはOOMScoreAdjust=-1000とMemoryMaxを組み合わせて永続保護する

この記事のポイント

・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枯渇の三大原因
・削除してもエラーが解消しない場合は幽霊ファイル・予約領域・tmpfsも確認する

この記事のポイント

・削除直後はディスクへの書き込みを止めることが最優先——追記するほど復元率は下がる
・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発でインストール可能