cron job occasionalmente non in esecuzione

Ho un CentOS 6.6server con i seguenti pacchetti installati:

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

A volte, uno dei processi di backup che è pianificato per l'esecuzione giornaliera semplicemente non viene eseguito. Lo script non è nemmeno chiamato secondo /var/log/cron.log. Interessante ricordare che altri lavori pianificati per l'esecuzione esattamente allo stesso tempo vengono eseguiti senza problemi.

Non riesco a riprodurre il problema e non ho individuato alcun motivo su di esso. Se non faccio nulla, il lavoro verrà eseguito correttamente il giorno successivo come previsto.

crond semplicemente ignora solo uno dei molteplici lavori che dovrebbero essere eseguiti in un determinato momento. Questo succede solo sporadicamente.

Ho letto in alcuni altri posti le persone che parlano di aggiungere una riga vuota alla fine del crontabfile. Il lavoro che occasionalmente non riesce a essere eseguito è davvero all'ultima riga del mio crontabfile. Non sono riuscito a trovare alcuna conferma che si tratti di un bug reale o noto.

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

Questo è tutto ciò che ho nel mio /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)

Scopri come OTHERJOBeseguire sempre mentre acceso Apr 1 pg_backup.shnon è stato nemmeno eseguito.

Ho già provato a riavviare, crondma questo continua a succedere. Ciò riguarda più server con la stessa versione di SO, kernel e cronRPM.

Esiste una versione più recente di cronie( 1.4.12), tuttavia l'aggiornamento non è un'opzione poiché stiamo già utilizzando l'ultima versione disponibile perCentos 6.6

Ho esaminato il log delle modifiche per tutte le cronieversioni successive alla mia ( 1.4.4) e non mi è sembrata alcuna soluzione a questo particolare problema. Ho anche controllato tutti i messaggi di commit .

— Luis
fonte

Buona risoluzione dei problemi. Perché non provare ad aggiungere un'ultima riga noop ( echo >/dev/nullad es.)?

— Belmin Fernandez,

C'è qualcuno dei tuoi comandi che genera errore? potrebbe fermare la sceneggiatura. Ho avuto un'esperienza simile con gli script init.d.

— hardik,

In quanto tempo completa ciascuno dei lavori? Se il lavoro che si avvia ogni minuto viene eseguito per due minuti ogni volta, ciò potrebbe costituire un problema. Ma se si completa in due secondi, probabilmente non è un problema.

— Kasperd,

Il processo che viene eseguito ogni minuto (OTHERJOB) viene completato in pochi secondi. Ma non è questo il problema. Ho appena aggiunto OTHERJOB ai registri sopra per mostrare che crond era in esecuzione e OTHERJOB è stato elaborato correttamente mentre pg_backup.sh semplicemente non è stato eseguito.

— Luis,

Controllare /var/log/audit/audit.log.

— Michael Hampton,

Risposte:

Il cron originale richiedeva che ciascuna voce terminasse con una nuova riga, quindi a volte è necessario una riga vuota o qualcosa alla fine.

   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)

Alcune versioni lo hanno riparato o emettono un avviso, ad esempio Ubuntu Maverik (10.10): crontab guarda la sezione diagnostica in basso che afferma che un avviso verrà scritto su 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.

— Brian
fonte

Questa è la prima risposta che viene fornita con il testo di ricerca, cron error getpwname failedquindi ho pensato di pubblicare la causa del mio problema:

Stavo usando / etc / crontab ma avevo dimenticato di mettere l'utente davanti al comando.

vale a dire,

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

Invece di

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

Ha dato lo stesso errore, vai a capire.

— Aaron R.
fonte

usiamo sssdper l'autenticazione remota. cronddeve verificare la presenza di utenti disponibili prima di eseguire i lavori e lo fa ogni 60 secondi. sssdil valore predefinito client_idle_timeoutè 60 secondi. quindi abbiamo avuto una condizione di competizione tra sssdecrond

Siamo arrivati solo alla fine di questo problema perché sulla versione 1.4.4-14crond ha iniziato a essere un po 'più prolisso su alcuni errori.

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

Dopo l'aggiornamento a quella versione abbiamo iniziato a vedere l'errore di seguito nello stesso momento in cui un lavoro non sarebbe stato eseguito:

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

che ci ha portato a questo: https://bugzilla.redhat.com/show_bug.cgi?id=1209600#c2

e infine a questo: https://access.redhat.com/solutions/1125133

Problema: sssd_beterminato con SIGKILL a causa della restituzione di getpwnam () che restituisce EPIPE (es. Pipe spezzate) può far sì che crond salti silenziosamente le voci del lavoro cron.

La soluzione suggerita sul link sopra è stata aggiungere la riga seguente a /etc/sssd/sssd.conf:

client_idle_timeout = 75

La modifica sopra ha risolto il problema per noi e cron non salta più i lavori.

— Luis
fonte