Determinare il problema con CRON non in esecuzione

Come posso determinare eventuali problemi con i comandi cron /etc/crontab non in esecuzione? Ho degli script che inviano messaggi di posta elettronica, posso eseguirli manualmente tramite la row di command e funzionano ottimamente ma non vengono mai elaborati da cron ….

Cosa posso fare per eseguire il debugging del motivo per cui il cron non è in esecuzione?

Ho una sensazione che fa parte del problema …

 $ sudo /etc/init.d/crond start sudo: /etc/init.d/crond: command not found 

  • UID di authentication di OpenLDAP contro i problemi di CN
  • MySQL non è riuscito a iniziare a causa di molte tabelle di InnoDB?
  • KVM su Ubuntu: la connessione della console non mostra nulla
  • In Ubuntu faccio modifiche a php.ini ma non succede niente
  • apt Package non è ancora configurato
  • Qual è un modo semplice per impostare un proxy autenticato HTTP o SOCKS?
  • Puppet: rimozione dei pacchetti e garanzia di arresto
  • Esegui lo script da rc.local come utente invece che root
  • 4 Solutions collect form web for “Determinare il problema con CRON non in esecuzione”

    Hai qualche possibilità, in nessun ordine particolare.

    • Esegui il command che hai in crontab sulla row di command. Ciò può essere ingannevole poiché spesso questo functionrà per te e il motivo per cui non è in esecuzione in cron è una variabile di ambiente mancante o qualcosa lungo queste righe.

    • Aggiungere un'opzione di output alla linea crontab, ad esempio:

      5 */2 * * * /usr/local/bin/do-stuff.sh >> /tmp/results.log;

    • Assicurarsi che il cron sia in esecuzione.

    • Controllare i file di log di cron per eventuali errori particolari.

    Oltre alle risposte di @muffinista e @ brent, ci sono altri problemi esoterici che puoi eseguire su Ubuntu

    • Hai bisogno di una row vuota alla fine del tuo crontab.
    • L'utente deve essere in | no-in /etc/cron.allow|cron.deny (o se questi file sono assenti)
      • l'utente non deve essere membro del gruppo crontab
    • cron può ignorare i nomi di file che non piace in directory /etc/cron.d/ e simili.
      • aggiungi l'opzione '-l' di cron (impatto spiegato più in 'man run-parts')
    • cron invia le voci di crontab tramite / bin / sh (per impostazione predefinita), in modo che le cose così semplici come questo non riescano, ma funzionano quando incollate nel terminal / bin / bash

      0 * * * * echo hi >& /dev/null

      quindi cambia SHELL o la tua syntax di reindirizzamento!

    La mia versione di Ubuntu ignora le impostazioni in / etc / defaults / cron, in modo da sbattere il livello di log che potrebbe essere necessario eseguire manualmente il cron daemon (cron -f -L 2).

    In alcuni casi recenti, ciò è dovuto a persone che modificano le cose in /etc/crontab senza submit il segnale crud 1 (SIGHUP) per farlo sapere che dovrebbe rivedere il /etc/crontab .

    Provare

     kill -1 $PID-OF-CROND 

    e vedere se questo aiuta. Determinare il pid di crond è lasciato come un esercizio per te 😉 – non da ultimo perché se non lo riesci a trovare, potrebbe significare che la crond non è in esecuzione e poi avrai trovato il tuo problema!

    Se stai usando il shellScript, spesso si dimentica che i comandi che utilizzano nel loro script potrebbero non essere nel PATH di cron (ad esempio, qualcosa in /opt ). Imposta il tuo PATH correttamente all'inizio del tuo script, se necessario. Per sh / bash, sarebbe:

     PATH=$PATH:/opt/something-1.0/bin 

    per esempio

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.