trabajo cron ocasionalmente no se ejecuta

Tengo un CentOS 6.6servidor con los siguientes paquetes instalados:

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 veces, uno de los trabajos de respaldo que está programado para ejecutarse diariamente simplemente no se ejecuta. El script ni siquiera se llama de acuerdo con /var/log/cron.log. Es interesante mencionar que otros trabajos programados para ejecutarse exactamente al mismo tiempo se ejecutan sin problemas.

No puedo reproducir el problema y no he visto ningún patrón en él. Si no hago nada, el trabajo se ejecuta correctamente al día siguiente como se esperaba.

crond simplemente ignora solo uno de los múltiples trabajos que se supone que se ejecutan en un momento determinado. Esto solo ocurre esporádicamente.

Leí en algunos otros lugares que la gente habla sobre agregar una línea vacía al final del crontabarchivo. El trabajo que ocasionalmente no se ejecuta se encuentra en la última línea de mi crontabarchivo. No pude encontrar ninguna confirmación de que este es un error real o conocido.

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

Esto es todo lo que tengo en mi /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)

Vea cómo OTHERJOBsiempre se ejecuta mientras está encendido Apr 1 pg_backup.shni siquiera se ejecutó.

Ya he intentado reiniciar crondpero esto sigue sucediendo. Esto está afectando a múltiples servidores con la misma versión de SO, kernel y cronRPM.

Hay una versión más nueva de cronie( 1.4.12), sin embargo, actualizarla no es una opción ya que ya estamos usando la última versión disponible paraCentos 6.6

Revisé el registro de cambios para todas las cronieversiones después de la mía ( 1.4.4) y no parece haber ninguna solución para este problema en particular. También verificó todos los mensajes de confirmación .

— Luis
fuente

Buena solución de problemas. ¿Por qué no intentar agregar una última línea noop ( echo >/dev/nullpor ejemplo)?

— Belmin Fernández

¿Hay alguno de sus comandos arrojar error? posiblemente podría detener el guión. Tuve una experiencia similar con los scripts init.d.

— hardik

¿Qué tan rápido se completa cada uno de los trabajos? Si el trabajo que comienza cada minuto se ejecuta durante dos minutos cada vez, entonces eso podría ser un problema. Pero si se completa en dos segundos, entonces eso probablemente no sea un problema.

— Kasperd

El trabajo que se ejecuta cada minuto (OTHERJOB) se completa en unos segundos. Pero ese no es el problema. Solo agregué OTHERJOB a los registros anteriores para mostrar que crond se estaba ejecutando y OTHERJOB se procesó correctamente mientras que pg_backup.sh simplemente no se ejecutó.

— Luis

Compruebe /var/log/audit/audit.log.

— Michael Hampton

Respuestas:

El cron original requería que cada entrada terminara con una nueva línea, así que sí, a veces se necesita una línea en blanco o algo al final.

   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)

Algunas versiones lo tienen arreglado o emiten una advertencia, por ejemplo Ubuntu Maverik (10.10): crontab mira la sección de diagnóstico en la parte inferior que indica que se escribirá una advertencia en 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
fuente

Esta es la primera respuesta que aparece con el texto de búsqueda, cron error getpwname failedasí que pensé en publicar la causa de mi problema:

Estaba usando / etc / crontab pero había olvidado poner al usuario delante del comando.

es decir,

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

En vez de

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

Dio el mismo error, vaya figura.

— Aaron R.
fuente

Utilizamos sssdpara la autenticación remota. crondtiene que verificar los usuarios disponibles antes de ejecutar trabajos y lo hace cada 60 segundos. sssdEl valor predeterminado client_idle_timeoutes 60 segundos. así que tuvimos una condición de carrera entre sssdycrond

Solo llegamos al fondo de este problema porque en la versión 1.4.4-14crond comenzó a ser un poco más detallado sobre algunos errores.

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

Después de actualizar a esa versión, comenzamos a ver el siguiente error al mismo tiempo que no se ejecutaba un trabajo:

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

que nos trajo a esto: https://bugzilla.redhat.com/show_bug.cgi?id=1209600#c2

y finalmente a esto: https://access.redhat.com/solutions/1125133

Problema: sssd_beterminado con SIGKILL debido a que getpwnam () devuelve EPIPE (es decir, tubería rota) puede hacer que crond omita silenciosamente las entradas de trabajo cron.

La solución sugerida en el enlace de arriba fue agregar la siguiente línea para /etc/sssd/sssd.conf:

client_idle_timeout = 75

El cambio anterior nos ha solucionado el problema y cron ya no se salta los trabajos.

— Luis
fuente