¿Por qué esta entrada cron se ejecuta dos veces?

Question

*/5 * * * * mi comando

Esta entrada funciona pero cada 5 minutos se ejecuta dos veces, ¿por qué?

en/var/log/cron se muestra:
Jun 16 de 22:20:01 crond prueba [12512]: (raíz) CMD (mi mando)
Jun 16 de 22:20:01 crond prueba [12516] : (raíz) CMD (mi comando)

Así que no es de dos uers.
Solo se ingresa una vez con crontab -e -u root

El comando es un comando php.

Answer 1

Nada en la descripción da motivos para que se ejecute dos veces. Mira en otro lado.

• ¿Lo llaman dos usuarios?
• ¿Se ingresó dos veces?
• ¿Se llama a sí mismo?
• ¿Se pone en movimiento para la repetición?

Si se trata de un script de shell que está ejecutando, tienen que anexar whoami y date a un archivo de registro. Deberías poder desenterrar la razón.

ACTUALIZACIÓN

Tipo ps -A, asegúrese crond no se está ejecutando dos veces.

Answer 2

Por supuesto que no es la entrada del crontab lo que causa que se ejecute dos veces. La manera más rápida de descubrir qué está pasando es agregar algo de depuración al script de trabajo cron. Si no hace nada, entonces por defecto la salida cron será enviada a root@localhost (a menos que haya configurado que esto sea diferente), por lo que suponiendo que tiene acceso a la raíz, añadir un poco de información de depuración a la secuencia de comandos, tales como:

echo "Script starting" 
date 
whoami 

y mira la salida. Esto lo ayudará a comenzar a descubrir cómo se llamará esto dos veces.

Answer 3

Si se trata de un comando para una aplicación que instaló, tal vez ya haya agregado la misma entrada a /etc/crontab o /etc/cron.d/<something>.

Answer 4

Parece que usted tiene dos de fórmula de crond, uno con PID 12512 y otro con PID 12516.

Answer 5

Yo confirmo - mi cron también ejecuta dos veces ...

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) 

Mi crontab

grep -R/var/spool/-e recargador

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

salida:

whoami 
date 
------ 

de salida:

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

Mi solución actual es:

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 

Pero no es la respuesta por qué eso es pasar ...

Sistema - gentoo Cron - vixie-cron

parte de ps aux wwf salida (almorzaron en el interior de cron tarea)

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:

Me di cuenta de que uno de informe de proceso de cron Jun06 como fecha de inicio (hoy es 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 

Segundo informe del proceso correctamente (uprime servidor es ~ 40 minutos - lo hice recomienzo recenty) Una información importante - Es el servidor V ejecutándose en la máquina host.

No importa lo que hago (/etc/init.d/vixie-cron reinicio) que largada con el mismo PID

resuelto:

he encontrado la razón. Un servidor V se ejecutó dos veces, con un contexto diferente. explicación posible - alguien ha cambiado el contexto mientras la máquina estaba en funcionamiento, y como resultado, no fueron muertos todos los procesos, y qué; s más - que afectaron nueva instancia de vserver (contexto 303 y 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 

Tengo el proceso TÉRMINO anterior, y el problema está resuelto.

Answer 6

Uso OpenWrt.

Tengo el mismo problema, pero tengo 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

El wget en crontab a menudo tiene un límite de 15 minutos. En nuestro caso, este fue el caso, y después de esos 15 minutos, el trabajo termina con un tiempo de espera y luego vuelve a funcionar de inmediato. Por lo tanto, la solución a esto era configurar el cronjob en crontab algo como esto:

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

...en lugar de

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

Por lo tanto, wget es la cosa. Significado 3600 = 1 hora, entonces. ¡O más si lo necesitas!

Answer 8

Tuve el mismo problema una vez, en mi caso fue que inicialicé el servicio cron dos veces por error. Después de detener cron # /etc/init.d/crond stop y lo inicié de nuevo # /etc/init.d/crond start, funcionó perfectamente.

Espero que esto pueda ayudar a cualquiera.