find -delete funciona bien, pero no con cron

10

TENGA EN CUENTA : He leído todas las preguntas similares re. cron, rutas, variables env, etc., pero no he encontrado ninguna que ofrezca soluciones a mi problema particular.

Tengo un script que hace algunos volcados de MySQL y luego elimina los antiguos como este:

/usr/bin/find "/home/bkp/dbdump" -name "*.gz" -mtime +5 -delete

(el comando anterior ha sido modificado de mi comando original por sugerencias de comentarios )

Sin embargo, los archivos nunca se eliminan cuando cron ejecuta este script. El usuario cron es root.

Notas de depuración

  • Si ejecuto manualmente el script en el que aparece el comando, los elimina como se esperaba.

  • Si ejecuto el comando find anterior solo desde la línea de comando como root, los elimina como se esperaba (y con -print devuelve una lista de archivos anteriores a 5 días como se esperaba)

  • También he agregado una declaración de ruta explícita al crontab de root, pero
    eso no cambia nada.

  • Cron no envía ningún error, y si canalizo la operación de búsqueda a un archivo de registro,
    aparece vacío o no se crea en absoluto.

  • Estoy usando el servidor Ubuntu 14.04.03 LTS.

cron TommyPeanuts
fuente
Evitaría la expansión de comodines (por ejemplo, * .gz) en la ruta. cron podría interpretarse como * .gz, no expandiendo todos los archivos gz.
Archemar
¿Qué resultado obtiene si ejecuta el trabajo sin una acción/usr/bin/find /home/bkp/dbdump/*.gz -mtime +5
User9517
@Archemar ¿Por qué no se expandiría el comodín? cronlos comandos se ejecutan a través del shell, y el shell expande comodines.
Barmar
crondebe enviar correos electrónicos con mensajes de salida y error. ¿Recibes algún correo electrónico de este trabajo?
Barmar
@Iain funciona como se esperaba.
TommyPeanuts

Respuestas:

6

El problema es que crontabno se ha $PATHconfigurado cuando se ejecuta. En realidad, puede proporcionarle una ruta agregando esto a la parte superior del archivo abierto a través de crontab -e:

PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

(o lo PATHque prefieras usar). Esto significa que puede evitar especificar las rutas completas a los comandos, directamente desde cron.

Hay múltiples problemas con su comando original. Básicamente le está pidiendo la cáscara para hacer la expansión de comodines, en lugar de find. En segundo lugar, no está proporcionando un camino completo para rm; use /bin/rmo /usr/bin/rm, donde sea que esté ubicado en su sistema (vea which rm).

El primer argumento para encontrar es la "ubicación para buscar", y luego especifica la "consulta de búsqueda" con los diversos -<option>s. Entonces, el formato adecuado del comando que desea ejecutar es:

find "/home/bkp/dbdump" -name "*.gz" -mtime +5 -exec rm -f {} \;

o

find "/home/bkp/dbdump" -name "*.gz" -mtime +5 delete

Si no especifica la PATHdefinición anterior, use:

/usr/bin/find "/home/bkp/dbdump" -name "*.gz" -mtime +5 -exec /bin/rm -f {} \;

o

/usr/bin/find "/home/bkp/dbdump" -name "*.gz" -mtime +5 delete
Será
fuente
1
Debería haberse $PATHconfigurado, pero será el valor predeterminado del sistema. Esto incluirá /usr/biny /bin, por lo tanto, debería poder encontrar el rmcomando.
Barmar
Así que intenté poner $ PATH en el crontab (aunque, como se mencionó en otra parte, probablemente sería la ruta predeterminada del sistema si no se indica), y me aseguré de que todo tuviera rutas completas. También usé -name "* .gz" en lugar de un comodín en la ruta de búsqueda. Pero nada pasa. El comando simplemente no parece ejecutarse y no se producen errores.
TommyPeanuts
3

Intenta esto en su lugar

find /home/bkp/dbdump -type f -name '*.gz' -mtime +5 -delete
shad0VV
fuente
¿Por qué redirigir stderr a un archivo? Por defecto, se enviará por correo electrónico si hubo algún resultado.
kasperd
Sí, es cierto que, de forma predeterminada, se envía un correo electrónico a la cola CORREO del usuario y se puede leer mediante correo.
shad0VV
1
Para obtener el mismo efecto que el comando original, deberá agregarlo -maxdepth 1.
Niels Keurentjes
0

Si invoco el comando find directamente desde el crontab de root y no como parte del script, entonces funciona.

El script en cuestión usa csh. Creo que el entorno cron de root en Ubuntu usará / bin / bash (o / bin / dash?). Quizás esto entra en conflicto de alguna manera con cómo se estaba ejecutando el comando find

De cualquier manera, el problema principal que resolvió, aunque de manera poco elegante.

TommyPeanuts
fuente