サーバークラッシュ Server process crash

原因ID sp-crash · 主担当 ゲーム開発チーム・サーバー開発 · 副担当インフラチーム・サーバーインフラ

未処理のエラーでサーバープロセスが落ちると、そのサーバーにいた全員が同時に切断されます。

なぜ存在しない対象を参照するエラー（null参照）、不正なデータ、メモリ不足などの致命的なエラー → すると サーバー（またはゾーン）のプロセスが終了 → 画面では 全員が同時に切断、最後の保存以降の進行はロールバックされることがある

症状: 切断, 不発・ロールバック
要因: ストール
誰に起きるか: 特定の場所・チャンネル, サーバー全体
いつ: ときどきランダムに, 特定の操作をしたとき
担当: 主担当 ゲーム開発チーム・サーバー開発 · 副担当インフラチーム・サーバーインフラ
ゲーム開発チームの対応: クラッシュダンプの分析による原因の修正、こまめな保存。
インフラチームの対応: プロセスの自動再起動、クラッシュダンプの収集・保管環境、サーバーダウン時の即時アラート。
グラフでは: 接続が一斉に切れる · 接続数、プロセスの再起動回数
確認箇所: coredumpctl listのコアダンプ記録（時刻、PID、終了シグナル）と、サービスマネージャー（systemd）の異常終了・再起動の記録。WindowsサーバーはWERが残したダンプファイル
該当する場合: 接続数が一瞬で0近くまで落ちた時刻に、ゲームサーバープロセスの異常終了とコアダンプがある
該当しない場合: プロセスは動き続けているのに接続が切れたなら、ネットワーク機器・アイドルタイムアウトの側。長く止まった後にウォッチドッグが再起動した記録なら、無限ループ・デッドロックの側
確認手段: インフラのツールで確認（ゲームコード不要）

出典

Collecting User-Mode Dumps Microsoft
Windowsエラー報告（WER）で、ユーザーモードのプログラムがクラッシュしたときにフルダンプ・ミニダンプをローカルに収集するよう設定
systemd.service(5) — Linux manual page systemd
Restart=on-failureは、異常終了・シグナルによる終了（コアダンプを含む）・ウォッチドッグのタイムアウト時にサービスを自動再起動、長時間動くサービスに推奨
coredumpctl(1) — Linux manual page systemd
systemd-coredumpが保存したコアダンプをlistで一覧表示、クラッシュの時刻・PID・クラッシュを起こしたシグナルを表示