Apache Mesos はすごいプロダクトだと思うのですが、単にジョブスケジューラを冗長化するという用途に対しては、やや牛刀な感があるツールだと言えるでしょう。 一方で、バッチサーバの冗長化というのは、割と見過ごされがちなポイントではあると思います。 そこで、もっとライトな方法でこれを実現できないかと少し調べていました。 そこから派生して、cron の冗長化についていくつか情報を得たので、以下にまとめてみます。 (1) 実は cron 自体にクラスタリングの機能がある http://man7.org/linux/man-pages/man8/cron.8.html#CLUSTERING_SUPPORT 上の Man ページに記載の通りです。 ただし、実は cron 自体の実装には Linux Distribution やバージョンによって差異があります。上は fedora の croni
リリースしました https://github.com/Songmu/horenso cron等、バッチジョブを走らせた場合にその結果通知やエラーレポートをどうするかは悩ましい問題です。ラッパースクリプトを統一的に噛ますのが常套手段ですが、そのためのツールとして、horenso というものをGoで作りました。報・連・相。その名の通り、実行ジョブの報告をつかさどってくれる君です。以下のようにして使います。 % horenso -r reporter.pl -- /path/to/job args... -- 以降に指定したコマンドが実行され、その結果がJSONとして標準入力経由でreporterに渡されます。reporterは実行可能なファイル、もしくはコマンドライン文字列であり、記述言語は任意です。reporterに渡されるJSONは以下の様なものです。 { "command": "per
なお、時間設定方法や書式についてはここでは解説しません。 拙作「くろんメーカ」をお使いください。 くろんメーカ - crontab用のコマンドを自動で生成します。 そのままコピペしてお使いください。 crontab -e で直接編集しない 有名な話ですが、crontab -r とやってしまうと全てが一瞬で消え去ります。 まさにバルス！ 間違えて crontab -r してしまい、crontab をふっとばしてしまった。つか、隣同士にある -e と -r で編集と削除とか、酷いよ＞＜。。。 crontab -r を安全にする - antipop 必ずローカルファイルに設定を書いたうえで、それを反映させるようにしましょう。 $ crontab -l > ~/crontab # 現在の設定をバックアップ $ vi ~/crontab # ローカルファイルを編集 $ crontab < ~/cro
ご存じの方には濡れ衣ですごめんなさい。 これ間違って理解してました。 真実を知って衝撃を受けました。 周りに聞いてみたら多くの人が同じく誤解してました。 問題 crontab でこういうスケジュールを設定したら コマンド hoge はどのようなタイミングで実行されるでしょう。 0 0 13 * 5 hoge こたえ 毎月13日の金曜日の0時0分 だと思ってたんだけど、これ間違いでした。 正しくは、 毎月13日または金曜日の0時0分 だった。はい「知ってたよ」っていう人はごめんなさいよ。 日と曜日だけ or になる crontab の書式は、基本的に and なんですよね。 0 9 1 10 * だと、 10月 かつ 1日 かつ 9時 かつ 0分 のタイミングで実行。 ところが、日と曜日だけは「または」になります。 さっき実験してみたけど実際にそうなった。 crontab – Wikiped
タスクの定期実行としてcronが使われ続けていることに問題意識を抱えている人は数多く居れども、多くは惰性で使い続けている。何を隠そう私もその1人である。 そんな中、近年ではcronの代替としてjenkinsを使うという斜め上の発想が蔓延りつつあるが、 そんなことをすると「cronに500Mもメモリ使ってられるかー」と椅子が飛ぶこと請け合いなので非常に難儀するものである。 斯くの如く問題意識を抱えていたものの、やはり惰性でcronを使い続けていたのだが、 昨日、代替cronのネーミングとして “xaicron” という非常に格好良い名前を思いついてしまったので、 この際代替cronについて考えてみることにする。 懸念事項としては、将来RPMパッケージ化などされた時に、実行ユーザーとしてxaicronが作られてしまって、 万が一xaicronというユーザー名を使っている人がいた場合に困るという
今までナチュラルにcrontab -eでcron編集をしていたのだけど、実はこれはとてつもなく危ないやり方だった。ということを、今さら知った。 crontab -rの恐怖 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 macbo
昨今、cron のログにかんする話がちょいちょいありますが、問題点をまとめると stdout or stderr に1バイトでも書くとメールがとぶインタープリタのだす warnings や printf デバッグの名残りなどでもメールがいちいちとんでめんどくさいめんどくさいから出力を /dev/null にほうむりがちログを /dev/null にすてると運用にさしつかえるといったところかとおもいます。 これにたいする一般的なソリューションとして、かずほさんの cronlog というのがあって、これは exit status をみて stdout/stderr の出力を /dev/null または任意のファイルにおくってメールをとばさせないというソリューションです。 cronlog は便利なのだけど、毎行設定するのだるいという問題があるので、設定が簡単なように cron に以下のようなパッ
(タイトルは釣りです) いい加減、>/dev/null 2>&1と書くのをやめたらどうか - DQNEO起業日記 この記事のタイトルが twitter で流れてきたのを見て、「そうだ！出力を /dev/null に捨てるなんてとんでもないよね！」と思ってよく読んだら /dev/null に間違いなく捨てる方法だったのでつい crontabに > /dev/null 書いたら椅子投げる 2012-06-13 00:01:17 via YoruFukurou とつぶやいてしまったのですが、では出力を捨てないためにはどうすればいいのか。現時点での個人的ベストプラクティスを書き留めておきます。 デフォルト : メールで送る (MAILTO) せっかく cron daemon がログを捨てないためにわざわざメールで送ってくれるのに、それを > /dev/null で踏みにじるとはひどい。 とはいえ、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く