cronから大量のメールが届く：止める前に読むこと

レン

cronを設定してから、同じメールが毎回届くようになった。うるさいから止めたい…

プロクラ

止める前に、一度だけ中身を読んでみて。定期実行から通知が来るのは「出力があったとき」なんだ。何も出力しなければ、メールは来ない。つまり、何かを言おうとしている状態だよ。

まず中身を確かめる

• エラーが出ている → 処理が失敗し続けている。止めるべきはメールではなく原因
• 正常な出力が出ている → 処理は動いている。出力を捨てる設定にすればよい
• 「command not found」 → パスの指定が抜けている典型
• 「Permission denied」 → 実行するユーザーの権限が足りていない

プロクラ

3つめと4つめは、定期実行で最も多い失敗だよ。手で打つと動くのに定期実行だと動かない、という症状の正体でもある。メールを止めてしまうと、この事実に気づけなくなる。

出力の扱いを決める

プロクラ

中身を確認して、処理自体が正常なら、出力の扱いを整えよう。全部黙らせるのではなく、失敗したときだけ知らせる形が理想だよ。

• 通常の出力だけを捨て、エラーは残す（失敗時のみ通知が来る）
• 両方をログファイルへ書き出し、メールは出さない
• 両方を完全に捨てる（推奨しない。失敗に気づけなくなる）
• ログへ書き出す場合、そのログの自動削除も設定しておく

プロクラ

1つめが現実的な落としどころだね。うまくいっている間は静かで、失敗した瞬間に届く。これなら、メールが来たこと自体が意味を持つ。

失敗が続いていた場合

プロクラ

確認した結果、ずっと失敗していたなら、その処理は最初から動いていなかったということだよ。バックアップの処理だったら、控えが1つも無い状態だったことになる。

• その処理が何のためのものだったかを確認する
• バックアップ系なら、実際にファイルが作られているかを見る
• 作られていなければ、いつから止まっていたかを調べる
• 直したあと、次回の実行で成功するところまで見届ける

溜まったメールの後始末

• 件数が多いと、それだけでディスクを使う
• 内容を確認したら消してよい
• 同じ件名が大量に並んでいるなら、原因は1つ
• 消す前に、直近のものを1件だけ残して読んでおく

レン

うるさいメールは、失敗の知らせだったんだ。読んでから止める。

通知が来ないことにも意味がある

プロクラ

失敗時だけ通知する形にしたら、今度は「通知が来ない＝正常」と読めるようになる。ただし、これは通知の仕組みが生きている場合の話だよ。

• 定期実行そのものが止まっていれば、失敗の通知も来ない
• メールが送れない状態になっていても、来ない
• つまり「静か」には2種類ある
• 成果物（バックアップのファイル等）が更新されているかを、時々見る

プロクラ

通知だけに頼らず、結果そのものを月に一度でも確認する習慣があると、この落とし穴を避けられるよ。