以下の環境と状況を前提にします あるリポジトリにcrontabに設定したい内容をtxtファイル( cron.txt)を含めてコミットしている コミットされたファイルがデプロイされるとその内容に基づいてデプロイ先サーバーでcrontabが設定される よくある構成かと思います。 ここでコミットされているファイルに以下のような記述がありました。 * 13 * * * php hoge.php この設定を書いた意図は、「毎日13時に hoge.phpを起動したい」でした。 しかし実際の挙動は「毎日13時台に毎分 hoge.phpが起動する」になります。 これに気づかないままコミットしてデプロイされてしまうと、本番サーバーに異常な負荷がかかったり、データ不整合が起こる可能性があります。 このリスクを少しだけ減らすためのテストを書きました。 php_cron_test cron-expressionと
リリースしました https://github.com/Songmu/horenso cron等、バッチジョブを走らせた場合にその結果通知やエラーレポートをどうするかは悩ましい問題です。ラッパースクリプトを統一的に噛ますのが常套手段ですが、そのためのツールとして、horenso というものをGoで作りました。報・連・相。その名の通り、実行ジョブの報告をつかさどってくれる君です。以下のようにして使います。 % horenso -r reporter.pl -- /path/to/job args... -- 以降に指定したコマンドが実行され、その結果がJSONとして標準入力経由でreporterに渡されます。reporterは実行可能なファイル、もしくはコマンドライン文字列であり、記述言語は任意です。reporterに渡されるJSONは以下の様なものです。 { "command": "per
ロシアの掲示板に出ていた、職場での小さなことをなんでも自動化していたハッカーの話が英語に翻訳され、Hacker News等で話題になっています。 xxx(ハンドル名): オーケー、ビルド担当エンジニアが転職で辞めちまった。本当にターミナルに住んでるようなやつだった。わかるだろ、Vimが大好きで、.dotファイルで図を描いて、Markdownでwikiに投稿するようなタイプさ… もし何か、そう何でも、90秒以上掛かるようなことがあったら、スクリプトで自動化しちゃうんだ。 xxx: そういうわけで我々はここにいて、彼の、そう、「遺産」を見てるところだ。 xxx: きっと気に入ると思うよ。 xxx: smack-my-bitch-up.sh(アバズレをしばく.sh) - 「遅くなる」というSMSを彼の妻(を指してるのは明らかだろう)に送る。文字列の配列からランダムに理由を選ぶ。cronジョブで動
森永です。 最近は大逆転裁判をやりながら寝落ちするという毎日を送っています。 サーバ構築する上で、ジョブをどうするかというのは考慮が必要な点です。 簡単に実現するにはcronを使えばいいのですが、要件によってはジョブスケジューラを使わないと厳しいということがあります。 かと言って、エンタープライズで使われている本格的なジョブスケジューラを使うのも大げさすぎる、というのもわかります。 そこで今回は、簡単に構築ができてそれなりに痒いところには手が届くジョブスケジューラ「Rundeck」を試してみます。 Rundeckとは OSSのジョブスケジューラです。 特徴として以下の様なものがあげられます。 エージェントレス SSH接続できればジョブを実行できます。 なので、別サブネットはもちろん、別VPCでも別AWSアカウントでもはたまたオンプレでもRundeckサーバからSSH接続とジョブを実行できる
なお、時間設定方法や書式についてはここでは解説しません。 拙作「くろんメーカ」をお使いください。 くろんメーカ - crontab用のコマンドを自動で生成します。 そのままコピペしてお使いください。 crontab -e で直接編集しない 有名な話ですが、crontab -r とやってしまうと全てが一瞬で消え去ります。 まさにバルス！ 間違えて crontab -r してしまい、crontab をふっとばしてしまった。つか、隣同士にある -e と -r で編集と削除とか、酷いよ＞＜。。。 crontab -r を安全にする - antipop 必ずローカルファイルに設定を書いたうえで、それを反映させるようにしましょう。 $ crontab -l > ~/crontab # 現在の設定をバックアップ $ vi ~/crontab # ローカルファイルを編集 $ crontab < ~/cro
システムを運用していく上で cron を使う場面はよくありますよね 処理をスケジュール実行したい時にとても便利です そんな cron ですが、最近仕事で作業しているときに ntpdate でシステム時刻を変更した後に cron で設定した時刻になってもジョブが実行されないという問題が見つかりました 全てのジョブが実行されていないわけではなく一部のジョブは実行されているようでした また、時刻を変更した後に crond を再起動すれば全てのジョブが正常に実行されるようになりました 幸い、実運用ではなくてシステムテスト中に見つかった問題なのでまだよかったんですが、運用している環境で同じ問題が起きたら相当マズイですよね そもそも ntp の時刻同期でシステム時刻が修正された場合にも同じ問題が起きそうじゃないですか？ ググっても同じような事象は見つからず、社内のメンバーにも聞いてみても cron で
https://metacpan.org/module/App::RunCron tl;dr cronlogより可搬性は落ちてシンプルさには欠けるけど、もうちょっと機能拡張してプラガブルな設定ができるruncronてやつを作った。コマンドの成功/失敗に応じて通知方法を変更できるようになっている。 本題 cronで困るのは、ログだったり通知であったりをどうするかというところです。 で基本的にどうするか、というところは@fujiwara組長の、 「cron で > /dev/null して椅子を投げられないための3つの方法」 に書いてあります。まとめると以下になります。 全部メールで投げる(> /dev/null は論外) 標準出力、エラー出力をまとめて、何らかのloggerに投げる(syslogがお手軽) 場合によってはcronlogで選別して失敗した時のみ通知する 最近は以下のように、sy
cles::blog 平常心是道 blogs: cles::blog NP_cles() « 小学生向けOffice :: 2009年、Googleでもっとも検索されたのはyahoo » 2009/12/05 incronでファイルやディレクトリが変更されたときに任意のコマンドを実行する linux sh 524 1へぇ 以前、簡易にディレクトリの同期を行う方法としてlsyncdを使った方法を調べましたが、単純にrsyncするだけではなくてもうちょっと手の込んだ事がやりたくなってきたのでlsyncdと同じinotifyベースで動作するincronをというソフトウェアを試してみました。 ファイル/ディレクトリの変更に応じて任意のジョブを実行するincron - SourceForge.JP Magazine こうした伝統的なcronで行えるのが時刻指定型のジョブ実行であるのに対して、ファ
ruby の代わりに、 $HOME/.rvm/bin/ruby-1.9.2-p320 などを使えばいいらしい。 rvmそれぞれの環境でインストールしたrubygemsにもパスが通って使えるようになる。 このファイルは中身を見るとシェルスクリプトで、rvm use 1.9.2-p320しながら引数をrubyに渡す感じになってる。 俺普段Ruby1.9か2.0使ってるんだけど、今までなんか面倒くさくてRuby1.8でも動くようにプログラム書いてsystem rubyにも同じgemインストールして動かしてた。 前に書いた自動日記をtwitterに流すようにしたってやつも、こうしたらRuby1.9で毎日1時にtweetするようになった。 0 1 * * * cd $HOME/src/ruby/autodiary && $HOME/.rvm/bin/ruby-1.9.2-p320 autodiary
今までナチュラルに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
(タイトルは釣りです) いい加減、>/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 で踏みにじるとはひどい。 とはいえ、
I’ve often needed to ensure that something happens on a recurring schedule. At a previous job, we needed to run scheduled Gearman jobs on a recurring basis. We chose to use cron as the serialization format of our schedules, and implemented a database driven system for storing these schedules. Storing the cron schedules for these recurring jobs in the database allowed us to have an easy to maintain
crontabの設定方法をすぐに忘れるのでメモ代わりにまとめています。 ※最初にまとめてからかなり時間が経過したので、内容の精査とその間に勉強した項目を追加しました。 crontabを設定する方法 crontabを設定する方法には２通りの方法があるので説明をしていきます。 crontab -e ※コマンドで設定 crontab ファイル ※ファイルを読み込んで設定 「crontab -e」コマンドで設定 「crontab -e」コマンドを実行するとcronを設定する画面が表示されます。 「e」では無く、横にある「r」を誤って指定してしまうと、設定されているcronの内容が削除されてしまうので注意してください。 $ crontab -e 設定を編集する画面が表示されるので、下記のような書式で設定を行います。 00 * * * * /root/disk-space.sh ちなみに、設定している
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
