cronのクラスタリングサポート（CentOS7）

ある日、突如 cron に疑問を感じ man cron を実行してみた。 たまたま CentOS7 だったのだが、「CLUSTERING SUPPORT」なるセクションがありびっくりした。 cronでクラスタリングとな！

びっくりしたのはいいが、実際に何をやってくれるのかはさっぱりわからなかったので和訳してみることにした。

以下、和訳。間違いがあればすいません。

*1

クラスタリングサポート

In this version of Cron it is possible to use a network-mounted shared /var/spool/cron across a cluster of hosts and specify that only one of the hosts should run the crontab jobs in this directory at any one time. This is done by starting Cron with the -c option, and have the /var/spool/cron/.cron.hostname file contain just one line, which repre- sents the hostname of whichever host in the cluster should run the jobs. If this file does not exist, or the hostname in it does not match that returned by gethostname(2), then all crontab files in this directory are ignored. This has no effect on cron jobs specified in the /etc/crontab file or on files in the /etc/cron.d directory. These files are always run and considered host-specific.

本バージョンの cron はネットワークマウントされた共有の /var/spool/cron を クラスタのホストをまたがって、どの時点においても一つだけのホストが実行すべき ジョブを実行することができる。これは -c オプションを与えて cron を起動すれば 実現できる。そして、/var/spool/cron/.cron.hostname に一行だけあれば そこに属するクラスタのいずれかのホストがジョブを実行すべきジョブを実行する。 もし、このファイルがないか hostname が gethostname(2) にマッチしない場合、 このディレクトリにあるすべての crontab ファイルが無視される。これは、/etc/crontab や /etc/cron.d 以下を対象とした cron の動作に影響を与えない。それらのファイルは 常に特定のホスト上で実行される。

Rather than editing /var/spool/cron/.cron.hostname directly, use the -n option of crontab(1) to specify the host.

/var/spool/cron/.cron.hostname を直接編集するよりは、crontab(1) の -n オプションを用いてホストに特化した設定を編集するほうがよい。

You should ensure that all hosts in a cluster, and the file server from which they mount the shared crontab directory, have closely synchro- nised clocks, e.g., using ntpd(8), otherwise the results will be very unpredictable.

あなたはクラスタのすべてのホストに対して以下のことを保証すべきである - crontab directory がファイルサーバーをマウントしていること - しっかりと時刻が同期されていること そうでなければ、結果がどうなるかは予測不能である。

Using cluster sharing automatically disables inotify support, because inotify cannot be relied on with network-mounted shared file systems.

クラスタシェアリングは自動で inotify(7) サポートを無効化する。 なぜならば inotify(7) はネットワーク共有されたファイルシステムを中継しないからである。

CAVEATS

All crontab files have to be regular files or symlinks to regular files, they must not be executable or writable for anyone else but the owner. This requirement can be overridden by using the -p option on the crond command line. If inotify support is in use, changes in the symlinked crontabs are not automatically noticed by the cron daemon. The cron daemon must receive a SIGHUP signal to reload the crontabs. This is a limitation of the inotify API.

全ての crontab ファイルは普通のファイルか、そのシンボリックリンクである。 それらは実行可能であったりオーナー以外の誰にでも編集可能であってはいけない。 この要求は crond のコマンドラインを -p オプションで上書きすることができる。 もし inotify サポートを使っている場合、シンボリックリンクされた crontab はデーモンにその変更を自動で通知しない。 これは ionotify API の制限である。

The syslog output will be used instead of mail, when sendmail is not installed.

sendmail が install されていない場合、syslogの出力は代わりに mail コマンドが利用される。

和訳してみてわかったこと

どうやら、/var/spool/cron を複数台にネットワークマウントすることにより、マウントされたサーバーをクラスタとみなしてその中の一台だけがジョブを実行するということができるようだ。

ただし、注釈にあるようにしっかりと時刻が同期されていなければ何が起きるかわからないという大変怖い事が書いてある。 ソースを読み込んで起きうる現象を把握しておかなければ到底プロダクションに投入できるものではない気がする。

私は最近 cron について非常に不安を感じているので、cron の動作をきちんと確認したいと思っている。この記事はその前フリでもある。

*1:@kitora_naoki に和訳の変なところの指摘をもらって修正しました！