定期実行が動かない理由を突き止めろ

師範 / 目安 30分

「毎晩、勝手に売上をまとめてくれるようにしてあったんだ」

鴫原さんが /var/log/yumesaku-uriage.log を開きます。中身は空です。

「先月までは、朝来ると前の晩ぶんが書かれとった。それが1行も増えとらん。仕込んだ覚えはあるし、ファイルも消しとらん。動いとらんのに、エラーも出とらんのが気味が悪い」

定期実行の障害がやっかいなのは、失敗が目の前で起きないことです。手で打ったコマンドなら、エラーはその場で画面に出ます。裏で動く仕掛けが転んだときは、記録を探しに行かないと何も分かりません。

今日の仕事は、まさにその記録の探し方です。

この機械での定期実行は systemd タイマー

定期実行というと cron を思い浮かべる人が多いはずです。ただ、この機械には cron が入っていません。代わりに使うのが systemd のタイマーです。仕組みは cron より少し多い代わりに、はっきりしています。

仕掛けは2つのファイルの組でできています。

• <名前>.service — 何をするか。実行するコマンドを ExecStart= に書きます
• <名前>.timer — いつ動かすか。時刻を OnCalendar= に書き、動かす相手として同じ名前の .service を指します

置き場所は /etc/systemd/system/ です。まず何が仕込まれているかを見ます。

仕込んだだけでは動かない

ここが第一の落とし穴です。ファイルを置いただけでは、systemd はそのタイマーを動かしません。動かすには、次の予定に登録させる必要があります。いま登録されているタイマーの一覧は次で見えます。

NEXT の列に次回の予定、LAST の列に前回動いた時刻が出ます。ここに自分のタイマーの名前が出てこないなら、そもそも登録されていません。登録するのが enable、いますぐ動かし始めるのが start です。両方を一度にやるなら次のように書きます。

単体の状態は is-enabled と is-active でも確かめられます。

動き始めても、中身が転ぶことがある

第二の落とし穴です。タイマーが正しく登録されていても、呼ばれた .service のほうが失敗すれば結果は同じで、ログは1行も増えません。

定期実行を待たずに、.service だけを手で動かして試せます。これが調査の要になります。

失敗していれば failed と出ます。なぜ失敗したかは、そのユニットのログにあります。

-u はユニットの指定です。付けずに打つと機械全体のログが流れてきて、目的の行を見失います。-n 30 は末尾30行、--no-pager はページャに入らない指定です。

ここで出てくるエラーは、道場でもう見たことのあるものです。定期実行だからといって特別な失敗をするわけではありません。手で打てば一目で分かる失敗が、見えない場所で起きているだけです。だから手で動かして見えるようにする、というのが今日の勘所です。

完成条件

1. 売上まとめのタイマーが enable かつ active になっていること
2. systemctl list-timers の一覧に、そのタイマーが出てくること
3. 呼ばれる .service が失敗せずに終わること
4. 実際に /var/log/yumesaku-uriage.log に売上のまとめが書かれていること

進め方

原因は1つとは限りません。1つ直したら systemctl start で試し、また転んだらログを読んでください。

ヒントは3段階で、①方針、②使うコマンド、③部分解の順に出ます。1つも開けずに通せたら、その問題は自分のものです。

1. yumesaku-uriage.timer が enable かつ active になっていること
2. systemctl list-timers の一覧にそのタイマーが出ること
3. yumesaku-uriage.service が失敗せずに終わること
4. /var/log/yumesaku-uriage.log に売上のまとめが書かれていること
5. 原因は1つとは限りません。直しては試し、を繰り返してください