crontab -e は「絶対に」使ってはいけない - ろば電子が詰まつてゐる
今までナチュラルに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日記
ひとつには、前者は「素人くさい、なんかダサイ」、後者は「ハッカーぽい、かっこいい」というのがあると思います。 よくWebで見かけるのが、後者を書こうとして間違えて、「リダイレクトに関する理解が間違っていた」「シェルの仕様を勘違いしていた」といって自分を責めてしまうケースです。 我々エンジニアは真面目な人が多いので、間違えると自分を責めてしまいがちです。 しかし開き直ってみれば、間違いを誘発する記法に問題があるとは言えないでしょうか。 私はこれは「奥が深い症候群」と言えるのではないかと思いました。 バッドノウハウがはびこる大きな理由は、(中略) 別の理由によ るものも根深いと私は考えている。それは、そういった使いにくい ソフトウェアを使いこなす事に対して、「奥が深い」といって喜び を見出す「奥が深い症候群」によるものである。 一般に、マニアという人種は普通の人にとってはどうでもいいよう な知
いい加減、>/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 これをぱっと見て
Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法
監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)に続きます 今日ようやく、積ん読状態だった「Software Design 2010年1月号」を手に取ったのですが、特集が「今日から使えるスクリプト満載！ [プロ直伝]お手軽サーバ監視術」。興味深く拝読したのですが、もっと楽ができるのにと思うところも。ちょうど、昨年末に運用しているサービス「パストラック」のサーバを移転し、crontab と perl で書かれたスクリプト群を使った監視環境を構築したところなので、そこで使っているスクリプト cronlog を紹介したいと思います。 特集の前書きにも書かれていることですが、サーバやネットワーク機器が多数ある環境なら、Nagios を始めとする、専ら監視のために作られたソフトウェアを使って、監視システムを構築すべきです。逆に小規
くろんメーカ - crontab用のコマンドを自動で生成します。 そのままコピペしてお使いください。DQNEO起業日記
crontab用のコマンドを自動で生成します。 そのままコピペしてお使いください。 ツイッターでご意見・ご感想をお待ちしております。→ Tweet 毎分、毎時 30秒おき（1分2回) 1分おきに (1分1回) 5分おきに（5分に1回） 1時間おきに（1時間1回） 毎時8分に（1時間1回） 2時間おきに(2時間に1回) 毎日 毎日、7時8分に（１日1回） 毎日、7時と19時に（1日2回） 毎日、7時と12時と19時に（1日3回） 毎週 月曜日の7時8分に（1週1回） 平日限定とか 平日の7時から19時まで、2時間おき 平日の毎日7時8分に（1日1回） 毎月 毎月6日の7時8分に（1月1回） コマンド 解説 1> 標準出力を吐き出す先 2> 標準エラー出力を吐き出す先 吐き出す先に /dev/null を指定すると出力は捨てられます。 cronについてのわかりやすい解説はこちら cron力をつ
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 で踏みにじるとはひどい。 とはいえ、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
