/ etc / crontabを編集するか、rootとしてcrontab -eを実行する必要がありますか？

43

ルートとして実行する必要がある定期的なシステムメンテナンスタスクを設定しています。Ubuntu 14.04 LTSに付属するcronをデフォルトとして使用する予定です。

前の管理者（退職してから）が/ etc / crontabを直接編集しているのがわかります。ただし、別の可能なアプローチはcrontab -eルートとして使用することであることを理解しています。どちらか一方を使用する説得力のある議論がありますか、それとも好みに依存していますか？

linux cron ubuntu-14.04

— marcv81
ソース

9

私にとって、これは合法的なベストプラクティスの質問のように見えます。私はすでに、回答の中で関連性のある事実的なポイントとそのコメントを確認できます。

— MadHatterは

1

crontab -lと入力して（crontabを一覧表示するため）、かつてcrontab-と入力しました。間違ってcrontabを削除してしまいました。その日は多くのことを学びました。

— 木こり

64

個人のcrontab（crontab -e）内のジョブは常に所有者として実行され、管理者が非rootユーザーとして実行するようにジョブを構成できる/etc/crontab追加の必須<user>フィールドが含まれていることに注意してください。

システムcrontabの編集またはroot用の個人用crontabのセットアップは、おそらくより移植性が高く、特定のLinuxディストリビューションに固有のものではなく、すべてのジョブを単一ファイルで管理する方が間違いなく便利です。

個人的に私は3番目のオプションを好みます：スケジュールされたタスクごとにドロップ

/etc/cron.d/cronスニペット付きのファイル
関連/etc/cron.[hourly |daily |weekly |monthly]ディレクトリ内の実行可能ファイル（スクリプト）。

スクリプトは簡単です（このようなファイルを簡単に作成/上書き/削除でき、単一のcrontabファイルの内容をいじる必要はありません）。また、構成管理ツールとうまく機能します。とにかくやって。

のジョブ/スクリプト/etc/cron.[hourly |daily |weekly |monthly]は常にrootとして実行されます。cronスニペットで/etc/cron.d/は、カスタムスケジュールの設定と、にある同じ必須<user>フィールドで別のユーザーとして実行することができます/etc/crontab。

— HBruijn
ソース

18

編集の欠点は/etc/crontab、cronパッケージを更新するたびにマージが必要になることです。/etc/cron.*ディレクトリの1つに新しいファイルを追加するだけであれば、その問題はありません。

— カスペルド

1

ほとんどのディストリビューションで/etc/cron.[hourly |daily |weekly |monthly]は実行可能ファイルを/etc/cron.d保持し、crontab を保持することを追加する必要があります。それ以外に、+ 1。

— GnP

私は間違いなくcron。[timing]ディレクトリのファンです。commnオプションより詳細なものはほとんど必要ありません。ただし、一部のディストリビューション、特にUbuntuは、これらのフォルダー内のファイル拡張子を持つスクリプトを静かに無視することに注意してください（最近のディストリビューションで修正された可能性のあるほとんどの人が.shを追加することを考えると、かなりインターネットに大きなバグです）。そのような状況でスクリプトが機能しなかった理由を解明するのは非常に困難です-少なくともcrontabに追加することは保証されています。

— -Gargravarr

15

私が最もよく思い出すように、crontab -eインストールする前にcrontab構文を検証し、間違えた場合は以前のものをエラーにして復元するという追加の利点があります。このように、構文が間違っていても、以前は機能していたものが突然停止することはありません。ベストプラクティスは、直接visudo編集/etc/sudoersするのではなく実行するなど、ユーティリティを使用することだと思います。

— ガーグラバー
ソース

2

+1構文検証についての良い点は、いくつかの構文エラーを認識しますが、絶対確実なものではありません（つまり/etc/crontab、6列目にユーザー名の行を入力できるようにします）。-対話型ツールを使用することは「ベストプラクティス」ではないと主張したいのですが、Puppet / Salt / Ansibleなどのツールで自動化する必要があります。そもそもサーバーを手動で構成しないでください。一方、あなたが古い学校の場合は、実際にツールを使用してください。

— -HBruijn

5台以上のサーバーを構成すればAnsibleや他のサーバーは優れていますが、たった1つの手間をかけるだけの価値はありません。たった1台のサーバーで、その時点で、ディストリビューション/リポジトリの変更により、スクリプトが動作しなくなる可能性があります。

— -marcv81

これが、受け入れられた答えに激しく反対する理由です。どのような変更が行われようとも、この検証プロセスを少なくとも1回実行する必要があります。次に、新しいcrontabから行をコピーし、それを他のサーバーに伝搬する自動化ツールに提供する場合、それは両方の世界で最高です。

— モンティハーダー

スクリプトを起動する場合はどちらも役に立ちません。また、スクリプトにエラーがあるため、どちらの方法でもドライランテストが必要です。

— mckenzm

@mckenzmは同意しましたが、適用できるバカ防止機能はあまりありません:)

— Gargravarr

2

これは本当にスタイルの質問です。OSによって複数のメソッドが提供されている理由があります。他の誰かを混乱させたくない場合（または、システムを処理しなかった後のあなた自身）-ホスト全体で実際にスケジュールされているタスクを確認するのが難しい場合は、一貫性を保ち、混在させないでください厄介な驚きに終わります。

— Rackandboneman
ソース

2

特定のユーザーの権限を必要とするcronジョブを確実に追加するには、個人的に次のコマンドを使用します。

 # crontab -u <user> -e

追加することもできsudoます。

@rackandbonemanが述べたように、/ etc / cron.d /ファイルをいじる必要はありません。問題がユーザーのcronジョブに関する場合は、crontabコマンドの機能を使用します。

— エスナック
ソース

3

-1上記を行うことの大きな欠点は、ユーザーがcronジョブを変更/削除/分割できるようになることです。これは、管理者が設定に貴重な時間を費やしたときに望ましくありません...ユーザーはサービスアカウントであり、そのアカウントはロック/期限切れになりますが、サービスは引き続き実行されますが、ロックされたアカウントの個人のcronタブは通常無効になります。

— HBruijn

ここで指定したユーザーが、公共のターミナルサービス環境のメンバーなどの公共のユーザーである場合、あなたは正しいです。ただし、問題がサービス/エージェントのユーザーに関するものである場合、考え直してみると、スタイルに関するものです。

— aesnak