Ubuntu-Server 20.04でcron jobが動かない

はじめに

ここ数年、サーバの管理というかサービス群はコンテナ化して運用するようにしている。
なのでサーバも基本的にDockerが動けばよい設定にしている。

Dockerを動かすOSは別に何でも良いのだけどUbuntu-Serverが構成がシンプルなので好んで使っており、最近はほぼほぼこれしか使わない。
OSのインストール時にもSSHサーバを入れるだけで後は何も入れない。しかしシンプルが故に手を加えなければならないところもある。
今回の議題もそれに関連しているかと思う(Ubuntu-Desktopとかなら問題にならないんじゃないのかな)。

さて、本題。
Linuxサーバをお守りしていると必然的にcron job(以下cron)の世話になる。
ローカルのコマンドから実行できるのにcronになると動かないというのは「cronあるある」でこれまでも嫌と言うほど体験してきた。
この場合は環境変数を読み込んでいないとかいろいろあるのでそこは他の情報を参照していただくとして。今回

「Ubuntu-Server 18.04で動く仕組みをそのまま20.04に移植したら動かない」

という現象に少し悩まされたのでその解消方法を述べる。

やったこと

私の場合cronの設定はユーザ単位で行うのを基本としており、システムのバックアップなどroot権限が必要な場合も同様である。
しかし設定ファイルが/etc/にまとまっているほうが管理しやすいので近年は/etc/cron.dを使うことが多い。

/etc/cron.dは以下のように実行ユーザを指定できる(この場合はroot)。

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

30 1 * * * root /bin/sh /usr/local/bin/backup.sh 1>>/var/log/cron.log 2>>/var/log/cron_error.log

これでうまく運用していたのだが新しいサーバに移植するとどうも実行した形跡がない。
/var/log/syslogを参照してもよくわからないのだ。

エラーをメールで飛ばすことも一般的だがmailutilsをインストールしなければならないしエラーログのためだけに導入するのも躊躇する。

ところが同じジョブを以下だと動くことがわかった。

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

30 * * * * root /bin/sh /usr/local/bin/backup.sh 1>>/var/log/cron.log 2>>/var/log/cron_error.log

二つの違いは先のものが「午前1時30分に実行」。後のものが「毎時30分に実行」となり時間指定の有無が違う。
書き方によって動くということはスクリプト自体には問題がないことがわかる。

そうなると時刻が正しくとれていないことが予想される。

解決方法

タイムゾーンの設定

20.04をインストールしたときのデフォルトのタイムゾーンがUTCになることは知っていた。なので

sudo apt-get install tzdata
sudo timedatectl set-timezone 'Asia/Tokyo'

という作業はすでに終えている。
「Ubuntu 20.04 LTSでタイムゾーンを変更する方法」で書いてあるのも同じ内容である。

サービスの再起動

cronのサービスを念の為再起動する。

systemctl restart cron.service

しかし直らない。
そこでよくよく/var/log/syslogを見るとログのタイムスタンプがUTCのままなのだ。

じゃあここは

sudo /sbin/shutdown -r now

で無事syslogのタイムスタンプも直った。めでたしめでたし。
といいたいが、わざわざサーバの再起動が必要なのかという疑問にぶち当たる。

そして調べた結果。

正しくはこうしよう

rsyslogの再起動

systemctl restart rsyslog.service

まとめ

cron jobがうまく動かなときは以下を確認

• コマンドラインから実行して確認するが基本的に絶対パスで表記し、実行場所が特定のディレクトリに依存しないようにする
• /var/log/syslogの内容を確認`
• 環境変数やPATHは通っているか(shellスクリプトなら冒頭に. /etc/profileと読み込ませるのもあり)
• サーバのタイムゾーンの設定は正しくできているか
• 上記設定がrsyslogのタイムゾーンにも反映しているか

ってとこだろうか。まだまだいっぱいあるだろうけど。

今回の原因はrsyslogの再起動を忘れていたことだった。
なので正確には「動かない」ではなく「意図しない時刻に動く」設定になっていたということ。
また冒頭に書いた18.04ではうまく動いたというのは記憶が曖昧なので当時もゴニョゴニョしたかもしれない。