web-dev-qa-db-ja.com

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)

Apr 1pg_backup.shが実行されていない場合でも、OTHERJOBが常に実行される方法を確認してください。

私はすでにcrondを再起動しようとしましたが、これは引き続き発生します。これは、同じバージョンのOS、カーネル、およびcron RPMを持つ複数のサーバーに影響を与えています。

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

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

linuxcentoscroncentos6
8
Luis

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

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

* Thu Feb  5 12:00:00 2015 Tomáš Mráz <[email protected]> - 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/11251

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

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

client_idle_timeout = 75

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

1
Luis

元の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.
6
Brian

これは、検索テキストcron error getpwname failedが表示される最初の回答なので、問題の原因を投稿すると思いました。

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

つまり、

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

の代わりに

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

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

2
Aaron R.