サーバーのプロセス番号がいつの間にか変わっていた ― 理由を後から追えるよう、起動・停止・異常終了の記録を残した話
J-WORKSの社内システムを動かしているサーバーのプロセス番号(PID)が、気づくと何度か変わっていた。サーバーが異常終了したのか、意図して再起動したのかを後から確かめようとしたが、どこにも記録が残っておらず追跡できなかった。そこで、サーバーの起動・停止・異常終了を毎回ファイルへ書き残す仕組みを作った記録。
検証条件
J-WORKSでは、SNS投稿・記事生成・商品づくりなどを動かす社内システムを、社内のパソコン上でサーバーとして常時動かしている。ある時、このサーバーのプロセス番号(OSが動いているプログラムに付ける番号。再起動すると別の番号になる)が、7072から216、さらに20828へと、いつの間にか変わっていることに気づいた。番号が変わったということは、サーバーが一度止まって起動し直したということである。問題は、それが誰かの意図した再起動だったのか、それとも何かのエラーで落ちたのかを、後から確かめる手段が無かったことだった。
実行内容
まず、社内のデータベースとプログラムの両方を調べ、起動や停止を記録している箇所が無いかを確認した。結果として、サーバーの起動時刻を画面に表示する処理はあったものの、起動・停止・異常終了をどこかへ残す処理は一切無く、過去のプロセス番号の切り替わりについては原因を確定できなかった。「何かがおかしい」と気づいた時点では、もう手がかりが残っていなかったことになる。そこで、今後同じことが起きたときに追えるよう、記録の仕組みを作ることにした。プロセス番号が変わる理由には、大きく分けて、運営者や自動の仕組みが意図して再起動した場合と、プログラムがエラーで落ち、その後に起動し直された場合がある。前者であれば問題は無いが、後者であれば、落ちた原因を突き止めないと同じことが繰り返される。この2つを見分けるには、止まる直前に何が起きたかの記録が要る。
結果
次の出来事を、1行に1件ずつ、追記のみのログファイルへ書き残すようにした。サーバーの起動(起動時刻・実行環境など)、プログラムのどこでも捕まえられなかったエラー、処理されないまま失敗した非同期処理、停止の指示(OSからの終了要求やキー操作による中断)、そして停止の完了である。捕まえられなかったエラーが起きた場合は、記録を残したうえでサーバーを終了させる設計にした。状態がおかしくなっている可能性のあるプログラムを、そのまま動かし続けないためである。停止の指示を受けた場合は、新しい受付を止め、処理中の通信には少し猶予を与えてから終了し、5秒たっても終わらなければ強制的に終了するようにした。
失敗原因
直接の原因は、そもそも起動・停止・異常終了の記録を残す仕組みが無かったことにある。サーバーが正常に動いている間は困らないため、こうした記録は後回しになりやすい。しかし、原因を調べたくなるのはいつも「何かが起きた後」であり、そのときに記録が無ければ、何が起きたかを推測するしかなくなる。
改善
記録先には、社内のデータベースではなく専用のログファイルを選んだ。理由は2つある。1つ目は、社内の別の仕組み(その日の出来事をnote記事の材料として集める処理)が、データベース上の運営記録を種類で絞り込まずに記事の材料として取り込む作りになっており、ここへ技術的な起動・停止の記録を書くと、無関係な技術ログが記事に混ざるおそれがあったためである。2つ目は、サーバーが異常終了する場面ではデータベース自体に書き込めない可能性があり、単純なファイルへの追記の方が失敗しにくいためである。このほか、記録の安全のために次の3点を入れた。エラーの文面に認証用の文字列などの秘密情報の形が含まれていれば、伏せ字に置き換えてから書き込む。ログの書き込み自体が失敗しても、その失敗で連鎖的にサーバーが落ちないようにする。記録の処理が二重に登録されないようにする。また、データベースの準備より前に記録の仕組みを動かし始めることで、起動直後の失敗も記録の対象にした。記録処理の二重登録を防ぐ仕組みは、テストの中で本物のサーバーに影響を与えずに確かめられるよう、登録先を差し替えられる形で作った。
現在の結論
2026年9月2日の修正で、サーバーの起動・停止・異常終了が、理由と時刻つきでファイルに残るようになった。過去のプロセス番号の切り替わりの原因は、記録が無かったため今も確定できていない。この経験からの学びは、「おかしいと気づいてから調べるのでは遅い」ということである。自分でサーバーや常駐プログラムを動かしている場合は、何も起きていないうちに、起動・停止・異常終了の記録を残す仕組みを用意しておくことをおすすめする。その際、記録の書き込み自体が新たな障害の原因にならないこと、秘密情報が記録に混ざらないことにも気を配るとよい。記録として最低限残しておきたいのは、(1)起動した時刻とプロセス番号、(2)停止の指示を受けた時刻とその種類、(3)停止が完了した時刻、(4)捕まえられなかったエラーの内容、の4点である。起動の記録があるのに、その直前に停止の記録が無ければ、正常に止まらなかった可能性が高い、と後から判断できる。1行に1件の形で追記していけば、後から時刻順に並べて読むだけで、何が起きたかをたどりやすい。
根拠
2026-09-02(JST)に実装したコード修正の記録(変更内容とコミットメッセージ)と、その修正で追加した自動テスト、およびJ-WORKS社内のノウハウ記録による。