cron flock 二重実行 apt 通知 来ない・重複するときの確認手順

cronがexit 0なのにapt週次通知が来ないなら、まず外側のcronと内側の通知スクリプトが同じlockを二度取得していないかを疑います。内側は「多重実行を避けた」と判断してexit 0で終われるため、cron監視だけでは空振りを成功と誤認します。逆に同じ通知が重複する場合、二重flockそのものより、通知ジョブへの起動経路が複数ある状態を先に切り分けます。

aptの週次助言は、毎週必ず送るものではありません。security更新、中核パッケージ、再起動待ちなどの条件に当たったときだけ通知し、通常は沈黙する設計です。したがって「通知なし」を障害と決めず、判定処理が通知対象を評価する地点まで到達したかを確認してください。

原因：exit 0は「通知を判定した」の証拠ではない

外側のflockがsame.lockを取得したままworkerを起動し、workerも同じsame.lockを取ろうとすると、workerはlock衝突として処理をSKIPできます。このときログにanother instance holds the lockを残しつつexit 0になる構成があります。

既存の再現では、同じlockを外側・内側で使うとprocessed=0が出ず、外側のlockを別名にするとprocessed=0が出ました。両方とも終了コードは0です。見るべきなのは終了コードではなく、本体が出した仕事量です。

確認コマンド

本番のlockを変更せず、まずcron設定とworker内のflock指定を並べて確認します。

crontab -l
rg -n "flock|lock" /home/USER/bin/worker.sh

cron側とworker側に同一のlockパスが現れたら、二重取得の候補です。次に、通知ログでlock衝突、評価件数、送信件数を同じ実行時刻に照合します。

rg -n "another instance holds the lock|evaluated=|processed=|sent=" /home/USER/log/example-job.log

パス、ログ名、出力キーは各環境の実装に合わせて要確認です。lockを分けるなら、外側は「定期ジョブ全体」、内側は「処理固有の共有資源」のように責務を分け、名前だけでなくコメントにも残します。

確認手順チェックリスト

1. cronの終了コードだけで成功と判定していないか確認する。
2. 外側と内側のflockが同じlockファイルを指定していないか確認する。
3. another instance holds the lockの直後に、評価件数や送信件数がないことを確認する。
4. 通知なしなら、更新候補の評価結果が0件なのか、評価前にSKIPしたのかを分ける。
5. 通知重複なら、cron、手動実行、別スケジューラなど、起動経路を時刻とlock名で照合する。

apt通知は「週次で調べ、例外時だけ鳴らす」運用なら、評価済みの沈黙は正常です。一方、評価件数そのものが記録されない沈黙は、通知条件ではなくジョブ到達性の問題として扱います。

よくある質問

exit 0ならcronは正常ですか？

プロセスとして正常終了したことは示しますが、apt候補を評価して通知条件を判定したことまでは示しません。evaluated=やsent=など、仕事量を残して判断します。

更新候補があるのに通知されないのは故障ですか？

必ずしも故障ではありません。週次助言がsecurity更新や中核更新などの例外時だけ通知する設計なら、条件外の候補だけでは沈黙します。評価結果が記録されているかを先に確認します。

通知が重複したらlock名を同じにすれば直りますか？

安易に同じlockへ統一すると、外側と内側の二重取得で全処理がSKIPするおそれがあります。まず複数の起動経路を特定し、残すlockごとに守る対象を分けてください。

関連する記事

• cronがexit 0なのに処理されない原因――flock二重取得を最小再現する
• apt更新を自動適用せず週次で通知する方法――沈黙を既定にしたパッチ助言
• cron監視の対象一覧を自動化する方法――鮮度判定と誤報の落とし穴
• cronのSKIPが連続して処理が止まる時の監視設計