|DMM inside
森永です。 最近は大逆転裁判をやりながら寝落ちするという毎日を送っています。 サーバ構築する上で、ジョブをどうするかというのは考慮が必要な点です。 簡単に実現するにはcronを使えばいいのですが、要件によってはジョブスケジューラを使わないと厳しいということがあります。 かと言って、エンタープライズで使われている本格的なジョブスケジューラを使うのも大げさすぎる、というのもわかります。 そこで今回は、簡単に構築ができてそれなりに痒いところには手が届くジョブスケジューラ「Rundeck」を試してみます。 Rundeckとは OSSのジョブスケジューラです。 特徴として以下の様なものがあげられます。 エージェントレス SSH接続できればジョブを実行できます。 なので、別サブネットはもちろん、別VPCでも別AWSアカウントでもはたまたオンプレでもRundeckサーバからSSH接続とジョブを実行できる
DockerHub の言語系のイメージは(alpine のもあるけれども)debian ベースのものが多いですが cron でスクリプトを定期的に実行しようとして、 RUN apt-get update && apt-get install -y cron とかすると、 cron から実行するスクリプトにコンテナの環境変数が渡されない コンテナの開始時に環境変数をファイルに書いて cron から実行するスクリプトで読んだり スクリプトの標準出力や標準エラーがどこに行くのかよくわからない スクリプトはログをファイルに出力して tail -f したり そのログだれがローテートするの? とか、とてもつらそうです。 ので、cron の代わりに michaloo/go-cron を使ってみたりしてたのですが、下記の記事を見まして、 alpine linuxでcron用コンテナを作る - Qiita
月末にcronを実行したいと思いcrontabに設定を書こうとしたところ、月初のように単純には書けないことに気づきました。 月初だと以下のように「毎月1日に」と書けばいいのですが、 0 0 1 * * 実行したいコマンド月末は30日の場合もあるし2月はうるう年も考慮する必要があります。 調べてみたことろ、testコマンドとdateコマンドを組み合わせて「28日から31日の間で翌日が1日だったら実行する」という設定を書けばいいみたいですね。 0 0 28-31 * * /usr/bin/test $(date -d '+1 day' +%d) -eq 1 && 実行したいコマンド勉強になりました。 参考crontabの書き方 | server-memo.netLinux - testコマンドとcronを組み合わせ、月末にバッチを動かす - Qiita
(タイトルは釣りです) いい加減、>/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 で踏みにじるとはひどい。 とはいえ、
はじめに これから書く内容は、シェルスクリプトをばりばり書いている現場(サーバエンジニア・インフラエンジニア)向けのものではありません。 年に数回crontabをいじるような現場(サーバに詳しくないアプリケーションプログラマが多数を占めるような現場とか、Webデザイナや非プログラマがcrontabをおそるおそるいじったりするような現場)を想定しています。 >/dev/null 2>&1 の問題点 この記法の問題点は、「覚えにくい、間違えやすい、間違ってても気づかない」ということです。 初心者を迷わせる要素がこんなにあります。 >/dev/nullは先か後か 1と2はどちらが先か &はどこに書くのか よって下記のように多種多様なミスが起こり得ます。 2>&1 >/dev/null >/dev/null 1>&2 >/dev/null 2>1& >/dev/null &2>1 これをぱっと見て
正常系のメッセージは標準出力に、異常系のメッセージは標準エラーに出すようになっているコマンドがあったとします。 これを cron に設定するときに、次のようにログおよびメール通知を行いたいです。 正常系のメッセージ(標準出力) ログファイルに出力 異常系のメッセージ(標準エラー) ログファイルに出力 メールで通知 メール通知は標準出力または標準エラーにそのまま吐き出せば crond が勝手にやってくれます。 ログファイルへの出力は logger コマンドにパイプしておけば(syslog の設定によりますが) /var/log/messages にそれっぽい形式で書かれるのでオススメです。 $ echo "this is test" | logger -i -t hogehoge $ sudo tail -1 /var/log/messages May 29 20:02:39 ore-no-
なお、時間設定方法や書式についてはここでは解説しません。 拙作「くろんメーカ」をお使いください。 くろんメーカ - 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 で
こんにちは。斎藤です。 最近、Dockerなどのコンテナ型仮想化技術、Chef, Ansible, Itamae などによるITインフラ構築・運用自動化技術の利用が進んでいます。一方で、何年も動いて「歴史」を積み重ねているシステムも数多くあります。そして、私を含めてそれらの運用に関わる事もあるでしょう。そんな「歴史」のあるシステムも、何とか運用を効率化したいと思う事があるかもしれません。 今日は、バッチジョブや複数サーバに対する運用を効率化するRundeckを取り上げます。「何ができるの?」「はじめかた」そして「利用時の留意点」の3点についてお話しします。 ※OSはCentOS 6系、Rundeck はバージョン 2.4.0、Java VM は Oracle JDK 1.7.0_72 を利用しています。 cron。Linux系OSに標準搭載されているジョブスケジューラです。標準で使えるため
バッチ用プログラムを書いた時に一々プログラム側でログの出力をするのが面倒って時に使えます。 ログの出力先に指定して、dateコマンドを使ってログファイルを出力します。 サンプルcron 0 0 * * * /bin/sh /root/batch.sh > /root/log/bat_`date +%Y%m%d`.log ですが上記のままだとエラーに・・・ 上記のままだと以下のエラーが出力されます。 /bin/sh: -c: line 0: unexpected EOF while looking for matching ``' /bin/sh: -c: line 1: syntax error: unexpected end of file 原因は「%」でした。 cronだと「%」はコマンドの終わりと解釈されるようです。 なのでシングルクォートが閉じられていない等のエラーが出ていました。
WEB+DBのPerl Hackers Hubで書かれていた「cron周りのベストプラクティス」を読んだ。かなり参考になった。 経緯としては読みたいって呟いたら感想よろしくと言われたので慌てて読んだ。 @shiba_yu36 「読んだ」なら言ってもいい— songmu (@songmu) 2014年2月24日 @shiba_yu36 マジに謝られても…— songmu (@songmu) 2014年2月24日 @shiba_yu36 マジになって感想エントリを書いてください。— songmu (@songmu) 2014年2月24日 特に参考になったこと batch.pl batch.plは非常に良いと思った。というのもcronとかのスクリプトで非常に簡単な事をやっている場合は適当にplファイルを作っちゃって登録するんだけど、得てしてそういうのはテストが無くてバグってて、しかもcronのロ
本日見本誌を受け取りました。感激しております。ありがとうございます。 縁あって、2/22 発売の WEB+DB PRESS Vol.79 に記事を書かせてもらえることになり「cron周りのベストプラクティス」というPerlにあまり関係ない記事を書かせてもらいました。 WEB+DB PRESS Vol.79 安定しつつも扱いづらいcronをどのようにWebアプリケーションプロジェクトで安定的に利用・活用するかについて書いています。cronだけで9ページという驚きの充実の内容です。とは言え、まだ書き足りない部分もあり、例えば比較対象としてJenkinsについても取り上げたかったのですが、泣く泣く削っております。 個人的にイノベーティブなプロダクトである、App::RunCronについても2ページを割いて取り上げております。 これであなたも、cronのログを捨ててしまったり、逆に溢れさせてしまっ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く