タグ

cronに関するyogasaのブックマーク (14)

  • Crontab を別のユーザのもので上書きしてしまった話 - Qiita

    このやらかしは、私の人生観を変えるきっかけとなった出来事でもあります。最後までお読みいただけたら幸いです。 環境 CentOS やらかしたこと root ユーザの Crontab を他の一般ユーザのもので上書きしました。 背景 某平日の夜 9 時半ごろ、(当時)新卒 2 年目で開発チームの私と新卒 4 年目でインフラチームの先輩は障害対応にあたっており、 Crontab の一部をコメントアウトする操作 を行おうとしていました。 私「もう眠いですよ~先輩、早くクーロン見ましょ 」 先輩「うん、見よ見よ これをこうして... 」 私「Crontab の確認って、 Crontab を確認したいユーザにログインして crontab -l じゃないんですか? 」 先輩「ああ、それもあるけどわたしはいつも root で /var/spool/cron/${ユーザ名} 見てる よー 」 私「へぇ~、初め

    Crontab を別のユーザのもので上書きしてしまった話 - Qiita
  • [linux]月末にcronを実行する

    月末に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

    [linux]月末にcronを実行する
    yogasa
    yogasa 2015/10/14
  • cron でのコマンド実行が失敗したときにアラートを飛ばすための alerty というツール : sonots:blog

    cron でのコマンド実行が失敗したときにアラートを飛ばすための alerty というツール : sonots:blog
    yogasa
    yogasa 2015/09/07
  • cronの代替になりそうなジョブ管理ツールのまとめ - Qiita

    たまに検討するけど、よく忘れるのでまとめておく。ごく個人的な感想としては、Rundeck, Azkabanあたりで始めてみるのがいいかもと思う。 要件 重複実行の防止 ジョブの実行結果、かかった時間、ログ出力などが見れる 失敗時の通知 候補 OSS系 Rundeck http://rundeck.org/ Java Runtimeで動く RUNDECK PROという有料サービスもある http://simplifyops.com/ 参考: http://heartbeats.jp/hbblog/2015/01/rundeck.html Oozie http://oozie.apache.org/ Workflow Scheduler for Hadoop Java http://oozie.apache.org/docs/4.1.0/DG_Overview.html Webコンソールもある

    cronの代替になりそうなジョブ管理ツールのまとめ - Qiita
    yogasa
    yogasa 2015/08/10
  • cron の意外な落とし穴! - もろず blog

    システムを運用していく上で cron を使う場面はよくありますよね 処理をスケジュール実行したい時にとても便利です そんな cron ですが、最近仕事で作業しているときに ntpdate でシステム時刻を変更した後に cron で設定した時刻になってもジョブが実行されないという問題が見つかりました 全てのジョブが実行されていないわけではなく一部のジョブは実行されているようでした また、時刻を変更した後に crond を再起動すれば全てのジョブが正常に実行されるようになりました 幸い、実運用ではなくてシステムテスト中に見つかった問題なのでまだよかったんですが、運用している環境で同じ問題が起きたら相当マズイですよね そもそも ntp の時刻同期でシステム時刻が修正された場合にも同じ問題が起きそうじゃないですか? ググっても同じような事象は見つからず、社内のメンバーにも聞いてみても cron

    cron の意外な落とし穴! - もろず blog
  • Rundeck - cronから移行しやすいジョブスケジューラを使ってみよう

    こんにちは。斎藤です。 最近、Dockerなどのコンテナ型仮想化技術、Chef, Ansible, Itamae などによるITインフラ構築・運用自動化技術の利用が進んでいます。一方で、何年も動いて「歴史」を積み重ねているシステムも数多くあります。そして、私を含めてそれらの運用に関わる事もあるでしょう。そんな「歴史」のあるシステムも、何とか運用を効率化したいと思う事があるかもしれません。 今日は、バッチジョブや複数サーバに対する運用を効率化するRundeckを取り上げます。「何ができるの?」「はじめかた」そして「利用時の留意点」の3点についてお話しします。 ※OSはCentOS 6系、Rundeck はバージョン 2.4.0、Java VM は Oracle JDK 1.7.0_72 を利用しています。 cronLinux系OSに標準搭載されているジョブスケジューラです。標準で使えるため

    Rundeck - cronから移行しやすいジョブスケジューラを使ってみよう
    yogasa
    yogasa 2015/02/01
  • RHEL 6のジョブスケジューラ「anacron」とは Part1 | 技術ブログ| レック・テクノロジー・コンサルティング株式会社

    こんにちは、Re:Qの中川(晴)と申します。 今回「RHEL6におけるジョブスケジューラ “anacron”」についてご紹介致します。 RHEL5まではcronでの実行がメインだったOS デフォルトジョブも、 RHEL6からほとんどが anacron に切り替わっております。 ただ、従来のシステムで多用されてきたcronと比べ、 anacron はまだ馴染み深くない方もいらっしゃるかもしれません。 そこで、今一度、anacroncronで混在してしまう点を整理し、2回に分けてご紹介致します。 今回のパート1では、 ・cronとanacronの違い ・cronとanacronをどのように使い分けるべきか ・cronとanacronの関係性 ・anacronのスケジュール実行フロー について、なるべくわかり易くイメージ図も交えご紹介致します。

    yogasa
    yogasa 2014/11/11
  • cron上でのコマンド実行を再現する - Qiita

    シェル上だと動くのにcron上だと動かない。 よく聞くお話ですよね。 大体はcron上と普段のシェル上で環境変数が違うために起こる問題です。 そういう時に使えるtipsを共有します。 個人のマシン上で適当に動かすようなcronだと みたいにしてログインシェルを間に噛まして環境変数を上書きして実行することでごまかしたりもできます。 これまた別の依存する箇所を増やすので 個人のマシンかrcファイルがちゃんと管理されているような状況以外ではオススメできません。 なのでcron上で実行される状況とほぼ同じ状況でスクリプトを実行してみましょう。 cron上では環境変数はほぼ空なので環境変数を空にしてみましょう。

    cron上でのコマンド実行を再現する - Qiita
    yogasa
    yogasa 2014/05/23
  • /etc/cron.d/以下にドットを含むファイルを配置しても無視される - $shibayu36->blog;

    先日、/etc/cron.d/にファイルを設定してるのに、何故かcronが起動してくれないという問題があった。その時は/etc/cron.d/crontab.develというファイルを配置していた。 何でかなーと思ってman cronしてたらこういう記述を見つけた As described above, the files under these directories have to be pass some sanity checks including the following: be executable, be owned by root, not be writable by group or other and, if symlinks, point to files owned by root. Additionally, the file names must conf

    /etc/cron.d/以下にドットを含むファイルを配置しても無視される - $shibayu36->blog;
  • Big Sky :: サーバを再起動したら勝手にscreenが起動してその中でirssiが動いていて欲しい場合のベストプラクティス

    個人的にお借りしているサーバがあってそこで何個かbotを動かしているのだけど、そのサーバがセキュリティアップデート等で再起動した後、ログインしてscreen起動して、その中で画面割ってbot起動して、また別の画面でirssiを起動する、みたいな事を毎回やってた訳ですがいい加減めんどう臭くなってきたので自動化した。 まずscreenを自動起動する仕組みを考えた。rcスクリプトでもいいけど、そもそも共用サーバなのでroot権限が無い。そこでcronを使う。crontab -e して @reboot (. ~/.profile; /usr/bin/screen -d -m) @reboot という識別を使います。再起動して1回だけ実行されるコマンドが書けます。最近の linux であれば使えるかと思います。 ここで .profile を読み込んでるのは、これをしないと screen が新しく起動

    Big Sky :: サーバを再起動したら勝手にscreenが起動してその中でirssiが動いていて欲しい場合のベストプラクティス
  • いい加減、>/dev/null 2>&1と書くのをやめたらどうか (追記あり) · DQNEO日記

    はじめに これから書く内容は、シェルスクリプトをばりばり書いている現場(サーバエンジニアインフラエンジニア)向けのものではありません。 年に数回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 これをぱっと見て

    いい加減、>/dev/null 2>&1と書くのをやめたらどうか (追記あり) · DQNEO日記
  • cron で > /dev/null して椅子を投げられないための3つの方法 - 酒日記 はてな支店

    (タイトルは釣りです) いい加減、>/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 で踏みにじるとはひどい。 とはいえ、

  • Kazuho@Cybozu Labs: 監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)

    結論から先に。cronlog を使えば、アプリケーションのテストコードと全く同じ形式で、監視用のスクリプトを書くことができます。プログラマが監視ツールの記法を覚える必要はありません。これは、プログラマが運用も行うケースでは特に有効な手法だと思います。 先週公開した Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法 というエントリで、crontab と拙作の cronlog を用いてサービス監視を書く手法を紹介しました。しかし、挙げた例はいずれも ping や http のテストといった外形監視の手法です。RDBMS とウェブアプリケーションのみから構成されるサービスならそれだけで十分でしょう。 しかし、外形監視だけでは、メッセージキューのような非同期処理の遅延を観測することはできません。また、http のログを監視して、エラーレスポンスや平均応答

  • Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法

    監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)に続きます 今日ようやく、積ん読状態だった「Software Design 2010年1月号」を手に取ったのですが、特集が「今日から使えるスクリプト満載! [プロ直伝]お手軽サーバ監視術」。興味深く拝読したのですが、もっと楽ができるのにと思うところも。ちょうど、昨年末に運用しているサービス「パストラック」のサーバを移転し、crontab と perl で書かれたスクリプト群を使った監視環境を構築したところなので、そこで使っているスクリプト cronlog を紹介したいと思います。 特集の前書きにも書かれていることですが、サーバやネットワーク機器が多数ある環境なら、Nagios を始めとする、専ら監視のために作られたソフトウェアを使って、監視システムを構築すべきです。逆に小規

  • 1