cronジョブが実行されないことがある

CentOS 6.6次のパッケージがインストールされたサーバーがあります。

crontabs-1.10-33.el6.noarch
cronie-1.4.4-12.el6.x86_64
cronie-anacron-1.4.4-12.el6.x86_64
kernel-2.6.32-504.3.3.el6.x86_64

場合によっては、毎日実行するようにスケジュールされているバックアップジョブの1つが単に実行されないことがあります。スクリプトはに従って呼び出されることすらありません/var/log/cron.log。興味深いことに、同時に実行するようにスケジュールされた他のジョブは問題なく実行されます。

問題を再現できず、パターンを発見していません。私が何もしない場合、ジョブは翌日正常に実行されます。

crondは、特定の時間に実行されることになっている複数のジョブの1つだけを無視します。これは散発的にのみ発生します。

他のいくつかの場所で、crontabファイルの最後に空の行を追加することについて話しています。ときどき実行に失敗するジョブは、確かに私のcrontabファイルの最終行にあります。これが実際のバグか既知のバグかを確認できませんでした。

# tail -2 /var/spool/cron/postgres
*  * * * * OTHERJOB
0 21 * * * /pg_backup.sh

これは私が持っているすべてです /var/log/cron.log

Mar 31 21:00:02 SERVERNAME [cron.info] CROND[19394]: (root) CMD (OTHERJOB)
Mar 31 21:00:02 SERVERNAME [cron.info] CROND[19418]: (postgres) CMD (/pg_backup.sh)
Mar 31 21:01:02 SERVERNAME [cron.info] CROND[20062]: (root) CMD (OTHERJOB)

Apr  1 21:00:02 SERVERNAME [cron.info] CROND[31349]: (root) CMD (OTHERJOB)
Apr  1 21:01:01 SERVERNAME [cron.info] CROND[32080]: (root) CMD (OTHERJOB)

どのように参照してくださいOTHERJOBには、中に実行常にApr 1 pg_backup.shしても実行されませんでした。

私はすでに再起動を試みましたcrondが、これは起こり続けます。これは、同じバージョンのOS、カーネル、cronRPMを持つ複数のサーバーに影響を与えています。

cronie（1.4.12）の新しいバージョンがありますが、最新バージョンをすでに使用しているため、アップグレードすることはできません。Centos 6.6

私はcronie（1.4.4）の後にすべてのバージョンの変更ログを調べましたが、この特定の問題に対する修正はないようです。また、すべてのコミットメッセージを確認しました。

— ルイス
ソース

良いトラブルシューティング。noopの最後の行を追加してみませんecho >/dev/nullか（たとえば）？

— Belmin Fernandez、2015

エラーが発生するコマンドはありますか？スクリプトを停止する可能性があります。init.dスクリプトでも同様の経験がありました。

— hardik

各ジョブはどれくらい早く完了しますか？毎分開始するジョブが毎回2分間実行される場合は、問題になる可能性があります。しかし、それが2秒で完了する場合、それはおそらく問題ではありません。

— kasperd

毎分実行されるジョブ（OTHERJOB）は数秒で完了します。しかし、それは問題ではありません。上記のログにOTHERJOBを追加したのは、pg_backup.shが実行されなかったときにcrondが実行されており、OTHERJOBが正しく処理されたことを示すためだけです。

— Luis、

確認してください/var/log/audit/audit.log。

— マイケルハンプトン2015年

回答:

元のcronでは、各エントリを改行で終了する必要がありました。そのため、場合によっては、最後に空白行などが必要になることがあります。

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

いくつかのバージョンでは、それが固定されているか、例のUbuntu Maverik（10.10）に対して警告を発する：crontabの警告を述べて下部の診断のセクションを見ては、syslogに書き込まれます。

DIAGNOSTICS
       cron requires that each entry in a crontab end in a newline  character.
       If  the last entry in a crontab is missing a newline (ie, terminated by
       EOF), cron will consider the crontab (at  least  partially)  broken.  A
       warning will be written to syslog.

— ブライアン
ソース

これは検索テキストで最初に出てくる答えなcron error getpwname failedので、問題の原因を投稿するつもりでした。

/ etc / crontabを使用していましたが、ユーザーをコマンドの前に置くのを忘れていました。

つまり、

*/5   *  *  *  * /bin/bash <filename>

の代わりに

 */5   *  *  *  * root /bin/bash <filename>

同じエラーが発生しました。

— アーロンR.
ソース

sssdリモート認証に使用します。crondジョブを実行する前に利用可能なユーザーを確認する必要があり、これは60秒ごとに行われます。 sssdデフォルトclient_idle_timeoutは60秒です。sssdとの間に競合状態がありましたcrond

バージョン1.4.4-14crondでいくつかのエラーについてもう少し冗長になり始めたため、この問題の根底に達しました。

* Thu Feb  5 12:00:00 2015 Tomáš Mráz <tmraz@redhat.com> - 1.4.4-14
- add log message when getpwnam fails

そのバージョンに更新した後、ジョブが実行されないと同時に以下のエラーが発生し始めました：

[cron.err] crond[8654]: (user) ERROR (getpwnam() failed): Broken pipe

これは私たちにこれをもたらしました：https : //bugzilla.redhat.com/show_bug.cgi?id=1209600#c2

そして最後にこれに：https : //access.redhat.com/solutions/1125133

問題：sssd_begetpwnam（）がEPIPEを返す（つまり、パイプが壊れている）ためにSIGKILLで終了すると、crondが警告なしにcronジョブエントリをスキップする可能性があります。

上記のリンクに関する提案の解決策は、以下の行をに追加することでした/etc/sssd/sssd.conf：

client_idle_timeout = 75

上記の変更により問題が修正され、cronはジョブをスキップしなくなりました。

— ルイス
ソース