Crontab nigdy nie działa podczas pracy w /etc/cron.d

32

Oto, co zrobiłem na Debian Jessie:

zainstaluj crona przez apt-get install cron
włóż backup_crontabplik/etc/cron.d/

Jednak zadanie nigdy się nie uruchamia.

Oto kilka wyników:

/# crontab -l
no crontab for root

/# cd /etc/cron.d && ls
backup_crontab

/etc/cron.d# cat backup_crontab
0,15,30,45 * * * * /backup.sh >/dev/null 2>&1

Czy jest coś, co można zrobić, aby aktywować określony crontab lub aktywować samą „usługę” crona?

debian cron

— Jivan
źródło

4

Co jeśli działa i nie działa z błędem, którego nie widzisz, ponieważ przekierowujesz wszystkie dane wyjściowe do / dev / null? :)

— tink

@tink. Czy zamiast tego można dołączyć dane wyjściowe na końcu pliku?

— Jivan

2

na pewno jest; 0,15,30,45 * * * * /backup.sh >> / tmp / testing_cron.out 2> & 1

— tink 16.07.16

@Jivan, tylko mała uwaga: ls /etc/cron.djest równoważna cd /etc/cron.d && lspod względem wydajności. Jedyną różnicą jest to, że katalog roboczy się nie zmieni.

— Drew Chapin,

49

Pliki /etc/cron.dmuszą również zawierać listę użytkowników , dla których zadanie ma zostać uruchomione.

to znaczy

0,15,30,45 * * * * root /backup.sh >/dev/null 2>&1

Należy również upewnić się, że uprawnienia i właściciel: grupa są ustawione poprawnie ( -rw-r--r--i są własnością root:root)

— Stephen Harris
źródło

16

crontab -lraporty o wpisach cron w /var/spool/cron/crontabs/- tj . crontabs na użytkownika . /etc/cron.dpliki to crontabs systemowe i nie są zgłaszane przez crontab -l.

— Stephen Harris

5

Właściwie wspomniałem, że to nie działa, ale właśnie zdałem sobie sprawę, że to po dodaniu rootdo pliku - po prostu crontab -lnie wspomniałem o tym, ponieważ wyjaśniłeś, dlaczego - dziękuję za pomoc

— Jivan

9

wydaje się, że także nazwa pliku ma znaczenie. W moim przypadku dodałem do etc/cron.dpliku kropkę pośrodku nazwy i zadanie nigdy nie zostało wykonane, dopóki nie zmieniłem jego nazwy

— pic

20

ten sam problem tutaj, myślniki „-” w nazwie pliku, zmiana ich na podkreślenia „_” rozwiązało problem, zadania uruchomiono natychmiast.

— Rob

1

Miałem też kreskę ... co ... dlaczego ?! W każdym razie dzięki @Rob

— Nikolay Dimitrov

8

Inną rzeczą, którą zaobserwowałem, jest to, że plik w /etc/cron.dnie może mieć rozszerzenia. W moim konkretnym przypadku miałem dowiązanie symboliczne:

# my-job.crontab
* * * * * root echo "my job is running!" >> /tmp/my-job.log

$: ln -sf /home/me/my-job.crontab /etc/cron.d/
# This did not work -> job would not run

$: ln -sf /home/me/my-job.crontab /etc/cron.d/my-job
# This did work -> job ran fine

Ograniczenia nazw plików są udokumentowane na stronie podręcznika użytkownika : http://manpages.ubuntu.com/manpages/xenial/man8/run-parts.8.html , można przekazać opcję --regex, aby zastąpić format pliku.

Domyślne zachowanie crona pozostało jednak bez rozszerzeń, patrz komentarze pod: https://bugs.launchpad.net/ubuntu/+source/debianutils/+bug/38022

— rodrigo-silveira
źródło

Człowieku, uratowałeś mi dzień!

— elboletaire

2

Jest to poprawne w Ubuntu (może we wszystkich dystrybucjach wywodzących się z Debiana). W Amazon Linux (i być może we wszystkich dystrybucjach pochodzących od Redhat) możesz mieć kropkę w nazwie pliku. Dziękuję Unix.SE.

— Law29

Właśnie sprawdziłem czysty Debian i kropki też tam nie działają. Kreski działają (w przeciwieństwie do tego, co mówi powyższy komentarz).

— Law29

4

Myślę, że prawdopodobnie brakuje ci niezbędnej pustej linii na końcu pliku cron. Miałem ten sam problem, ale po sprawdzeniu wszystkiego, co tu wymienione (uprawnienia użytkownika, nazwa pliku, wersja crona itp.), Zdałem sobie sprawę, że nie miałem podziału wiersza po ostatnim wpisie w moim /etc/cron.d/own_cronpliku, co powoduje, że cały plik jest ignorowany.

— slac1024
źródło

2

Jeśli jesteś jedynym użytkownikiem na tym komputerze, możesz użyć tylko crontab -e. Przy pierwszym uruchomieniu polecenia pojawi się monit o wybranie edytora. Następnie możesz dodać do tego:

0,15,30,45 * * * * /backup.sh >/dev/null 2>&1

Jeśli zmienisz na zwykłe konto użytkownika, musisz użyć sudo crontab -edo skonfigurowania skryptów, które mają być uruchamiane jako root.

crontab -lwyświetla tylko bieżący plik crontab, po skonfigurowaniu za pomocą crontab -e. Jeśli masz plik cron w /etc/cron.d/, nie będzie on wyświetlany przy pomocy crontab -l.

Będzie trzeba także sprawdzić, czy skrypt jest wykonywalny z: chmod +x /backup.sh.

— clk
źródło

1

dzięki - w tym przypadku crontab jest ustawiony w kontekście, Dockerfilewięc nie mogę tego zrobić crontab -e- ale i tak jest to przydatna informacja

— Jivan

2

Dla Crona z dystrybucji * bian (jak Raspbian) musisz włączyć -lparametr demona Cron. Jest to zalecane przy użyciu /etc/default/cronpliku konfiguracyjnego, włączając EXTRA_OPTS.

— próchno
źródło

Zostało to zanegowane, ale w niektórych przypadkach jest poprawne, choć nie wyjaśnione. W dystrybucjach opartych na Debianie -lopcja dla demona cron autoryzuje rozszerzony zestaw nazw plików w /etc/cron.dkatalogu, więc jeśli plik jest dyskretnie ignorowany, ponieważ zawiera kropkę, wówczas albo „dodaj -l”, albo „usuń kropkę” rozwiąże problem.

— Law29

1

Sprawdź swoją wersję cron.

Wygląda na to, że jeśli używasz cronda Dillona, nie potrzebujesz użytkownika we /etc/cron.dwpisie.

Zrozumiałem to po prawie wyciągnięciu moich pozostałych włosów.

Mam garść wpisów, które zostały dodane /etc/cron.dprzez różne instalacje. Po pewnym dochodzeniu odkryłem, że jedno z nich działa. Nie miał użytkownika. Więc usunąłem użytkownika z innych. I zaczęli pracować.

— James Nelson
źródło