Por alguna razón extraña no puedo guardar una copia de seguridad generada de MySQL a través de mysqldump en una unidad de red afp como un trabajo cron. Si ejecuto el script de shell como usuario root (iniciar sesión a través de sudo su en la terminal), funciona perfectamente. Así que el script está bien. Debe tener algo que ver con el trabajo cron en sí.
Para hacerlo, edité el crontab de root usando crontab -e de la siguiente manera:
10 12 * * 1-5 sh /var/root/cronjobs/mysql_backup.workdaily.shEsto le indica al demonio cron que lo ejecute cada día laborable (de lunes a viernes) a las 12:10 PM.
Con la misma llamada desde la terminal funciona (como se describió anteriormente).
Este es el script de shell que estoy usando para hacerlo:
#!/usr/bin/env sh
LOCALMOUNTPOINT="/Volumes/MyDrive"
# verificar si la unidad de red está montada
if mount | grep "on $LOCALMOUNTPOINT" > /dev/null; then
echo "montado"
else
# no necesario la verificación a continuación, pero mucho más seguro en la ejecución de trabajos cron:
if ls -lha /Volumes | grep "$LOCALMOUNTPOINT" > /dev/null; then
mount -t afp "afp://username:password@NETWORKDRIVE%28AFP%29._afpovertcp._tcp.local/Subfolder" /Volumes/MyDrive
else
mkdir /Volumes/MyDrive && mount -t afp "afp://username:password@NETWORKDRIVE%28AFP%29._afpovertcp._tcp.local/Subfolder" /Volumes/MyDrive
fi
fi
mysqldump -u root -ppassword --all-databases | gzip -c > $(date "+/Volumes/MyDrive/Dumps/mysql/username/full__%FT%H_%M_%S.sql.gz")El trabajo cron crea un archivo en la unidad de red con un tamaño de archivo de 20 Bytes. Si lo descomprimo con gunzip, está vacío. Normalmente la base de datos tiene alrededor de 12 MB. Entonces, algo está mal aquí.
Este script se ejecuta a través del trabajo cron a la hora del almuerzo, por lo que nadie usa el MacBook en ese momento (la pantalla está bloqueada con un usuario conectado). El modo de espera está completamente desactivado (solo el modo de espera de la pantalla está activo después de 10 minutos).
¿Alguien sabe por qué esto no funciona? Cualquier ayuda o sugerencia sería genial.
2 votos
El shebang está faltando, además mysqldump puede que no esté en PATH. Si esto no ayuda, por favor captura cualquier salida creada por el trabajo de la cuna y añádela a la pregunta.
0 votos
@patrix lo siento, fue mi culpa. El problema del shebang fue solo un error de copia y pegado. Edité la pregunta. Y sí, mysqldump está en PATH, porque agregué la aplicación mysql a la variable PATH. Pero podría ser causado por la shell de sudo. Entonces, tal vez esté en la de los usuarios, pero no en la del root. Y no hay ningún error que mostrar. Porque el usuario root nunca ha recibido ningún correo. Normalmente recibirías un correo, si un trabajo cron sale con un código de error. Lo extraño es que hay un archivo, pero sin ningún contenido.
0 votos
Estoy de acuerdo con @patrix sobre que mysqldump no está en la PATH. Ampliando sobre eso, ten en cuenta que cuando se ejecuta cron, no tiene un entorno PATH para empezar, así que intenta expandir el camino completo para mysqldump.
0 votos
Además, al realizar pruebas, ¿está ejecutando bajo el mismo usuario que el cronjob? Para capturar toda la salida, considere redirigir stdout y stderr a un archivo en crontab
0 votos
No relacionado con tu problema, pero la existencia de directorios se puede probar fácilmente con
if [[ -d "LOCALMOUNTPOINT" ]]; thenen lugar de usar ls y grep :-)0 votos
Incluso puedes evitar la duplicación de código utilizando `[[ -d "PUNTOMONTAJELOCAL" ]] || mkdir "PUNTO MONTAJE LOCAL" para asegurarte de que el directorio existe y luego ejecutar el comando de montaje.
0 votos
@patrix tu declaración no funciona. ¿Necesita estar rodeada por una declaración "if"?
0 votos
No, pero solo funciona en bash :-) sh necesita [ y ] hasta donde sé. O simplemente usa bash en su lugar
0 votos
En lugar de
if ls -lha /Volumes...then....else..ifpodrías usarmkdir -p "$LOCALMOUNTPOINT"y luego montar la unidad. La opciónpenmkdircreará el directorio si es necesario o fallará silenciosamente si ya existe.