Cron Job läuft gelegentlich nicht

Ich habe einen CentOS 6.6Server mit den folgenden Paketen installiert:

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

Manchmal wird einer der Sicherungsjobs, die täglich ausgeführt werden sollen, einfach nicht ausgeführt. Das Skript wird nicht einmal nach aufgerufen /var/log/cron.log. Interessant zu erwähnen, dass andere Jobs, die genau zur gleichen Zeit ausgeführt werden sollen, ohne Probleme ausgeführt werden.

Ich kann das Problem nicht reproduzieren und habe keine Muster darauf entdeckt. Wenn ich nichts tue, wird der Job am nächsten Tag wie erwartet korrekt ausgeführt.

crond ignoriert einfach nur einen der mehreren Jobs, die zu einem bestimmten Zeitpunkt ausgeführt werden sollen. Dies geschieht nur sporadisch.

Ich habe an einigen anderen Stellen gelesen, dass am Ende der crontabDatei eine leere Zeile eingefügt wird. Der Job, der gelegentlich nicht ausgeführt werden kann, befindet sich in der Tat in der letzten Zeile meiner crontabDatei. Ich konnte keine Bestätigung finden, dass dies ein echter oder bekannter Fehler ist.

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

Das ist alles was ich in meinem habe /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)

Sehen Sie, wie OTHERJOBimmer ausgeführt wurde, während on Apr 1 pg_backup.shnicht einmal ausgeführt wurde.

Ich habe bereits versucht, neu zu starten, crondaber das passiert immer wieder. Dies betrifft mehrere Server mit derselben Version von Betriebssystem, Kernel und cronRPMs.

Es gibt eine neuere Version von cronie( 1.4.12), ein Upgrade ist jedoch keine Option, da wir bereits die neueste verfügbare Version für verwendenCentos 6.6

Ich habe das Changelog für alle cronieVersionen nach meiner ( 1.4.4) durchgesehen und habe anscheinend keine Lösung für dieses spezielle Problem gefunden. Überprüfte auch alle Festschreibungsnachrichten .

— Luis
quelle

Gute Fehlerbehebung. Warum nicht versuchen, eine letzte Zeile hinzuzufügen ( echo >/dev/nullz. B.)?

— Belmin Fernandez

Gibt es einen Ihrer Befehle, der einen Fehler auslöst? es könnte möglicherweise das Skript stoppen. Ich hatte ähnliche Erfahrungen mit init.d-Skripten.

— Hardik

Wie schnell werden die einzelnen Aufträge abgeschlossen? Wenn der Job, den Sie jede Minute starten, jedes Mal zwei Minuten lang ausgeführt wird, ist dies möglicherweise ein Problem. Aber wenn es in zwei Sekunden fertig ist, ist das wahrscheinlich kein Problem.

— Kasperd

Der Job, der jede Minute ausgeführt wird (OTHERJOB), wird in wenigen Sekunden abgeschlossen. Aber das ist nicht das Problem. Ich habe nur OTHERJOB zu den obigen Protokollen hinzugefügt, um zu zeigen, dass crond ausgeführt wurde und OTHERJOB korrekt verarbeitet wurde, während pg_backup.sh einfach nicht ausgeführt wurde.

— Luis

Überprüfen Sie /var/log/audit/audit.log.

— Michael Hampton

Antworten:

Für das ursprüngliche Cron musste jeder Eintrag mit einer neuen Zeile enden. Ja, manchmal benötigen Sie am Ende eine leere Zeile oder etwas anderes.

   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)

Einige Versionen haben es behoben oder geben eine Warnung aus, zum Beispiel Ubuntu Maverik (10.10): crontab Schauen Sie sich den Diagnoseabschnitt unten an, der besagt, dass eine Warnung in syslog geschrieben wird.

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.

— Brian
quelle

Dies ist die erste Antwort, die mit dem Suchtext geliefert wird, cron error getpwname failedsodass ich dachte, ich würde die Ursache meines Problems veröffentlichen:

Ich habe / etc / crontab verwendet, aber vergessen, den Benutzer vor den Befehl zu stellen.

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

Anstatt

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

Es gab den gleichen Fehler, gehen Sie Abbildung.

— Aaron R.
quelle

Wir verwenden sssdfür die Remote-Authentifizierung. crondmuss vor dem Ausführen von Jobs nach verfügbaren Benutzern suchen und dies alle 60 Sekunden. sssdStandard client_idle_timeoutist 60 Sekunden. Also hatten wir eine Rennbedingung zwischen sssdundcrond

Wir sind diesem Problem nur auf den Grund 1.4.4-14gegangen, weil crond in der Version etwas ausführlicher über einige Fehler war.

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

Nach dem Update auf diese Version wurde der folgende Fehler angezeigt, während ein Job nicht ausgeführt wurde:

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

das brachte uns dazu: https://bugzilla.redhat.com/show_bug.cgi?id=1209600#c2

und schließlich dazu: https://access.redhat.com/solutions/1125133

sssd_beProblem : Wird mit SIGKILL beendet, weil getpwnam () EPIPE zurückgibt (dh Rohrbruch), kann dies dazu führen, dass crond Cron-Jobeinträge stillschweigend überspringt.

Die vorgeschlagene Lösung für den obigen Link war das Hinzufügen der folgenden Zeile zu /etc/sssd/sssd.conf:

client_idle_timeout = 75

Die obige Änderung hat das Problem für uns behoben und cron überspringt keine Jobs mehr.

— Luis
quelle