find -delete działa OK, ale nie z cronem

10

UWAGA : Przeczytałem wszystkie podobne pytania dotyczące. cron, ścieżki, zmienne env i tak dalej, ale nie znalazłem żadnej, która oferowałaby rozwiązania mojego konkretnego problemu.

Mam skrypt, który wykonuje zrzuty MySQL, a następnie usuwa stare:

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

( powyższe polecenie zostało zmodyfikowane z mojego oryginalnego polecenia dzięki sugestiom z komentarzy )

Jednak pliki nigdy nie są usuwane, gdy cron uruchamia ten skrypt. Użytkownik cron jest rootem.

Debugowanie notatek

Jeśli ręcznie uruchomię skrypt, w którym pojawia się polecenie, usuwa je zgodnie z oczekiwaniami.
Jeśli uruchomię powyższe polecenie find samodzielnie z wiersza poleceń jako root, usuwa je zgodnie z oczekiwaniami (i przy pomocy -print zwraca listę plików starszych niż 5 dni zgodnie z oczekiwaniami)
Dodałem także wyraźną instrukcję path do crontab root'a, ale
to nic nie zmienia.
Cron nie wysyła żadnego błędu, a jeśli potokuję operację znajdowania do pliku dziennika,
który pojawia się pusty lub wcale nie jest tworzony.
Używam serwera Ubuntu 14.04.03 LTS.

cron

— TommyPeanuts
źródło

Unikałbym rozwijania symboli wieloznacznych (np. * .Gz) na ścieżce. cron może interpretować jako * .gz, nie rozwijając wszystkich plików gz.

— Archemar,

Jakie wyniki uzyskasz, jeśli uruchomisz zadanie bez akcji/usr/bin/find /home/bkp/dbdump/*.gz -mtime +5

— user9517,

@Archemar Dlaczego symbol wieloznaczny nie zostałby rozwinięty? cronpolecenia są uruchamiane przez powłokę, a powłoka rozwija symbole wieloznaczne.

— Barmar

cronpowinien wysłać wiadomość e-mail z komunikatami wyjściowymi i błędami. Czy otrzymujesz taki e-mail z tej pracy?

— Barmar

@Iain działa zgodnie z oczekiwaniami.

— TommyPeanuts,

6

Problem polega na tym, crontabże nie został $PATHustawiony podczas działania. Możesz podać ścieżkę, dodając ją do górnej części pliku otwartego za pomocą crontab -e:

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

(lub cokolwiek PATH, czego wolisz użyć). Oznacza to, że możesz uniknąć podania pełnych ścieżek do poleceń bezpośrednio z crona.

Istnieje wiele problemów z oryginalnym poleceniem. Zasadniczo prosisz powłokę o rozwinięcie znaku zastępczego zamiast find. Po drugie, nie zapewniasz pełnej ścieżki rm; użyj /bin/rmlub /usr/bin/rm, gdziekolwiek się znajduje w twoim systemie (patrz which rm).

Pierwszym argumentem dla find jest „lokalizacja do wyszukiwania”, a następnie określ „zapytanie wyszukiwania” za pomocą różnych -<option>s. Właściwy format polecenia, które chcesz uruchomić, to:

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

lub

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

Jeśli nie określisz powyższej PATHdefinicji, użyj:

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

lub

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

— Będzie
źródło

1

Powinien był zostać $PATHustawiony, ale będzie to domyślny system. Będzie to obejmowało /usr/bini /bindlatego powinno być w stanie znaleźć rmpolecenie.

— Barmar

Próbowałem więc umieścić $ PATH na crontabie (chociaż jak wspomniano w innym miejscu, prawdopodobnie domyślnie wprowadziłby ścieżkę systemową, jeśli nie podano), i upewniłem się, że wszystko ma pełne ścieżki. Użyłem również -name „* .gz” zamiast znaku wieloznacznego na ścieżce wyszukiwania. Ale nic się nie dzieje. Wydaje się, że polecenie po prostu nie działa i nie zgłoszono żadnych błędów.

— TommyPeanuts,

3

Spróbuj tego zamiast tego

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

— shad0VV
źródło

Dlaczego przekierowałbyś stderr do pliku? Domyślnie zostanie wysłany pocztą e-mail, jeśli pojawił się jakiś wynik.

— kasperd

Tak, to prawda, że domyślnie wysyłany jest dowolny e-mail na adres Bufor użytkownika MAIL i można go odczytać za pomocą poczty.

— shad0VV,

1

Aby uzyskać taki sam efekt, jak oryginalne polecenie, należy je dodać -maxdepth 1.

— Niels Keurentjes

0

Jeśli wywołam polecenie find bezpośrednio z crontab roota, a nie jako część skryptu, to zadziała.

Skrypt, o którym mowa, używa csh. Wierzę, że środowisko crona root na Ubuntu będzie używać / bin / bash (lub / bin / dash?). Być może jest to w jakiś sposób sprzeczne z działaniem polecenia find.

Tak czy inaczej, główny problem został rozwiązany, choć nieco nieelegancko.

— TommyPeanuts
źródło