監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)に続きます 今日ようやく、積ん読状態だった「Software Design 2010年1月号」を手に取ったのですが、特集が「今日から使えるスクリプト満載！ [プロ直伝]お手軽サーバ監視術」。興味深く拝読したのですが、もっと楽ができるのにと思うところも。ちょうど、昨年末に運用しているサービス「パストラック」のサーバを移転し、crontab と perl で書かれたスクリプト群を使った監視環境を構築したところなので、そこで使っているスクリプト cronlog を紹介したいと思います。 特集の前書きにも書かれていることですが、サーバやネットワーク機器が多数ある環境なら、Nagios を始めとする、専ら監視のために作られたソフトウェアを使って、監視システムを構築すべきです。逆に小規
cronに関するrx7のブックマーク (10)
-
rx7 2015/11/12
-
crontabの"-i"オプションで"-r"のうっかりミスを防止する - 元RX-7乗りの適当な日々
今、お風呂からあがって、TwitterのTLを見てたら「crontab -e は「絶対に」使ってはいけない - ろば電子が詰まつてゐる」のエントリを読んで、その勢いで書く。 crontabコマンドにはrオプション(Remove)があり、これを実行すると何の警告もなく全てが消え失せる。 crontab -e は「絶対に」使ってはいけない - ろば電子が詰まつてゐる 確かに、(僕も含めて) 誰もが一度くらいは怖い/ドキドキするような思いをするのかもしれないですが、crontabコマンドには"-i"オプションという、削除時に確認のプロンプトを出してくれるオプションが存在します。 つまり、aliasでこのオプションをつけておけば良いわけですな。 $ crontab -e crontab: installing new crontab $ crontab -r $ crontab -l no cro
-
cronの通知先メールアドレスを変更したい
Red Hat Linuxなどのcron設定では、標準で/etc/crontabに「MAILTO=」として、動作結果を特定のアカウントへ通知されるよう記述されている。 ここでの/etc/crontabには、システム自体（root）権限で実行されるものが定義されることから、その通知もroot宛になっている。 # cat /etc/crontab SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 0 * * * root run-parts /etc/cron.daily 04 0 * * 0 root run-parts /etc/cron.weekly 06 0 1 * * root r
-
RailsのCron処理に·Whenever MOONGIFT
Ruby on Railsにおけるバックグラウンド処理で有名なものと言えばBackgrounDRbやBackground-fuになるだろう。使ってみた感想としてはどちらも癖があって、何となくうまくいかない。プロセスが途中で消えたりすることもある。 分かりやすい記述でCronが書ける 非同期的にキックするような処理が必要な場合は難しいが、単純なCron処理であればLinux標準のCronが最も安定している。それを手軽に使えるのがWheneverだ。 今回紹介するオープンソース・ソフトウェアはWhenever、Railsアプリケーションに対応したCron処理ライブラリだ。 WheneverはRailsアプリケーションとCrontabの橋渡しをするソフトウェアだ。Railsアプリケーション内でwheneverizeコマンドを実行すると設定ファイルが出力される。ここではevery 3.hoursの
-
cronでエラーメールの送り先を指定する方法 — ディノオープンラボラトリ
cronは良く使うツールの一つだと思いますが、何故かトラブルの思い出がつきまとうのは僕だけでしょうか。今日はそんなcronの便利な機能を一つ紹介します。 cronで実行するコマンドの作法 はじめにcronスクリプトの作法を紹介します。cronは決められた時間が来るとコマンドを自動実行する仕組みですが、自動実行するコマンドは下記の条件を満たすべきです。 正常終了した場合は標準出力/標準エラー出力に何も出力しない 異常終了した場合は標準出力/標準エラー出力にエラーメッセージを出力する というのも、cronで実行したコマンドが標準出力・エラー出力に1バイトでも出力した場合、その内容がメールで送信されます。僕は異常時だけメールを受け取る使い方が一番スマートに思えます。 もしくは、次のような使い方も考えられます。 コマンドのログは標準出力に出力し、ローカルのログファイルに追記する 異常終了した場合は
-
crontabの設定メモ - ザリガニが見ていた...。
crontabの設定は簡単なのだが、ちゃんと理解しようとすると意外と多くの関連する知識が必要なのであった...。以下、crontabの設定しながら覚えたことメモ。 環境 MacBook OSX 10.5.6 zariユーザーでログイン中 ターミナルでbashを利用 関連する日記 Spotlight対応のスティッキーズにしておく コマンド書式 crontab -l # zariユーザーのcron設定を表示する crontab -e # zariユーザーのcron設定をviを起動して編集する sudo crontab -u Guest -l # ルート権限で認証して、Guestユーザーのcron設定を表示する 実行する時間の設定とコマンドから構成される。 * * * * * command | | | | | | | | | `--曜日（0:日 1:月 2:火 3:水 4:木 5:金 6:土
-
cronからlaunchdへ（より効率的なジョブ管理を目指して) - ザリガニが見ていた...。
前回、cronでジョブ（コマンドやスクリプト、単一のプログラムなど）を自動実行するために、crontabからその設定をする方法について調べていた。自分なりにかなり詳細に。 ところが、OSX 10.5ではcronを利用してジョブを自動実行する仕組みは一切、利用されていなかった...。ユーザーがcrontabで設定ファイルを作成しない限り、cronさえ起動していない状態だ。（crontabで設定ファイルを作成すれば、cronも起動するようになる。）cronに替わって、OSX 10.5ではlaunchdが活躍していた。launchdはcron以上に柔軟にジョブを管理する仕組みを持っている。 例えば、スティッキーズをspotlightで検索可能な状態にするために、cronを使ってStickiesDatabaseを1分ごとにコピーしていた。*1 最初は無差別にコピーしていたが、 * * * * *
-
恐怖のcrontab -r. 設定ファイルはレポジトリ管理せよ - LukeSilvia’s diary
crontabファイル含め、設定ファイルはレポジトリで管理しましょうという話です。 恐怖のcrontab -r crontab -r を安全にする - antipop 間違えて crontab -r してしまい、crontab をふっとばしてしまったので、以下のような zsh 関数を書いて、確認を出すようにした。つか、隣同士にある -e と -r で編集と削除とか、酷いよ＞＜。。。 cronのにジョブを登録する際に、crontabファイルを開きますが、「crontab -e」と間違って「crontab -r」をやると、crontabが消えてしまう。しかも、記事の内容にある通り、「e」と「r」というタイポしてもおかしくない位置にあるというので、これは怖い。 crontabの内容なんてほとんど覚えてない割にはちょくちょく更新するファイル。バックアップとかとってないと大変なことになる。 ytoy
-
-
-
1
公式Twitter
- @HatenaBookmark
リリース、障害情報などのサービスのお知らせ
- @hatebu
最新の人気エントリーの配信
キーボードショートカット一覧
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Copyright © 2005-2025 Hatena. All Rights Reserved.
設定を変更しました