Tengo un script programado que realiza una copia de seguridad svnsync cada 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 para mayor visibilidad (y porque uno de nuestros ingenieros eliminó accidentalmente el crontab porque pensó "crontab -r" significa "leer el crontab ;-))
Todos los comandos svnsync en el script cron.hourly fallan con un mensaje que dice que se debe aceptar el certificado SSL para el repositorio SVN (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 aceptado el mensaje no vuelve a aparecer).
Entonces me parece que el script se ejecuta 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 más en una cuestión de Subversión. Siempre trato de encapsular mi entorno en mis scripts, pero el problema aquí es que no estoy seguro de qué hay (o qué falta) en el entorno que hace que SVN solicite que se acepte el certificado SSL cuando ejecuto mi script desde cron.por hora. Supongo que tiene algo que ver con la forma en que se ejecuta el script run-parts.
Respuesta1
Desea utilizar la opción '--config-dir' para informarle dónde encontrar el certificado aceptado (por ejemplo, ~/.subversion de forma predeterminada).
Dicho esto, estoy casi seguro de que sería mejor que llamaras a svnsync desde el script de ganchos/post-commit, ya quesugerido en otro lugar. Entonces tu espejo siempre estará sincronizado, en lugar de estar sincronizado con donde estaba tu maestro hace una hora.
Respuesta2
En el sistema Debian/Ubuntu, cron.daily|weekly|montly 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 puedes ver, no hay nada particularmente especial en este entorno. Al menos en Debian/Ubuntu todo se ejecuta como cuenta raíz.
Cuando escribo scripts cron al comienzo del script, siempre configuro mi RUTA y otras variables de entorno que usaré, por lo que puedo estar seguro de que funcionará correctamente en cualquier entorno.
Respuesta3
Un crontab normal para todo el sistema es el crontab de un usuario específico y tiene el campo de nombre de usuario, como lo usa /etc/crontab.
El uso de scripts /etc/cron.*(por hora, diario, semanal, mensual) es una forma más limpia y sencilla (evita errores de sintaxis comunes) de configurar crontab para rootel usuario 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 de forma predeterminada ( /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 todavía) mediante:
sudo run-parts --report --test /etc/cron.daily
Respuesta4
En mi sistema RHEL 5.1, la variable de entorno PATH se configura desde /etc/crontab. Todo lo que está arriba es material que se introduce en el 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, simplemente notará que se ejecutó cron.hourly
Mi crontab está configurado de la siguiente manera:
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ías hacer es poner algo como lo siguiente en /etc/cron.hourly:
env > /tmp/cron.env
Luego inspeccione el archivo cuando aparezca y modifique su secuencia de comandos (si puede) para configurar el entorno correctamente, o escriba una secuencia de comandos breve que su crontab llamará.