新しい crontab エントリを挿入するために、これら 2 つの参照を使用しました。
新しい bash ファイルを作成し、それを /usr/bin に移動しました。この sh ファイルには、root ユーザーと admin グループの実行権限があります。bash ファイルは、ログ ファイルに 1 行をエコーし、Java プログラムを呼び出します。sh ファイルを root として手動でテストしました。問題なく動作します。crontab エントリは次のようになります...
@hourly /usr/bin/foo.blah.sh
これは毎時 1 分に実行されるはずです。 echo ステートメントがログ ファイルに出力されないので、crond がこれを呼び出しているとは思えません。また、「top」でプロセスを視覚的に監視すると、ジョブは表示されません。 cron デーモンが実行中であることを確認するために、「service crond status」を実行しました。 ドキュメントには、デーモンを再起動する必要はないと書かれています。 他に何が間違っているのでしょうか?
答え1
crontab -lcrontab エントリがどこにあるかは実際には述べられていませんが、 を出力するコメントに基づいてno crontab for root、さまざまな cron ジョブに対応するファイルを含む /etc/cron.* ディレクトリの 1 つにファイルを追加したのではないかと推測します。この回答では、その場合を想定しています。
これらのファイルの形式は、 で編集するユーザー固有のcrontabとは少し異なりますcrontab -e。具体的には、ユーザー名フィールドが含まれているコマンドの直前に、ユーザー固有の crontab には含まれません (少なくとも私のシステムでは、/var/spool/cron/crontabs に保存されていますが、その情報を悪用しないでください。正確な場所は、実行している cron デーモンの実装の詳細であり、それらのファイルを管理するには、文書化されたインターフェイスを使用する必要があります)。
結果として、あなたは変わるべきだ
@hourly /usr/bin/foo.blah.sh
に
@hourly user /usr/bin/foo.blah.sh
userはスクリプトを実行するユーザー アカウントの名前です。これで正常に実行されるはずです。
どうしても必要な場合を除いて、 cronジョブを実行しないことを強くお勧めしますroot。スーパーユーザーとして何かを行うと、常にセキュリティ上のリスクが生じます。可能であれば、スクリプトにアクセス権を制限した独自のアカウントを割り当ててください。(これは最小権限の原則です。つまり、ジョブを実行するために必要な最小限の権限です。) 一般的なルールとして、システムローカルファイルを /usr/local へシステム パッケージ マネージャーとの衝突を避けるため、また、混乱を避けるために、動作に root 権限を必要とするものを bin ディレクトリに置かず、代わりに sbin を使用してください。
答え2
以前は、cron にスクリプトを追加するときは、次のように常に sh を先頭に付けていました。
@hourly sh /usr/bin/foo.blah.sh