15

維持および更新する必要がある広大な crontab を継承しました。私はそれや bash スクリプトの経験があまりなく (基本についてはかなり理解できていると思います)、良い仕事をしたいと思っています。簡単なリクエスト: 乱雑な crontab と一連の bash スクリプトを「リファクタリング」するためのガイドライン

長いリクエスト: 私は多くの問題に遭遇しましたが、多くの人が cron ファイルなどを使用しているため、情報、ベスト プラクティス、およびツールの大きなリポジトリが欠けているように感じます。プログラミングの一種？(私の偏見: ツールを使用して、より速く、一貫して、適切に処理できるのに、手動で何かを行う必要はありません)。

これまでの問題の例:

  1. 外部イベントが原因で、crontab が数日間実行されませんでした。他の誰かと一緒に、私たちは手作業でリストを調べ、何が実行されなかったのか、何を再実行する必要があるのか​​、どのスクリプトを編集して以前の日付で実行する必要があるのか​​などを調べようとしました。見つけられないもの:

    • オンラインにはたくさんの (少し無意味な) 'cron ジェネレーター' があります。逆はどこ？長いcrontab、2つの日付を入力して、どのプロセスがいつ実行されるべきか、または合計で何回実行されるべきかを出力できるものはありますか? これは私の貧弱なスクリプト能力の範囲内にあるように思われるので、既に存在しているべきではないでしょうか? ;)
    • または、もう一度それを行う必要がある場合、スクリプト内のすべての日付呼び出しを変更するのではなく、date() のインスタンスが以前の時刻に事前設定されるように bashscript を呼び出す方法はありますか? (例: 見逃したすべてのレポートと請求書)

  2. あるレポートが 2 年間実行されていなかったことが判明しました。もう一度リクエストされたばかりで、ほら、crontabにありました！bash スクリプトには、関連ファイルへのパス参照が壊れていました。見つからないもの: bash ファイルのパス チェッカーのようなものはありますか? ウェブサイトのリンク チェッカーのようなものです。はい、最終的にはこれらすべてを手動で実行しますが、少なくともいくつかの問題領域が表示されます。

  3. 依存プロセス間のギャップが長すぎるか短すぎるため、最初のプロセスが実行された後に更新が行われたか、2 番目のプロセスが呼び出される前に最初のプロセスの実行が完了していない場合があるようです。これにはいくつかの可能なオプションを見てきました (たとえば、anacron は順番に実行されます)。

  4. また、crontab から生成された本質的に意味のない電子メールも多数あります (エラーをスローするが「正しく」実行されるスクリプト、ほとんどサイレントに失敗するスクリプト、または重要でないスクリプトのすべてのステップを印刷するだけのスクリプト)。私は手動でスクリプトを調べて、より有用なデータを提供するようにするか、「静かに成功する」ようにしますが、ガイドラインはありますか?

問題の理解やレイアウトが混乱している場合は、申し訳ありませんが、問題がわかりました。私は初心者から、これを正しく行うために何をすべきかを知る必要があり、扱いにくいシステムをさらに台無しにする必要はありません。ありがとう！

4

2 に答える 2

5

完全な回答ではありませんが、役立つその他のリソース: http://blog.endpoint.com/2008/12/best-practices-for-cron.html

私はゆっくりとこれを経験し、それぞれのポイントを実装しようとしています. 投稿後まで、「ベスト プラクティス cron」をグーグルで検索することは考えていませんでした。:P

バージョン管理については、ファイルごとにスクリプトを編集するため、当面は RCS を使用しますが、Git をセットアップするようにアドバイスされています (または、Windows システムを使用している場合は Mercurial をセットアップすることをお勧めします)。 ）。

これは実際には素晴らしいです ね: http://everythingsysadmin.com/2010/09/xed-202-released.html RCS に入っていない場合は、RCS に入れます。完全に無知なバージョン管理。私が bash に頭を悩ませているなら、使用しているバージョン管理システムに自動的にコミットする編集ショートカットを作成したいと思います。

システム管理者から受け取ったその他のヒント、日付: say、date、または --date="last monday" を使用するのではなく、固定の日付を使用し、実行するたびに日/週などを追加します (なぜなら、スクリプトが実行されない場合は、追いつくまでスクリプトを繰り返し再実行できるからです。ああ！（そして、これは明白に聞こえるかもしれませんが、私が最終的に編集するレポートの山は、レポートが実行されている日付を目立つように述べていません。修正します。）

そして、エラーメールがあるかどうかに実際に気付くように、cronメールをできるだけ静かにするように努めるべきだと安心しました. 私がまだ調査していない、より良い cron エラー レポート用のラッパーがあります。

于 2011-04-18T22:02:06.780 に答える
3

あなたの前にある大変な仕事、幸運を祈ります。:)

毎日実行されるすべてのタスクを見つけて、の独自のスクリプトにそれらを押し込むことをお勧めし/etc/cron.daily/ます。/etc/cron.weekly毎週、毎時、毎月に同じです。

anacron(8)マシンが常にオンラインであるとは限らないが、ジョブの実行時期をある程度制御する必要がある場合は、ジョブのスケジューリングにの使用を調査することをお勧めします。これは、数年間、複数のディストリビューションのデフォルトのcron-helper-toolでした。したがって、自分のタスクに依存するのに十分安定していることを願っています。しかし、それがあなたのニーズを完全に満たしていないかもしれないことは容易に想像できます。

スクリプトの日付を偽造することは、Ubuntuの少なくとも2つのパッケージで行うことができます：datefudgeとfaketime。私はどちらも経験がありませんが、どちらも助けになるはずです。将来は必要ないことを願っています。:)

申し訳ありませんが、bashスクリプトのパスチェッカーがないことを知っています。単純なスクリプトは単純で目で確認しやすいため、可能性は低いと思われます:)複雑なスクリプトは、実行時にパス名を生成します。たぶん、各スクリプトで使用されるパス名のデータベースを保持し、そのデータベースを定期的に検証するための新しいスクリプトを作成することができます。

を設定すると、cronメールを無効にできますMAILTO=""。私はこれが好きかどうかわかりません。たぶんMAILTO、ログ専用アカウントに設定すると、大洪水に役立つでしょう。別のオプションは、ルールを非常に上手く利用できるようにすることです。これにより、procmail(1)ルールを別のメールボックスに完全に詰め込むことができます。

うまくやる、mutt colorまたはscoreコントロールすることは、もみ殻の中から小麦を見つけるのに役立ちます。（color index red black ERRORまたは同様のコマンドを使用すると、問題をより迅速に特定できる場合があります。）

于 2011-04-13T11:16:04.003 に答える