今までナチュラルにcrontab -eでcron編集をしていたのだけど、実はこれはとてつもなく危ないやり方だった。ということを、今さら知った。
crontabコマンドにはrオプション(Remove)があり、これを実行すると何の警告もなく全てが消え失せる。
macbook:~ ozuma$ crontab -l 15 * * * * /home/ozuma/bin/hoge.sh 0 9 1 * * /home/ozuma/bin/piyo.sh > /dev/null 2>&1 */5 * * * * /home/ozuma/bin/fuga.sh > /dev/null 2>&1 macbook:~ ozuma$ crontab -r macbook:~ ozuma$ crontab -l crontab: no crontab for ozuma macbook:~ ozuma$
これを知った時は、今まで何気なくcrontab -eしていたことを思い出して背筋が寒くなりましたね……eとrなんてすぐ隣なんだから(今すぐ君のキーボードを確認してみよう)、ミスタイプする可能性もとても高い。
これは、組織や会社、団体ごとに違った方針があると思う。そこでここでは、いくつかのパターン(というか宗派)を紹介する。
この場合、各ユーザごとのcrontabを作ることは許さない。過激な管理者(そう、あいつだあいつ)なら、/var/spool/cron の中を毎日消しに来るかもしれない。
ユーザは管理者にお願いして、/etc/crontabファイルに直接書いてもらうか、/etc/cron.dフォルダに放り込んでもらうことにする。（この2つのどちらにするかで、また宗派が分かれる）。このため、ユーザはシステム管理者と仲良くなっておく必要がある。たまにはランチに誘ってみるのも良いだろう。
/etc/crontabなどシステムのcrontabファイルは、ユーザごとのcron設定と違って、6フィールドめに実行ユーザを書くことになっている。
30 2 * * * ozuma /home/bin/hoge/fuga.sh
これで、ozumaさんから依頼のあったfuga.shを、毎日2時30分に実行できる。
この宗派は、/usr/bin/crontab をシェルスクリプトのラッパーで置き換えて、ラッパーの中で-rオプションを付けられていても消して無視しちゃったり、強制的に-iオプション(確認)を付けたりする。
しかし、OSのシステムコマンドに手を入れるわけで正直微妙だと思うし、iオプションはLinuxのみ(BSD/Solarisには無い)ので、採用すべきでないと思う。
crontabコマンドは、オプションを付けずに引数を与えると、その指定されたファイルを読み込んで設定される。
$ crontab cron.txt
これで、cron.txtに書かれた内容が設定される。だから、crontab -eで設定することは禁止して、常にこの形式で行うことにすれば、-eオプションを付けることが無いわけだから-r事故も起こらない。この場合、~/etc/crontab とか作っておいて、それを読み込ませる、とすると良いだろう。(ヘタに-lオプションを使うと事故る危険があるから、-lで吐いてそれを加工、はしないようにする)。
$ vi ~/etc/crontab (新しくcrontabに追加する行を設定) $ crontab ~/etc/crontab
そして、各ユーザの~/etc/crontabファイルと、念のため/var/spool/cron/(ユーザ名) をバージョン管理しておけば完璧だろう。
と、色々やっていてもやっぱり消しちゃう事故が起きたら。
システム全体のバックアップがあるならば、/var/spool/cron/(ユーザ名) というファイルに書かれているのでこのファイルを復旧すれば良い。
バックアップが無いならば、/var/log/cron にcronの実行ログが出ているのでこれを目で見て、手動でcrontabを復旧しよう。/var/log/cronからのサルベージ援護スクリプトを公開されている方もあるようです（crontab -r とやってしまった時の対処法)。
Good luck!