Perché questa voce cron è eseguita due volte?

Question

*/5 * * * * mio comando

Questa voce funziona ma ogni 5 minuti viene eseguita due volte, perché?

in/var/log/cron mostra:
16 giu 22:20:01 test crond [12512]: (root) CMD (il mio comando)
16 giu 22:20:01 test crond [12516] : (root) CMD (mio comando)

Quindi non è da due uers.
Viene immesso solo una volta con crontab -e -u root

Il comando è un comando php.

Answer 1

Nulla nella descrizione dà motivo di eseguirlo due volte. Guarda altrove.

• Due utenti lo chiamano?
• È inserito due volte?
• Si chiama da solo?
• Si imposta in condizioni di movimento per la ripetizione?

Se si tratta di uno script di shell che si sta eseguendo, farla accoda whoami e date ad un file di log. Dovresti essere in grado di chiarire la ragione.

UPDATE

Tipo ps -A, assicurarsi crond non è in esecuzione due volte.

Answer 2

Di sicuro non è la voce crontab a causarne il funzionamento due volte. Il modo più veloce per scoprire cosa sta succedendo è aggiungere un po 'di debug allo script del cron job. Se non fai niente, per impostazione predefinita l'uscita cron verrà inviato a root@localhost (a meno che non si è configurato questo per essere diverso), quindi a patto di avere un accesso root, aggiungere alcune informazioni di debug per lo script, come ad esempio:

echo "Script starting" 
date 
whoami 

e guarda l'uscita. Questo ti aiuterà a capire come viene chiamato due volte.

Answer 3

Se si tratta di un comando per un'applicazione installata, è possibile che sia già stata aggiunta la stessa voce a /etc/crontab o /etc/cron.d/<something>.

Answer 4

Sembra che tu hai due in esecuzione di crond, uno con PID 12512 e uno con PID 12516.

Answer 5

Io confermo - il mio cron anche eseguito due volte ...

Jul 24 14:40:01 localhost cron[2713]: (root) CMD (/etc/apache2/generator/reloader.do) 
Jul 24 14:41:01 localhost cron[9481]: (root) CMD (/etc/apache2/generator/reloader.do) 
Jul 24 14:41:01 localhost cron[10724]: (root) CMD (/etc/apache2/generator/reloader.do) 
Jul 24 14:42:01 localhost cron[20380]: (root) CMD (/etc/apache2/generator/reloader.do) 
Jul 24 14:42:01 localhost cron[20832]: (root) CMD (/etc/apache2/generator/reloader.do) 

mio crontab

grep -R/var/spool/-e ricaricatore

/var/spool/cron/crontabs/root:* * * * * /etc/apache2/generator/reloader.do 

uscita:

whoami 
date 
------ 

uscita:

root 
root 
Tue Jul 24 14:46:02 CEST 2012 
--------- 
Tue Jul 24 14:46:03 CEST 2012 
--------- 

mia soluzione attuale è:

if [ -f /etc/apache2/generator/reloader.lock ] 
then 
exit 
fi 
touch /etc/apache2/generator/reloader.lock 
/etc/apache2/generator/reloader 
rm /etc/apache2/generator/reloader.lock 

Ma non è la risposta perché questo è accaduto ...

sistema - gentoo Cron - vixie-cron

parte ps aux wwf uscita (pranzato all'interno cron compito)

root  10843 0.0 0.0 16480 560 ?  Ss Jun06 0:01 /usr/sbin/cron 
root  29797 0.0 0.0 25020 964 ?  S 15:08 0:00 \_ /usr/sbin/cron 
root  29799 0.0 0.0 9188 1228 ?  Ss 15:08 0:00  \_ /bin/bash /etc/apache2/generator/reloader 
root  29822 0.0 0.0 14800 988 ?  R 15:08 0:00   \_ ps aux wwf 
------ 
root  8215 0.0 0.0 16480 836 ?  Ss 14:23 0:00 /usr/sbin/cron 
root  31419 0.0 0.0 25020 968 ?  S 15:08 0:00 \_ /usr/sbin/cron 
root  31423 0.0 0.0 9188 1228 ?  Ss 15:08 0:00  \_ /bin/bash /etc/apache2/generator/reloader 
root  31431 0.0 0.0 14804 1004 ?  R 15:08 0:00   \_ ps aux wwf 

EDIT:

01.235.164,106 mila

Ho notato, che uno dei rapporto di processo cron jun06 come data di inizio (oggi è Jun24)

root  10843 0.0 0.0 16480 560 ?  Ss Jun06 0:01 /usr/sbin/cron 
root  8215 0.0 0.0 16480 836 ?  Ss 14:23 0:00 /usr/sbin/cron 

Seconda relazione processo in modo corretto (uprime del server è ~ 40 minuti - ho fatto ricomincio recenty) Un importante informazioni - è V-server in esecuzione sulla macchina host.

Non importa quello che faccio (/etc/init.d/vixie-cron riavvio) Si parte di con lo stesso PID

RISOLTO:

ho trovato il motivo. Un server V è stato eseguito due volte, con un contesto diverso. possibile spiegazione - qualcuno ha cambiato il contesto, mentre la macchina era in esecuzione, e, di conseguenza, non tutti i processi sono stati uccisi, e che cosa; s più - che ha influenzato nuova istanza di vserver (contesto 303 e 3031):

root     10843  3031 developer      0.0  0.0  16480   560 ?        Ss   Jun06   0:01 /usr/sbin/cron 
root     16509   303 developer      0.0  0.0  16480   836 ?        Ss   15:18   0:00 /usr/sbin/cron 

Ho terminato il vecchio processo e il problema è risolto.

Answer 6

Io uso OpenWrt.

Ho lo stesso problema, ma ho solo un cron: ps | grep crond:

31447 root  1508 S /usr/sbin/crond -c /etc/crontabs -l 8 
31454 root  1500 S sh -c ps | grep crond 
31456 root  1496 S grep crond 

logread | grep cron

May 27 13:15:01 decibox cron.info crond[31447]: crond: USER root pid 1594 cmd /root/check_connect.php.sh 
May 27 13:20:01 decibox cron.info crond[31447]: crond: USER root pid 2103 cmd /root/check_connect.php.sh 
May 27 13:20:01 decibox cron.info crond[31447]: crond: USER root pid 2325 cmd /root/check_connect.php.sh 
May 27 13:25:01 decibox cron.info crond[31447]: crond: USER root pid 2880 cmd /root/check_connect.php.sh 

Answer 7

Il wget in crontab ha spesso un limite di 15 minuti. Nel nostro caso questo è stato il caso, e dopo quei 15 minuti il ​​lavoro termina con un timeout e poi ri-corre di nuovo subito. Quindi, la soluzione era impostare il cronjob in crontab in questo modo:

1 2 * * * root wget --read-timeout=3600 -O - 'http://cron-job-url' >/dev/null 2>&1 

...invece di

1 2 * * * root wget -O - 'http://cron-job-url' >/dev/null 2>&1 

Quindi, wget è la cosa. Significato 3600 = 1 ora, quindi. O più se hai bisogno!

Answer 8

Ho avuto lo stesso problema una volta, nel mio caso è stato che ho inizializzato il servizio cron due volte per errore. Dopo aver fermato cron # /etc/init.d/crond stop e avviato di nuovo # /etc/init.d/crond start, ha funzionato perfettamente.

Spero che questo possa aiutare nessuno.