Crontabにエントリを作成し、ユーザーAとして真夜中にジョブを実行しました。
朝、スクリプトの結果がないことがわかりました。 /var/cron/log
を確認すると、その時間(同じ時間)にスクリプトユーザーrootのみが実行されていることがわかりました。
質問:a)cronで複数のジョブを同時に実行するように設定できますか?.
b)いいえの場合これは、ユーザーroot cronがcronジョブを実行する他のユーザーよりも優先されることを意味しますか?
ここに彼らがどのように見えるかがあります。
root$ crontab -l
05 00 10 * * /opt/sdf/sbin/somescriptA.sh> /dev/null 2>&1 #Test
userA$ crontab -l
05 00 10 * * /opt/sdf/sbin/somescriptB.sh> /dev/null 2>&1 #Test
Cronは同時に多くのスクリプトを実行できます。実際、Debianには、同時に実行されるcronスクリプトのディレクトリ全体(つまり、/ etc/cron.daily /etc/cron.hourly)があります。
スクリプトが別の時間に適切に実行される場合、ルートcronジョブの時間を変更してみませんかは、問題が実際のタイミングにあるのか、スクリプト間の競合にあるのかを判断します。
すべてが正しく機能するようになるまで、/ dev/nullへのリダイレクトをオフにするにも同意します。
投稿したcrontabは毎月10日の00:05にのみ実行するように設定されていますが、これでよろしいですか?
/ opt内のスクリプトに実行可能な権限があり、shが適切に呼び出されていることを確認してください。コンソールでスクリプトを実行するだけでこれを試すことができます(フルパスを使用して、コマンドの前に「sh」を付けないでください)。
ディレクトリ/ var/spool/cron /でユーザー名を確認してください。cronファイルがそこにあるはずです(どこかに-私は現在システムにアクセスできません)。
/ dev/nullリダイレクトをジョブから外し、cronにファイルの出力をメールで送信します。スクリプトに問題がある可能性があります(おそらく、cronで実行するときに存在しない環境変数を想定しています)。
Cronジョブは同時に実行できます。あなたの問題は別のものです。 ..または..スクリプトはrootとして実行されています。実行しようとしているものには、複数のインスタンスを防ぐ独自の方法があるのかもしれません。
ロックファイルやオープンファイルなど、2つのスクリプトの間に何らかの相互作用があると思います。
同時に実行されている複数のcronジョブで問題が発生したことはありません。私のSlackwareシステムでテストしただけで問題なく動作しますが、ディストリビューションによって異なる場合があります。
とにかく、通常はcrontabエントリの数分をずらして、すべてが同時に実行されないようにすることをお勧めします(システムへの不要な負荷と潜在的な相互作用の問題を防ぐため)。
Cronジョブの出力をnullにリダイレクトするのではなくチェックするというMilnerの提案を2倍にします。少なくとも、ジョブ自体が機能していない理由をデバッグするまでは。
Crontab -eを使用してcrontabを編集しましたか? crontabが変更を認識していない可能性があります。このコマンドを使用して、新しいcrontabを編集/インストールする必要があります。
他の人が同じ時間にスケジュールされたため、cronジョブをサイレントに無効にすることを聞いたことがありません。それはうまくいくはずなので、あなたの問題は別の場所にあると思います。
ところで、これはserverfault.comのように聞こえます。
ユーザーは問題なくcronジョブを同時に実行できるはずです。ユーザーAがcronの使用を許可されていることを確認しましたか(/etc/cron.allowと/etc/cron.denyを確認してください)。
同様の問題があり、ユーザーのcrontabから2つの異なるスクリプトを同時に実行することが問題である可能性があると考えていました。問題は、2番目のスクリプトの最上位ディレクトリの権限が「drwx ------」であり、cronがそれにアクセスして実行できないことであることに気付きました。そのディレクトリのアクセス許可を変更した後、それはスムーズに実行されました。