クライアントを起動すると、端末に Segmentation fault (core dumped) と表示され、次の一時間はカードの再書き込みに消える。このメッセージが示すのは、ある瞬間に一つのプロセスがどのように死んだか、ということだけだ。基板が壊れたとも、電源・ストレージ・イメージに問題がないとも言っていない。

シェルが表示した行から、その背後にあるプロセスへ遡る。役に立つ事実は、どの実行ファイルが、どの環境で、接続のどの段階で失敗したかだ。

シェルが表示した行から始める

コマンドの名前は別のバイナリを起動するラッパーやランチャーであることが多いので、カーネルが実際に終了させた実行ファイルを確認する。完全なパス、パッケージとアプリケーションのバージョン、アーキテクチャ、OS とカーネルのリリース、起動したアカウント、正確な時刻を書き留める。VPN の名前を冠したシェルコマンドは補助プロセスを起動しやすく、記録にはその補助プロセスの名前が残る。先月インストールしたパッケージのバージョン文字列を写しても、何が動いたかは分からない。

クラッシュの直前に何があったかを記す。起動、プロファイルの解析、認証、すでに通信を通していたセッションのいずれかだ。この四段階は segfault という語よりずっと探索を絞り込む。その出来事の前後の短いログ範囲を保存し、どの最近の変更が原因かという推測は記録が語るまで伏せる。

メモリイメージが存在するか確かめる

core ファイルのリファレンスは、ダンプを終了時に書き出されるプロセスメモリのイメージと説明し、その書き出しを止める条件も挙げている。条件には、リソース上限がゼロであることや、ダンプを作業ディレクトリ以外へ振り向ける core パターンが含まれる。したがって core という名前のファイルが無いことは、クラッシュが起きたかどうかを何も証明しない。設定されたパターンと上限を確認してから、システムが証拠を残さなかったと結論づける。

systemd のコレクタを使うシステムでは、対応する表示が保存された記録を実行ファイルと時刻に対応づける。ジャーナルの項目と読めるメモリイメージは別物であり、保持ポリシーと権限によって片方だけが残ることがある。別のビルドや別のライブラリ群で取ったトレースは通常は相手の時間を無駄にするので、ディストリビューションやアプリケーションの保守担当に、対応している診断手順を尋ねる。

sysctl kernel.core_pattern
ulimit -c
coredumpctl list --since "1 hour ago" --no-pager
coredumpctl info /usr/sbin/openvpn

これらの読み取りは、実際にクラッシュしたマシンで繰り返す。新しいインストールで行っても、誰も聞いていない問いに答えるだけだ。

ダンプを秘密を含む素材として扱う

プロセスのメモリには認証情報、セッション鍵、プロファイルの内容が入りうるため、ダンプは隣のテキストログより機密性が高い。ログを伏せても不透明なメモリイメージには何の効果もなく、一般の課題追跡システムはサポートのやり取りよりずっと長く添付ファイルを保持する。ファイルはベンダーや保守担当が用意する非公開の経路で移す。公開の課題に生のダンプを貼ると、プロセスの死の瞬間にメモリにあったものがすべて露出し、誰かが調べるまでそれが何かは分からない。

保守担当がトレースを求めたら、どの実行ファイルとどのライブラリのものかを尋ねる。報告されたビルドとフレームが一致しない backtrace は信頼しにくく、読み違えやすい。

何かを交換する前に由来を確かめる

インストールを所有する相手を通じてパッケージの由来とファイルの完全性を検証し、管理された修理の前に設定と識別情報を保存する。クリーンインストールが起動するかを見るためだけに、証拠の唯一のコピーを上書きしない。新しいイメージが起動することは、新しいイメージが起動するというだけだ。古いイメージに壊れたパッケージ、故障中のカード、このアーキテクチャで必ず fault するバイナリが含まれていたかは分からない。

無関係なプログラムも失敗する場合や、システムがストレージ、電源、カーネルのエラーを記録する場合は、その観察をプラットフォーム調査のために残す。範囲は広がるが、すべての segfault が故障した RAM や壊れたイメージ由来だと証明するものではない。

的を絞った修正の後、同じ許可された起動と同じ VPN 操作を同じハードウェアで繰り返す。どの失敗がどのバージョンで止まったかを述べる。クリーンな起動だけでは、欠陥部品を特定できず、次のハードウェア故障も予測できない。

関連記事