更新したのに古いプロセスが残る理由｜常駐処理の更新検収

複数の更新対象すべてが新しい版になった。更新処理は成功と終了した。それでも初回の実体確認では、3つの常駐処理が古いPIDのまま残っていました。

これは更新失敗というより、完了条件の置き場所が足りなかった事例です。更新履歴が示すのは、新しい版を配置できたことです。一方、利用者が必要としているのは、いま仕事をしている実行実体が新しい版を使っていることです。この二つは一致するとは限りません。

今回の更新処理は、6か所が版2.1.210になったことを示していました。再起動操作も成功として終了しています。しかし、動作中の実体を照合すると、3つの常駐処理は古いPIDのままでした。ファイルを入れ替えても、すでにメモリ上で動いている常駐処理まで自動で置き換わるとは限らないためです。

「更新済み」と「稼働中」を別の列で見る

更新後の検収では、少なくとも次の三点を混ぜずに扱います。

復旧後の照合では、ある環境でbridgeと3つの常駐処理、計4つのPIDが版2.1.210を指していることを確認できました。別の環境でも、bridgeと常駐処理の2つのPIDが同じ版を指していました。

一方で、再起動は「新しく動かす」だけの操作ではありません。別の場所では、常駐していた対話処理が2件終了しました。更新対象のうち、常駐処理を持たない3か所は更新済みを確認でき、別の1か所は更新後に休止状態へ戻りました。

つまり、再起動成功という表示だけでは、必要な仕事が続いているかまでは判断できません。停止が正しい場合もありますが、意図した停止か、復帰可能な停止かを別途確認する必要があります。

常駐プロセスの更新確認は、実体から始める

確認の順序を固定すると、成功表示だけで判断しにくくなります。

1. 更新対象を列挙する
2. そのうち常駐処理を持つ対象を列挙する
3. 稼働中の実行実体と版を照合する
4. 更新前後でPIDが入れ替わったか、止まった処理がないかを確認する

PIDの変更そのものを絶対基準にする必要はありません。重要なのは、いま動いている実体が意図した新しい版を指していること、そして必要な作業が失われていないことです。

ファイルの存在や更新時刻だけでは、生きている処理の状態を証明できません。この考え方は、先行する死活監視は「プロセス」を見よ — ファイルの存在は生存証明ではないともつながります。更新検収でも、記録された結果より先に、現に動いているプロセスを観測する必要があります。

自動化の完了条件に、復帰点を含める

常駐処理に対する更新では、開始前に「止まったら困るもの」を洗い出しておくと判断が安定します。対話中の仕事や長時間処理があるなら、再開方法と記録の保全対象を先に決めます。

ここでの要点は、再起動を避けることではありません。更新、再起動、実行実体の照合を一つの検収単位として扱うことです。再起動後に休止へ戻る処理も、意図どおりなら問題ではありません。反対に、更新済みと表示されていても、古い実体が残っていれば検収は終えられません。

更新検収のチェックリスト

• 更新対象ごとに、新しい版へ更新された結果を確認する
• 常駐処理を持つ対象を、更新結果とは別に一覧化する
• 稼働中の実行実体が新しい版を指すことを確認する
• 更新前後で残ったPIDや、意図しない停止がないかを確認する
• 中断した対話・作業について、記録の保全と復帰可否を確認する

更新済みと稼働中は別物です。自動化の完了条件は、更新履歴を読むところではなく、「動いている実体が新しい版を指している」と確認できるところまで置くべきです。

更新したのに古いプロセスが残る不安を減らすには、再起動成功をゴールにせず、更新結果・稼働実体・中断された仕事の復帰可否を別々に照合してください。