systemd 259で定期処理が起動しない：39バイトの警告ログから見つけた設定互換性

移設先で更新されたログファイルは、ちょうど39バイトでした。ファイルは存在し、予定時刻に更新され、監視も緑です。しかし中身は警告1行だけで、定期処理の本体は一度も起動していませんでした。

共有ホストでは、本体業務を守るため、メモリが逼迫した際に先に落とされる側へ回す優先度指定を定期処理へ付けていました。旧環境では有効だった1行です。移設先のsystemd 259では、一時実行の起動方式がその指定を受け付けず、Unknown assignmentという警告を出して停止しました。

この型が厄介なのは、警告という言葉から「処理自体は動いている」と受け取りやすい点です。実際には警告1行で本体が丸ごと起動せず、発火記録とログ更新時刻だけを見る監視は正常と判定し続けました。移設は、設定を入れた時点では終わりません。

39バイトしかないログが示していたこと

移設先で再作成した定期処理には、メモリ逼迫時の優先度を指定する同じ1行を付けていました。ところがsystemd 259では、一時実行の起動方式に対してその指定を受け付けませんでした。

残ったのはUnknown assignmentという警告1行だけです。設定の書式が崩れていたわけではなく、旧環境では実際に効いていた記述でした。実行環境の版と起動方式が変わったことで、同じ設定が通らなくなりました。

この状態で、導入以来一度も走っていなかった処理が4本ありました。ログの更新時刻はいずれも初回予定時刻と一致していました。監視ではなく、「旧環境の動作はすべて移ったか」を調べる棚卸しで発見しました。気づくまでに1日以上かかっています。

警告なのに、何も始まらない

エラーで明確に終了するなら、終了状態やエラーログを監視対象にして拾いやすくなります。今回は異なりました。発火記録があり、ログファイルも更新されるため、死活判定の前提を満たしたまま仕事だけをしていません。

移設作業で見るべきなのは、「設定が配置されたか」だけではありません。予定された最初の実行で本体が起動し、期待した記録が残ったかまでを完了条件に置く必要があります。

前回の旧側の定期処理が動き続けて二重になった記録では、動き続けても当日は目立った問題になりませんでした。今回は逆に、一度も動かなくても当日は静かでした。移設直後の不具合には、静かに重複する型と、静かに欠落する型があります。

1本直しても、同じ設定は直っていなかった

実は同じ罠を先に踏んだ処理が1本あり、それは即日で修正済みでした。しかし、その修正を同じ書き方をした処理全体へ広げませんでした。結果として、残り4本が止まったままになりました。

1件の設定互換性問題を見つけたときは、個別の復旧と同時に、同じ記述を使う対象を横並びで数える必要があります。修正済みの1本は安心材料になりますが、同じ設定が残っていれば、むしろ発見を遅らせることがあります。

恒久修正では、起動方式に依存する優先度指定をやめ、各処理の先頭で自分自身の優先度を直接書く方式へ差し替えました。修正後は正常起動の記録が83行まで積み上がり、警告だけで終わる状態から抜けたことを数字で確認できました。

移設完了の基準を変える

今回から、定期処理の移設完了は「登録した」ではなく「初回発火が成功し、その内容をログで確認できた」と定義し直しました。少なくとも、発火記録と更新時刻だけで完了にしないためです。

なお、死活判定を終了コードや成果物の有無まで見る改善には、まだ手を付けられていません。そのため、ログだけを更新して仕事をしない別の型が起きる余地は残っています。移設前に元側が静かに壊れた事例も、バックアップ用マウントが静かに失敗した記録として残しています。

移設後に行う最小限の点検

• 同じ設定を使う定期処理を一覧にして、1本の修正で終わらせない。
• 初回予定時刻の後にログを開き、更新時刻ではなく本体の正常起動記録を見る。
• 警告が出た場合は、警告の後に本体処理が続いたかを分けて判断する。

移設先の版が変わると、設定は壊れるのではなく、黙って無効になることがあります。次回は、多重起動を防ぐ仕組みが自分自身を弾き、「何もせず正常終了」を返し続けた件を扱います。

まずは移設済みの定期処理を一つ選び、次の実行後にログの中身を開いてください。更新時刻ではなく、処理が実際に始まり、終わった記録があるかを見るのが最初の一手です。