El trabajo cron diario no se está ejecutando

10

Una descripción rápida: tengo un script que respaldará diariamente mi repositorio de código fuente desde SVN en un tarball para ese día. He probado el script y funciona muy bien siempre que lo ejecute como sudo, debido a la propiedad del directorio de salida.

Entonces, el problema es que quiero ejecutar esto a diario, así que puse un enlace en el directorio /etc/cron.daily. Aquí están los contenidos del directorio.

thom@spenser:/etc/cron.daily$ ls -l
total 60
-rwxr-xr-x 1 root root   189 2011-09-14 02:21 apport
-rwxr-xr-x 1 root root 15535 2011-10-06 11:30 apt
-rwxr-xr-x 1 root root   314 2011-08-08 16:57 aptitude
lrwxrwxrwx 1 root root    24 2012-02-28 11:05 backup -> /usr/local/bin/backup.sh
-rwxr-xr-x 1 root root   502 2011-06-08 11:48 bsdmainutils
-rwxr-xr-x 1 root root   256 2011-10-06 04:04 dpkg
-rwxr-xr-x 1 root root   372 2011-10-04 16:50 logrotate
-rwxr-xr-x 1 root root  1353 2011-07-27 07:17 man-db
-rwxr-xr-x 1 root root   606 2011-08-17 09:16 mlocate
-rwxr-xr-x 1 root root   249 2011-06-24 05:36 passwd
-rwxr-xr-x 1 root root  2417 2011-07-01 17:25 popularity-contest
-rwxr-xr-x 1 root root   383 2011-09-30 15:09 samba
-rwxr-xr-x 1 root root  3594 2011-09-19 20:07 standard
thom@spenser:/etc/cron.daily$

El problema es que simplemente nunca se ejecuta. Aquí están los permisos para ese script:

thom@spenser:/etc/cron.daily$ ls -l /usr/local/bin/backup.sh 
-rwxr-xr-x 1 root root 260 2012-02-28 11:03 /usr/local/bin/backup.sh

Ideas?

bash cron Thom
fuente
2
Si es posible, considere cerrar algunas de sus otras preguntas abiertas seleccionando la mejor respuesta (si tienen una). Necesitamos que los usuarios mantengan sus preguntas para que el sitio pueda ser una herramienta efectiva para la próxima persona con sus problemas. Para obtener más detalles sobre las mejores prácticas, considere leer las preguntas frecuentes sobre cómo hacer preguntas .
Bruno Pereira

Respuestas:

37

Probé esto

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

Descubrí que mi archivo update.ubuntu no apareció. También noté que mi archivo tenía una extensión (tiene un punto).

Pasos para arreglar esto.

  1. Cambié el nombre de mi update.ubuntu a update-ubuntu
  2. Ahora run-parts --test /etc/cron.daily, de nuevo , esta vez apareció mi archivo.
D Durga Prasad
fuente
1
Sí, esto me lo arregló. No le gustan los puntos en el nombre del archivo, renombrar mi archivo de myscript.sh a myscript funcionó para mí.
Matt Parkins
3
Esto necesita ser más alto. Tenía mi script guardado como el tradicional "backup.sh". La eliminación de la parte ".sh" lo resolvió. ¡Gracias una tonelada!
David
¡Gracias! ¡El chico / chica que decidió eliminar implícitamente los archivos .sh del cron diario debería avergonzarse!
Sylvain
¡Debería ser azotado públicamente! ;-) Me pregunto cuánto tiempo la gente perdió colectivamente debido a esta decisión ... También me pregunto si hubo una buena razón para ello.
xastor
3

Podría ser una de varias cosas:

Ruta de las raíces:

Dependiendo de los comandos que se ejecuten, es posible que deba expandir la variable PATH de los usuarios raíz colocando la siguiente línea en la parte superior de su archivo crontab:

RUTA = / usr / sbin: / usr / bin: / sbin: / bin

src: https://help.ubuntu.com/community/CronHowto

O simplemente use rutas completas para cada comando en su script: en /bin/lslugar de, lspor ejemplo. ( which lsen la línea de comando para rutas).

Hay un extraño error sobre los puntos en el nombre de archivo que se informa aquí . Podría extenderse al archivo al que está vinculando, aunque esto parece poco probable.

¿Está guardando la salida del archivo de copia de seguridad? Ponga algo como esto en la primera línea, para ayudar a determinar si no se está ejecutando o si se está ejecutando pero falla en algún momento.

/bin/echo "Attempting to run backup" >> /path-to-home/backup.log

Alternativamente, intente agregar el script al archivo crontab directamente:

sudo -i
crontab -e
[add the next line to the file, then save and exit]
33 15 * * * /usr/local/bin/backup.sh

funcionará a las 15:30 todos los días si la máquina está encendida. use * * * * * mientras realiza la prueba para que se ejecute una vez por minuto hasta que funcione.

Sean
fuente
1
Se desaconseja el uso de rutas absolutas en los scripts. Si no sabe qué es PATH, configúrelo usted mismo en el script. Ver razones por las que crontab no funciona
geirha
Enlace útil, gracias. La razón dada para no usar rutas completas es la portabilidad. Lo suficientemente justo. Otra solución razonable es definir los comandos que está utilizando al comienzo del script, junto con otras configuraciones: LS = / bin / ls; SRC_DIR = / home / joe / src. Luego use $ LS $ SRC_DIR. Mantiene todo definido en la parte superior y en un solo lugar.
Sean
Me parece que para reducir la legibilidad, y tienes que revisar cada comando COMMAND = / path / to / para cada nuevo sistema en el que debería ejecutarse. En un sistema, todos los comandos que necesita podrían estar en / usr / bin, en otro algunos están en / bin, otros en / usr / bin. Solo tener / usr / bin y / bin en PATH hace que no sea un problema. En una nota al margen, los nombres de las variables deben estar en minúsculas, de lo contrario corre el riesgo de anular variables especiales de shell o variables de entorno.
geirha
re: nombres de variables en mayúscula. Siempre lo he hecho sin pensarlo mucho, debido a los primeros guiones que vi hacerlo. Pero tienes razón, no hay ventajas ni posibilidades de desventajas. Gracias por señalar esto, rompiendo este hábito ahora.
Sean
1

Grep su syslog para mensajes como;

crond: (*system*) BAD FILE MODE

los archivos deben restringirse a (es suficiente) en 644):

chmod 0644 /etc/cron.d/my_crontab
Tom H
fuente