Tengo un crontab que crea un volcado de mi base de datos todas las noches:
20 3 * * * /path/to/dailydump.sh
dailydump.shcontiene:
#!/bin/sh
DATENAME=`date +%Y%m%d`
BASENAME="/path/to/dumps/db_${DATENAME}.sql"
/usr/bin/mysqldump -hhost -uusername -ppassword databasename > ${BASENAME}
Los permisos son:
-rwx---r-x 1 ... dailydump.sh
drwxr-xrwx 2 ... dumps
¿Por qué mi cronjob no funciona?
Estoy en un servidor compartido sin acceso root. No hay inicios de sesión /var/log/crono /var/log/syslog. No hay correo en /var/mail/<user_name>o /var/spool/mail/<user_name>(de hecho, no hay nada en /var/mail/y /var/spool/), [email protected]no envía ningún mensaje de error y 1 2 * * * /path/to/your/command &>/path/to/mycommand.logno guarda ningún archivo de registro. ps -ef | grep cron | grep -v grep?no devuelve nada. (Verhttps://serverfault.com/a/449652)
Toda la configuración funcionó bien hasta que moví todos los archivos a un nuevo dominio y tuve que configurar un nuevo crontab. (Sí, actualicé todas las rutas y la información de inicio de sesión de la base de datos. También lo verifiqué varias veces). Estoy con el mismo proveedor de alojamiento en la misma máquina, por lo que el entorno no ha cambiado.
Cualquier ayuda sería muy apreciada.
"Solución"
Vale, esto es muy extraño. El centro de ayuda de mi proveedor dice que si el script que ejecutará un cronjob se encuentra dentro de un directorio protegido con contraseña, debo agregar -auth=user:password -sourceantes la ruta al script. Entonces agregué eso (con la autenticación adecuada):
20 3 * * * -auth=user:password -source /path/to/dailydump.sh
El resultado fue queme enviaron un mensaje de error por correo electrónico(Así MAILTO=funciona), indicándome /bin/sh: -=: invalid optiony enumerando las opciones disponibles. El ejemplo en el centro de ayuda en realidad no proporcionaba una ruta física ( /path/to/file), sino una URL ( http://...), así que eliminé authuna y sourceotra vez y guardé el crontab, y¡¡Ahora se ejecuta el maldito cronjob!!'El crontab se ve exactamente como antes, carácter por carácter, pero ahora se ejecuta, sin cambios aparentes en el código.
No tengo idea de cuál fue el problema, pero insertar un código incorrecto y eliminarlo nuevamente funcionó. o_O Parece como si el cronjob realmentehizose ejecuta todo el tiempo (porque cuando no lo hace, obviamente arroja un error), solo que¡Hice nada!Muy misterioso. Si alguien puede explicarme eso (de manera reproducible), ofreceré una recompensa de 200 y la otorgaré (después de la espera necesaria de dos días).
Además, @chaos me dio otra solución, evitando por completo el script de shell y permitiendo que cron volcara la base de datos directamente (vea los comentarios a su respuesta a continuación):
20 3 * * * /usr/bin/mysqldump -hhost -uusername -ppassword nombre de base de datos > /ruta/a/dumps/db_$(fecha +\%Y\%m\%d).sql
Simplemente no olvides omitir los signos de porcentaje, o el guión encontrará un "EOF inesperado".
Gracias a todos por su ayuda. Aprendí mucho nuevamente (aunque no lo que estaba mal aquí).
Respuesta1
Para asegurarse de que el crondemonio se esté ejecutando y respetando el crontab, puede realizar una pequeña prueba. Edita tu crontabcon una entrada como esta:
* * * * * /bin/date >>/tmp/test
Después de un minuto, verifique el archivo /tmp/test. Si no hay ningún archivo, lo más probable es que el demonio no se esté ejecutando. Si ese es el caso, me pondría en contacto con el soporte del proveedor.
Editar:
Para determinar el entorno en la instancia cron, haga lo siguiente:
* * * * * /usr/bin/id >>/tmp/test
* * * * * /usr/bin/env >>/tmp/test
Ahora vea el contenido del archivo.
Respuesta2
- Ejecute el script directamente y compruebe si funciona.
- Es posible que algunas de las variables de entorno del shell no estén disponibles cuando el script se ejecuta en crontab, dependiendo de cómo configure el script.
Intente modificar el script para probar si el problema son las variables de entorno:
sh --login -c "/usr/bin/mysqldump -hhost -uusername -ppassword databasename > ${BASENAME} > /path/to/LogFile.txt 2>&1"