Fessが起動せず、すべてのURLが404になる一方で、Javaプロセスと待ち受けポートは残っていることがあります。Webアプリケーションの初期化に失敗したとき、プロセスを終了コード1で止めるための変更が進んでいます。
ポートが開いているだけでは起動成功と分からない
たとえば起動時にOpenSearchへ接続できず、待ち時間内にWebアプリを初期化できない場合でも、Tomcat本体は動き続けることがあります。失敗したコンテキストへ要求すると404になりますが、サービス管理やコンテナの再起動ポリシーはプロセスが生きているため反応しません。
PR #3710ではTomcat起動後に各Webアプリの状態を調べ、利用可能でないものがあれば、標準エラーへlogs/fess.logを参照するメッセージを出してSystem.exit(1)で終了する処理を加えています。新しい有効化設定はありません。
マージ済みの変更だけでは不足する
ランチャーのFessBootは限定されたクラスパスで動きます。#3710の失敗判定がコアライブラリのStringUtilを参照したため、実際の配布物ではNoClassDefFoundErrorとなり、Tomcatのスレッドが残る問題が報告されています。
運用では失敗検知と再試行条件を確認する
修正がそろった配布物を使う段階で、検証環境から接続不能な検索エンジンを指定し、メッセージと終了コード1を確認します。正常に起動する場合に終了しないことも対で確認します。
Fess自身が接続先を修復して自動復旧する機能ではありません。再起動するかどうかはsystemdやコンテナ側のポリシーに依存します。検索エンジンのURL、接続・認証エラー、fess.logとコンソールの原因を先に確認し、再試行の間隔や上限も運用に合わせます。
この確認が済むまでは、プロセスの存在やTCPポートだけに頼らず、アプリケーションの応答も監視します。既存の外部OpenSearch向けsystemd起動依存関係の変更とは、確認する段階が異なります。