find -delete funziona bene, ma non con cron

10

NOTA : ho letto tutte le domande simili in merito. cron, percorsi, variabili env e così via, ma non ne ho trovato nessuna che offra soluzioni al mio problema specifico.

Ho uno script che crea alcuni dump MySQL e quindi elimina quelli vecchi in questo modo:

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

(il comando sopra è stato modificato dal mio comando originale da suggerimenti di commenti )

Tuttavia, i file non vengono mai eliminati quando cron esegue questo script. L'utente cron è root.

Note di debug

Se eseguo manualmente lo script in cui appare il comando, li elimina come previsto.
Se eseguo il comando find da solo dalla riga di comando come root, li elimina come previsto (e con -print restituisce un elenco di file più vecchi di 5 giorni come previsto)
Ho anche aggiunto un'istruzione esplicita del percorso al crontab di root, ma
ciò non cambia nulla.
Cron non invia alcun errore e, se installo l'operazione di ricerca a un file di registro,
risulta vuoto o non viene creato affatto.
Sto usando il server Ubuntu 14.04.03 LTS.

cron

— TommyPeanuts
fonte

Eviterei l'espansione jolly (ad es. * .Gz) nel percorso. cron potrebbe interpretare come * .gz, non espandendo tutti i file gz.

— Archemar,

Quale output ottieni se esegui il processo senza un'azione/usr/bin/find /home/bkp/dbdump/*.gz -mtime +5

— user9517

@Archemar Perché il carattere jolly non dovrebbe essere espanso? croni comandi vengono eseguiti attraverso la shell e la shell espande i caratteri jolly.

— Barmar il

crondovrebbe inviare e-mail con messaggi di output e di errore. Ricevete email di questo tipo da questo lavoro?

— Barmar il

@Iain funziona come previsto.

— TommyPeanuts,

6

Il problema è che crontabnon è stato $PATHimpostato durante l'esecuzione. Puoi effettivamente fornire un percorso aggiungendolo nella parte superiore del file aperto tramite crontab -e:

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

(o qualunque cosa PATHtu preferisca usare). Questo significa che puoi evitare di specificare i percorsi completi dei comandi, direttamente da cron.

Esistono diversi problemi con il comando originale. In pratica stai chiedendo alla shell di eseguire l'espansione jolly, piuttosto che find. In secondo luogo, non stai fornendo un percorso completo per rm; usa /bin/rmo /usr/bin/rm, ovunque si trovi sul tuo sistema (vedi which rm).

Il primo argomento per find è la "posizione da cercare", quindi si specifica la "query di ricerca" con le varie -<option>s. Quindi, il formato corretto del comando che si desidera eseguire è:

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

o

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

Se non si specifica la PATHdefinizione come sopra, utilizzare:

/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

— Volere
fonte

1

Avrebbe dovuto essere $PATHimpostato, ma sarà l'impostazione predefinita del sistema. Ciò includerà /usr/bine /bin, quindi, dovrebbe essere in grado di trovare il rmcomando.

— Barmar il

Quindi ho provato a inserire $ PATH nel crontab (anche se, come menzionato altrove, sarebbe probabilmente predefinito il percorso di sistema se non indicato), e mi sono assicurato che tutto avesse percorsi completi. Ho anche usato -name "* .gz" invece di un carattere jolly nel percorso di ricerca. Ma non succede nulla. Il comando non sembra funzionare e non vengono generati errori.

— TommyPeanuts,

3

Prova questo invece

find /home/bkp/dbdump -type f -name '*.gz' -mtime +5 -delete

— shad0VV
fonte

Perché reindirizzare stderr a un file? Per impostazione predefinita, verrà inviato via e-mail in caso di output.

— Kasperd,

Sì, è vero che per impostazione predefinita sta inviando e-mail allo spooler MAIL dell'utente e può essere letto tramite posta.

— shad0VV,

1

Per ottenere lo stesso effetto del comando originale, è necessario aggiungere -maxdepth 1.

— Niels Keurentjes il

0

Se invoco il comando find direttamente dal crontab di root e non come parte dello script, allora funziona.

Lo script in questione utilizza csh. Credo che l'ambiente cron di root su Ubuntu utilizzerà / bin / bash (o / bin / dash?). Forse questo è in qualche modo in conflitto con l'esecuzione del comando find.

In entrambi i casi, il problema principale è stato risolto, anche se in modo inelegante.

— TommyPeanuts
fonte