¿Por qué esta entrada cron se ejecuta dos veces?
-
05-07-2019 - |
Pregunta
*/5 * * * * my command
Esta entrada funciona pero cada 5 minutos se ejecuta dos veces, ¿por qué?
En / var / log / cron
se muestra:
Jun 16 22:20:01 Test CROND[12512]: (root) CMD (my command)
Jun 16 22:20:01 Test CROND[12516]: (root) CMD (my command)
Así que no es de dos usuarios.
Solo se ingresa una vez con crontab -e -u root
. El comando es un comando php.
Solución
Nada en la descripción da razones para que se ejecute dos veces. Busca en otro lado.
- ¿Lo llaman dos usuarios?
- ¿Se ha ingresado dos veces?
- ¿Se llama a sí mismo?
- ¿Establece condiciones de movimiento para la repetición?
Si es un script de shell que está ejecutando, haga que agregue whoami
y date
a un archivo de registro. Deberías poder desenterrar la razón.
ACTUALIZACIÓN
Escriba ps -A, asegúrese de que crond no se ejecute dos veces.
Otros consejos
El wget en crontab tiene a menudo 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 se vuelve a ejecutar de inmediato. Entonces, la solución a esto fue configurar el cronjob en crontab de esta manera:
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
Entonces, wget es la cosa. Significado 3600 = 1 hora entonces. ¡O más si lo necesitas!
Si es un comando para una aplicación que instaló, tal vez ya haya agregado la misma entrada a / etc / crontab
o /etc/cron.d/<something>
.
Confirmo: mi cron también se 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 reloader
/var/spool/cron/crontabs/root:* * * * * /etc/apache2/generator/reloader.do
salida de:
whoami
date
------
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 la que eso sucede ...
Sistema - gentoo Cron - vixie-cron
parte de la salida de ps aux wwf
(agrupada dentro de la tarea cron)
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
EDITAR:
Me di cuenta de que uno de los informes del proceso cron es 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 de proceso correcto (el tiempo de funcionamiento del servidor es de ~ 40 minutos; lo reinicié recientemente) Una información importante: es el servidor V que se ejecuta en la máquina host.
No importa lo que haga (/etc/init.d/vixie-cron restart) comienza con el mismo PID
RESUELTO:
He encontrado la razón. Un servidor V se ejecutó dos veces, con un contexto diferente. Posible explicación: alguien ha cambiado el contexto mientras se estaba ejecutando la máquina y, como resultado, no se eliminaron todos los procesos y, lo que es más, afectaron la 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
He terminado el proceso anterior, y el problema está resuelto.
Seguro que no es la entrada de crontab lo que hace que se ejecute dos veces. La forma más rápida de descubrir lo que está sucediendo es agregar algo de depuración a la secuencia de comandos del trabajo cron. Si no hace nada, entonces, de forma predeterminada, la salida cron se enviará a root @ localhost
(a menos que haya configurado esto para que sea diferente), por lo que, suponiendo que tenga acceso de root, agregue información de depuración al script. , tales como:
echo "Script starting"
date
whoami
y mira la salida. Esto te ayudará a descubrir cómo se llama dos veces.
Una vez tuve el mismo problema, en mi caso fue que inicialicé el servicio cron dos veces por error. Después de que dejé de cron # /etc/init.d/crond stop
y lo volví a iniciar # /etc/init.d/crond start
, funcionó perfectamente.
Espero que esto pueda ayudar a cualquiera.
Parece que tienes dos crond en funcionamiento, uno con PID 12512 y otro con PID 12516.
Yo uso OpenWrt.
Tengo el mismo problema, pero solo tengo 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
Tuve el mismo problema debido a una doble entrada en el archivo conf:
# grep /syslog /etc/rsyslog.conf /etc/rsyslog.d/50-default.conf
/etc/rsyslog.conf:*.*;auth,authpriv,kern,mail.none -/var/log/syslog
/etc/rsyslog.d/50-default.conf:*.*;auth,authpriv,kern,mail.none -/var/log/syslog
Comentar claramente uno de los 2 resuelve el problema