DockerのFess snapshotイメージで docker stop を実行すると、従来の起動スクリプトは停止シグナルをFessへ届けず、待ち時間の後に強制終了することがありました。docker-fess #103・#104は、プロセスが終了したことの検知と、停止要求を受けたときの処理を改めます。
停止時と異常終了時の終了コードを確認する
追加の有効化設定はありません。修正を含むAlpine版では、起動スクリプトが SIGTERM または SIGINT を受けてFessプロセスへ伝え、その終了を待ちます。NobleとAL2023では、サービスの停止スクリプトがJVMの終了を待ちます。いずれもslim版が対象です。
検証環境でヘルスチェックが通った後、docker stop -t 10 <コンテナ名> を実行します。PRのAlpine版・Noble版での試験では、従来は約10秒で終了コード137、修正を含むスクリプトでは約1秒で143でした。PRの実測値はこの構成に限られます。終了後は docker inspect --format '{{.State.ExitCode}}' <コンテナ名> で終了コードを、ログで停止処理を確認できます。
一方、起動失敗などでFessのプロセスが先に終了した場合は、エントリーポイントも終了コード1で止まります。従来は初回のヘルス応答前だと、初期値 PING_INTERVAL=60 秒・PING_STARTUP_RETRIES=10 回のヘルス確認が尽きるまで最長約10分待っていました。変更後のプロセス確認は1秒刻みで、PING_INTERVAL は整数秒で指定します。
停止に時間がかかる場合
停止シグナルの処理が登録されるのはFessの起動後です。FESS_PLUGINS によるプラグインの取得中や、RUN_SHELL=true の対話シェルが動いている間は、すぐには停止処理へ進めません。実行中のヘルスチェックの完了を待つ場合もあります。停止と再起動の挙動は、使っているイメージとコンテナの再起動ポリシーで確認します。