Diferencia entre usar crontab y /etc/cron.hourly,daily,weekly

Tengo un script programado que realiza una copia de seguridad de svnsync por hora de nuestros repositorios de Subversion. Lo estaba ejecutando desde una entrada en el crontab raíz sin problemas, pero decidí que me gustaría ejecutarlo desde /etc/cron.hourly en su lugar para mayor visibilidad (y porque uno de nuestros ingenieros eliminó accidentalmente el crontab porque pensó "crontab" -r "quiso" leer el crontab ;-))

Todos los comandos de svnsync en el script cron.hourly fallan con un mensaje que dice que el certificado SSL para el repositorio SVN debe ser aceptado (este es el mensaje que recibe de forma interactiva la primera vez que el usuario accede al repositorio SVN, pero una vez que el certificado I aceptado el mensaje no vuelve a aparecer).

Entonces, me parece que el script se está ejecutando en un entorno de usuario diferente cuando se ejecuta desde cron.hourly que cuando se ejecuta a través del crontab raíz. ¿Alguien puede explicar la diferencia?

ACTUALIZACIÓN: Debería haber mencionado mi distribución, estoy usando anacron en CentOS 5.1.

ACTUALIZACIÓN 2: Gracias por las sugerencias hasta ahora; Creo que esto se está convirtiendo en una pregunta más de Subversion. Siempre trato de encapsular mi entorno en mis scripts, pero el problema aquí es que no estoy seguro de en qué está (o falta) el entorno que hace que SVN solicite que se acepte el certificado SSL cuando ejecuto mi script desde cron.hora. Supongo que tiene algo que ver con la forma en que se ejecuta el script run-parts.

Desea utilizar la opción '--config-dir' para hacerle saber dónde encontrar el certificado aceptado (por ejemplo, ~ / .subversion por defecto).

Dicho esto, estoy casi seguro de que sería mejor llamar a svnsync desde el script hooks / post-commit, como se sugiere en otra parte . Entonces su espejo siempre está sincronizado, en lugar de estar sincronizado con su maestro hace una hora.

En el sistema Debian / Ubuntu, cron.daily | semanal | mensual se inician desde el crontab principal.

17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

También tenga en cuenta que probablemente podría colocar un fragmento de crontab en /etc/cron.d/

Como puede ver, no hay nada particularmente especial en este entorno. Al menos en Debian / Ubuntu, todo se ejecuta como la cuenta raíz.

Cuando escribo secuencias de comandos cron al comienzo de la secuencia de comandos, siempre configuro mi RUTA y otras variables de entorno que usaré, por lo que puedo estar seguro de que funcionará correctamente en cualquier entorno.

Un crontab regular de todo el sistema es el crontab de un usuario específico y tiene el campo de nombre de usuario, tal como lo utiliza /etc/crontab.

El uso de scripts en /etc/cron.*(por hora, diario, semanal, mensual) es una forma más limpia y fácil (evita errores de sintaxis comunes) de configurar crontab para el rootusuario y esto se maneja mediante run-partsla ejecución de scripts o programas en un directorio. Todas estas reglas todavía están definidas en el crontab de todo el sistema por defecto ( /etc/crontab), por lo que es lo mismo.

Cuando los trabajos cron son manejados por run-parts, son más fáciles de depurar, ya que simplemente puede probar qué scripts se ejecutarían exactamente (sin ejecutarlos aún):

sudo run-parts --report --test /etc/cron.daily

Mi primera suposición salvaje sería verificar su variable HOME.

En mi sistema Centos, man 5 crontab dice:

El demonio cron (8) configura automáticamente varias variables de entorno. SHELL se establece en / bin / sh, y LOGNAME y HOME se configuran desde la línea / etc / passwd del propietario del crontab.

Entonces, si no ha especificado lo contrario, el crontab de root usaría / root para HOME. Pero en / etc / crontab (que es desde donde se ejecuta /etc/cron.hourly, a través de run-parts), HOME se establece en / (y SHELL en / bin / bash en lugar de / bin / sh).

No sé acerca de svnsync, pero subversion usa un directorio ˜ / .subversion /, por lo que podría depender de HOME.

En mi sistema RHEL 5.1, la variable de entorno PATH se establece desde / etc / crontab. Todas esas cosas en la parte superior son cosas que se alimentan al medio ambiente.

Si reinicia cron, la primera vez que se ejecute (si es desde /etc/crontabo /var/spool/cron/$USER) lo anotará en / var / log / cron. De lo contrario, solo notará que cron.hourly se ejecutó

Mi crontab se establece en lo siguiente:

01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

Lo que podría hacer es poner algo como lo siguiente en /etc/cron.hourly:

env > /tmp/cron.env

Luego inspeccione el archivo cuando aparezca, y modifique su script (si puede) para configurar el entorno correctamente, o escriba un script de envoltorio corto que llamará su crontab.

/var/log/messages (o el equivalente de su distribución) debería indicarle los detalles de qué comando se ejecutó cuándo y qué usuario.

Nunca asuma que hay algo en el medio ambiente. Siempre codifique defensivamente. Tiene un archivo completo para poner allí cualquier entorno que desee. Úsalo.

No mucho más la portabilidad, la última vez que verifiqué (en Debian) se recomendó poner cosas en cron.hourly (y las demás) y no directamente en crontab si quería crear un paquete con sus cosas.