1. Qiita
  2. 投稿
  3. crontab

イケてるcrontabのいじり方

  • 10
    いいね
  • 0
    コメント

crontab -eはだめ。

  • ミスりやすい。
  • 間違ってcrontab -rしようものなら・・・(全部消えます)。
  • crontabってコマンドを叩くだけで震えが止まりません。
  • 元に戻すのが変更量によっては大変なこともある。

イケてるcrontabのいじり方

作業ディレクトリの作成

  1. 場所はどこでもかいまいませんが、作業ユーザーのホームディレクトリで大丈夫でしょう。
  2. 年で一旦ディレクトリを切って月日でディレクトリを作っていますが、これも好みで自由に設定して大丈夫です。
  3. 大事なのは作業者が変わっても同じルールで運用することです。
[hoge@hogeserver ~]$ WORK_DIR=~/work/$(date +%Y)/$(date +%m%d)_crontab
[hoge@hogeserver ~]$ mkdir -p ${WORK_DIR}
[hoge@hogeserver ~]$ cd $_

今のcrontabを取得する

[hoge@hogeserver ~]$ crontab -l > crontab.old
[hoge@hogeserver ~]$ cp crontab.old crontab.new

修正する

  1. 好きなエディタで修正してください。
[hoge@hogeserver ~]$ vi crontab.new

変更差分のチェック

  1. diffコマンドの-yオプションで2列横に並べて表示、--suppress-common-linesオプションで同じ行は表示しない
  2. もちろんvimdiffでも大丈夫ですし、その他diff toolでも。
[hoge@hogeserver ~]$ diff -y --suppress-common-lines crontab.old crontab.new

実際にcrontabに反映する

[hoge@hogeserver ~]$ crontab crontab.new

反映されているかチェック

  1. crontab.newとは差分がないことを確認する
  2. crontab.oldとは差分があることを確認する
[hoge@hogeserver ~]$ crontab -l | diff - crontab.new # 差異がないこと
[hoge@hogeserver ~]$ crontab -l | diff - crontab.old # 差異があること

元に戻す時は

  1. もともとのファイルを食わしてあげるだけ。
  2. 心配性なあなたはdiffももう一度実行すると良いかもしれません。
[hoge@hogeserver ~]$ crontab crontab.old

crontab tips

変数が実は使えます

  1. crontabエントリーは長くなりがちですが、変数を上手に使うと折り返しなく表示できてストレス軽減できます。
  2. crontabのバージョンやLinuxディストリビューションでできるできないがあるので実運用前にはテストをしてください。
  3. これを利用するとと下記のように書くことが可能です。
MAILTO=""
BATCH_DIR="/path/to/batch"

0 5 * * * /bin/bash ${BATCH_DIR}/hoge.sh

変数が使えるなら・・・

  1. (もしかしたら試すディストリビューション、cronバージョンが少ないかもしれませんが)
  2. こういう書き方は出来ないようです
MAILTO=""
BATCH_DIR="/path/to/batch"

# ↓これはできないようです
LOG_DIR="${BATCH_DIR}/log"
0 5 * * * /bin/bash ${BATCH_DIR}/hoge.sh >>${LOG_DIR}/hoge.log 2>&1

ログファイル名には日付を入れましょう

  1. 運用ポリシーにもよりますが、ずっと同じファイルにログを書き続けるとパフォーマンスが良くないです。
  2. 障害発生時にログを開くのにイライラしたり探すのに時間がかかったりします。
  3. dateコマンドで今日の日付を入れてあげると日毎のログファイルに分割されます。
MAILTO=""
BATCH_DIR="/path/to/batch"
LOG_DIR="/path/to/batch/log"

0 5 * * * /bin/bash ${BATCH_DIR}/hoge.sh >>${LOG_DIR}/hoge.$(date +\%Y\%m\%d).log 2>&1

dateコマンドのエスケープは適切に

  1. エスケープ忘れると他のエンジニアに笑われるログファイルが出来上がります。
  2. ちょっと恥ずかしいので、出来てしまったらmvコマンドですぐ隠蔽しましょう。
MAILTO=""
BATCH_DIR="/path/to/batch"
LOG_DIR="/path/to/batch/log"

0 5 * * * /bin/bash ${BATCH_DIR}/hoge.sh >>${LOG_DIR}/hoge.$(date +%Y%m%d).log 2>&1

/dev/nullにはできるだけ出力しないようにしましょう

  1. そもそも何が起こってるかわからなくなる
  2. アプリケーションで別にログを出力してる場合は大丈夫

標準出力と標準エラーは分けましょう

  1. 障害発生時の対応が早くなります。
  2. エラーは指定したファイルに出力されるので、障害の監視もしやすくなる。
  3. 場合によってはエラーのディレクトリをつくってそこに格納しても良いかもしれませんね。
MAILTO=""
BATCH_DIR="/path/to/batch"
LOG_DIR="/path/to/batch/log"

0 5 * * * /bin/bash ${BATCH_DIR}/hoge.sh 1>>${LOG_DIR}/hoge.$(date +\%Y\%m\%d).log 2>>${LOG_DIR}/hoge.$(date +\%Y\%m\%d).error.log