Konfiguracja demona cron w Gentoo

1.  Cron - podstawy

Co robi cron?

Cron jest demonem, który uruchamia zaplanowane zadania w oparciu o dane przekazane przez polecenie crontab. Program wykonuje swoją pracę sprawdzając co minutę czy w plikach crontab użytkowników znajdują się jakieś zadania do zrealizowania.

Cron w praktyce

W Portage znajdują się co najmniej kilka implementacji crona, spośród których można wybierać. Wszystkie posiadają podobny interfejs. Mianowicie, używają komendy crontab lub podobnej. Istnieje także pokrewne narzędzie zwane Anacron, którego przeznaczeniem jest współpraca z cronem na systemach, które nie działają w sposób ciągły.

Zależnością każdego z tych trzech cronów jest pakiet sys-process/cronbase. Może on wystarczyć do podstawowych zastosowań crona.

Zanim zaczniemy pracę z cronem, musimy wybrać jedną z wersji tego programu. Dla wygody przedstawiamy poniżej informacje o dostępnych implementacjach.

2.  Który cron spełni nasze potrzeby?

Vixie cron

Vixie cron jest wersją posiadającą wiele możliwości i opartą na cronie z SysV. Każdy użytkownik posiada własny plik crontab oraz ma możliwość używania zmiennych środowiskowych w obrębie tego pliku. W przeciwieństwie do innych odmian crona, oferuje wsparcie dla SELinux i PAM. Wspiera mniej architektur niż DCron, ale więcej niż Fcron.

Cechy programu sys-process/vixie-cron:

• Wsparcie dla SELinux
• Wsparcie dla PAM /etc/security/limits.conf
• Ustawianie zmiennych środowiskowych w plikach crontab (PATH, SHELL, HOME, itp.)
• Każdy użytkownik może posiadać własny crontab, do którego dostęp kontrolowany jest za pomocą cron.allow i cron.deny

Cron Dillona

Dcron w zamierzeniach ma być prostą, elegancką i bezpieczną implementacją crona. Nie pozwala na wykorzystanie zmiennych środowiskowych w plikach crontab, zaś wszystkie zadania są uruchamiane z /bin/sh. Podobnie jak w Vixie cron, każdy użytkownik posiada własny plik crontab.

Cechy programu sys-process/dcron:

• Szybki, prosty i wolny od zbędnych dodatków
• Dostęp do crontab jest ograniczony do grupy cron, tzn. nie polega na zewnętrznych zasobach

Fcron

Fcron w zamierzeniach ma zastąpić programy Vixie cron i Anacron. Został zaprojektowany do pracy na systemach, które nie działają w sposób ciągły. Ponadto zawiera dodatkowe możliwości takie jak: uruchamianie zadań w zależności od tego czy spełnione są określone warunki, zdolność przypisywania priorytetów zadaniom, możliwość przypisania zadania do uruchomienia przy starcie systemu. Więcej informacji można znaleźć na stronie domowej Fcrona.

Cechy programu sys-process/fcron:

• Zaprojektowany do pracy na systemach, które nie działają w sposób ciągły, np. może rozpocząć zadanie po ponownym uruchomienia systemu
• Ustawianie zmiennych środowiskowych i wielu innych opcji dla plików crontab
• Każdy użytkownik może posiadać własny crontab, do którego dostęp kontrolowany jest za pomocą cron.allow i cron.deny
• Rozszerzona składnia polecenia crontab, zawierająca obsługę wielu nowych możliwości

bcron

bcron jest nowym systemem zaprojektowanym z myślą o bezpiecznych operacjach. Aby działać w ten sposób, system dzielony jest na kilka oddzielnych programów, a każdy z nich odpowiedzialny jest za inne zadanie, które ściśle kontolują komunikację między nimi. Interfejs użytkownika drop-in jest bardzo podobny do innych tego typu systemów (takich jak vixie-cron) jednak duże róznice znajdują się w wewnętrznych mechanizmach. Aby uzyskać więcej informacji prosimy zapoznać się ze stroną http://untroubled.org/bcron/.

Właściwości sys-process/bcron:

• Zastępuje system drop-in z vixie-cron
• Architektura wielowątkowa
• Natywne wsparcie dla czasu letniego

Anacron

Anacron nie jest demonem crona. Zazwyczaj pracuje w połączeniu z cronem. Wykonuje polecenia w odstępach czasu podawanych w dniach oraz nie czyni założeń o ciągłym działaniu systemu. Uruchamia zadania, które nie zostały wywołane podczas wyłączeń systemu. Anacron przeważnie jest uruchamiany przez demona cron raz dziennie.

3.  Korzystanie z crona

Instalacja

Wybieramy tę wersję crona, która nam najbardziej odpowiada i instalujemy ją.

# emerge dcron
# /etc/init.d/dcron start
# rc-update add dcron default

Jeśli nie zainstalowaliśmy Fcrona, to opcjonalnie możemy zainstalować Anacrona.

# emerge anacron
# /etc/init.d/anacron start
# rc-update add anacron default

Plik crontab dla systemu

Poinstalacyjne komunikaty z niektórych wersji crona informują o konieczności uruchomienia polecenia crontab /etc/crontab. Plik /etc/crontab jest plikiem crontab dla systemu. Demon cron dzięki sys-process/cronbase może uruchamiać skrypty z plików /etc/cron.{daily,hourly,weekly,monthly}. Należy wspomnieć, że tylko vixie-cron automatycznie planuje zadania w /etc/crontab. Użytkownicy programów Dcron i Fcron muszą uruchomić crontab /etc/crontab, każdorazowo po wprowadzeniu zmian w /etc/crontab.

Warto zauważyć, że zadania zaplanowane w systemowym pliku crontab, nie zostaną wyświetlone na liście zaplanowanych zadań, tj. po wydaniu komendy crontab -l.

Oczywiście nie musimy używać żadnego z programów cron. Jeśli zdecydujemy się na Dcrona lub Fcrona, to NIE uruchamiamy crontab /etc/crontab. Jeśli wybierzemy vixie-crona lub bcron, to powinniśmy zakomentować wszystkie linie w pliku /etc/crontab.

# sed -i -e "s/^/#/" /etc/crontab

Nadawanie zaufanym użytkownikom dostępu do crona

Jeśli chcemy, by użytkownicy inni niż root mieli dostęp do demona cron, to sugerujemy przeczytanie tego akapitu. W przeciwnym przypadku można przejść do następnej sekcji, tj. planowania zadań.

Jeśli chcemy nadać użytkownikowi prawo do korzystania z plików crontab, to niezależnie, który pakiet wybierzemy, musimy go najpierw dodać do grupy cron. Dla przykładu, jeśli chcemy dodać użytkownika yarel do grupy cron, to wpisujemy:

# gpasswd -a yarel cron

Jeśli używamy Dcrona, to jest to wszystko co musimy zrobić, by nadać użytkownikowi prawo do korzystania z crontab. Użytkownicy Dcrona mogą przejść do następnej sekcji, tj. planowanie zadań. Pozostali czytają dalej.

Jeśli korzystamy z Fcrona, to musimy zmienić pliki /etc/fcron/fcron.deny oraz /etc/fcron/fcron.allow. Najbezpieczniejszy sposób to odmówienie dostępu wszystkimi (all), w pliku /etc/fcron/fcron.deny, a następnie wymienienie w pliku /etc/fcron/fcron.allow użytkowników, którzy mają mieć dostęp.

all

Przypuśćmy, że mamy użytkownika yarel, który powinien mieć możliwość planowania własnych zadań. Dodajemy go do pliku /etc/fcron/fcron.allow w następujący sposób:

yarel

Wybierając Vixie crona, będziemy chcieli wyedytować plik /etc/cron.allow.

Przykładowo, jeśli chcemy nadać użytkownikowi yarel prawo dostępu do crona, to umieszczamy go w pliku /etc/cron.allow następująco:

yarel

Planowanie zadań

W każdym pakiecie proces edycji plików crontab wygląda inaczej, ale wszystkie wersje obsługują podstawowy zestaw poleceń: dodawanie i zastępowanie pliku crontab, edycja i usuwanie oraz wyświetlanie listy zadań z plików crontab. Następujące zestawienie pokazuje jak używać komend w poszczególnych pakietach.

Zanim zaczniemy używać tych komend, musimy zrozumieć strukturę pliku crontab. Każda linia takiego pliku wymaga podania pięciu pól określających czas. W kolejności są to: minuty (0-59), godziny (0-23), dni miesiąca (1-31), miesiące (1-12) oraz dni tygodnia (0-7, 1 to poniedziałek, 0 i 7 to niedziela). Dni tygodni i miesiące mogą być określane za pomocą trzyliterowych angielskich skrótów, takich jak: mon, tue, jan, feb, itp. Każde pole może także zawierać zakres wartości (np. 1-5 dla poniedziałek-piątek), listę wartości rozdzieloną przecinkiem (np. 1,2,3 albo mon,tue,wed) lub zakres wartości z określonym krokiem (np. 1-6/2 dla 1,3,5).

Może to wyglądać na zagmatwane, ale kilka przykładów powinno rozwiać wątpliwości.

# Uruchamia /bin/false co minutę przez cały rok

*     *     *     *     *        /bin/false


# Uruchamia /bin/false o 1:35 w pon, wt, śr i 4-tego każdego miesiąca

35    1     4     *     mon-wed  /bin/false

# Uruchamia /bin/true o 22:25 2. marca
25    22    2     3     *        /bin/true


# Uruchamia/bin/false o 2:00 w każdy poniedziałek, środę i piątek

0     2     *     *     1-5/2    /bin/false

Przećwiczymy to, czego się właśnie nauczyliśmy. Wykonamy kolejne kroki tworzenia nowych zaplanowanych zadań. Na początku tworzymy plik o nazwie crons.cron i wypełniamy go tak, by wyglądał następująco:

$ nano crons.cron
# Minuty  Godziny  Dni   Miesiące  Dni tygodnia
10     3      1      1       *       /bin/echo "Nie lubię crona."
30     16     *      1,2     *       /bin/echo "Trochę lubię crona."
*      *      *      1-12/2  *       /bin/echo "Naprawdę lubię crona."

Teraz możemy dodać plik crontab do systemu używając komendy "nowy wpis" z tabeli powyżej.

# crontab crons.cron

Weryfikację zaplanowanych zadań możemy przeprowadzić z użyciem odpowiedniej komendy listowania z tabeli powyżej.

# crontab -l

Powinna pojawić się lista przypominająca zawartość pliku crons.cron. Jeśli tak nie jest, to możliwe że zostało użyte niewłaściwe polecenie, by dodać nowy plik crontab.

Zgodnie z powyższym plikiem crontab, co minutę każdej godziny, każdego dnia w co drugim miesiącu, wykonane będzie polecenie echo "Naprawdę lubię crona.". Oczywiście robimy to, jeśli naprawdę lubimy crona. Każdego dnia stycznia oraz lutego o godzinie 16:30 zostanie wykonana komenda echo "Trochę lubię crona.". Pierwszego stycznia o 3:10 zostanie wykonana komenda echo "Nie lubię crona.".

Użytkownicy Anacrona powinni czytać dalej, natomiast pozostali mogą przejść do następnego akapitu, tj. edycji plików crontab.

Użytkownicy Anacrona będą modyfikować zawartość pliku /etc/anacrontab. W pliku tym znajdują się cztery pola: liczba dni między kolejnymi uruchomieniami, opóźnienie w minutach, po którym zadanie jest uruchamiane, nazwa zadania oraz komenda, która będzie uruchamiana.

Przykładowo, by wywoływać co 5 dni, 10 minut po uruchomieniu Anacrona polecenie echo "Lubię anacrona." wpisujemy:

5 10 wasting-time /bin/echo "Lubię anacrona."

Program Anacron kończy działanie po tym, gdy wszystkie zadania wymienione w pliku anacrontab, zostaną wykonane. Jeśli chcemy sprawdzać te zadania codziennie, to musimy użyć crona. Instrukcja pod koniec następnego akapitu, wyjaśnia jak to osiągnąć.

Edycja plików crontab

Bądźmy poważni, nie chcemy, by system co minutę mówił nam jak bardzo lubimy crona. Kolejny krok w poznawaniu tego programu, to usunięcie pliku crontab przy użyciu odpowiedniej komendy do usuwania z wymienionej powyżej tabeli. Po usunięciu pliku wylistujemy zaplanowane zadania, by upewnić się, że komenda do usuwania zadziałała.

# crontab -d
# crontab -l

Po wydaniu polecenia crontab -l nie powinna wyświetlać się lista zaplanowanych zadań. Jeśli pojawiają się wpisy, oznacza to, że polecenie do usuwania zadań nie zadziałało. Należy upewnić się, że została użyta komenda usuwania, właściwa dla naszej wersji crona.

Teraz, gdy mamy wyklarowaną sytuację, umieśćmy coś użytecznego w pliku crontab użytkownika root. Większość ludzi zechce uruchamiać updatedb w odstępach tygodniowych, by zapewnić prawidłowe działanie slocate. Ponownie modyfikujemy plik crons.cron, by wyglądał następująco:

22 2 * * 1    /usr/bin/updatedb

Powyższe sprawi, że cron będzie uruchamiał updatedb każdego tygodnia, w poniedziałek o 2:22 nad ranem. Powinniśmy teraz dodać plik crontab wykorzystując komendę nowy wpis, zawartą w tabeli powyżej, a następnie ponownie sprawdzić listę zadań.

# crontab crons.cron
# crontab -l

Przypuśćmy, że chcemy także dodać emerge --sync do listy zadań wykonywanych codziennie. Możemy to wykonać przez modyfikację pliku crons.cron, a następnie przez użycie odpowiedniej komendy do edycji. Poniższe daje nam możliwość modyfikacji pliku crontab użytkownika w miejscu, bez polegania na zewnętrznych plikach, takich jak crons.cron.

# crontab -e

Polecenie powinno otworzyć plik crontab użytkownika w edytorze. Chcemy, by emerge --sync uruchamiało się codziennie o 6:30 rano, więc zmieniamy zawartość pliku, by wyglądało to mniej więcej tak:

22 2 * * 1    /usr/bin/updatedb
30 6 * * *    /usr/bin/emerge --sync
(jeśli korzystamy z anacrona, dodajemy następującą linię)
30 7 * * *    /usr/sbin/anacron -s

Ponownie sprawdzamy listę zadań zaplanowanych do wykonania, tak jak to czyniliśmy w poprzednim przykładzie. Upewniamy się że zadanie zostało zaplanowane. Jeśli tak jest, to mamy wszystko gotowe.

4.  Korzystaie z cronbase

Tak jak wspominaliśmy wcześniej, wszystkie pakiety crona są zależne od sys-process/cronbase. Pakiet cronbase tworzy pliki /etc/cron.{hourly,daily,weekly,monthly} i skrypt o nazwie run-crons. W domyślnym pliku /etc/crontab znajdują się takie wpisy:

*/15 * * * *     test -x /usr/sbin/run-crons && /usr/sbin/run-crons
0  *  * * *      rm -f /var/spool/cron/lastrun/cron.hourly
0  3  * * *      rm -f /var/spool/cron/lastrun/cron.daily
15 4  * * 6      rm -f /var/spool/cron/lastrun/cron.weekly
30 5  1 * *      rm -f /var/spool/cron/lastrun/cron.monthly

Nie będziemy wdawać się w zbytnie szczegóły, opowiemy pokrótce jak uruchamiać poszczególne skrypty co godzinę, co jeden dzień, co tydzień i co miesiąc. Takie ustawienie ma kilka zalet:

• Zostaną uruchomione nawet jeśli komputer był wyłączony w czasie, na który zaplanowano ich wykonanie
• Ułatwia to umieszczanie skryptów przez osoby opiekujące się poszczególnymi pakietami
• Od razu wiadomo gdzie znajdują się wszystkie zadania, ułatwia to tworzenie kopii zapasowych i odtwarzanie części systemu.

5.  Uwagi końcowe

W razie problemów

Jeśli występują problemy z prawidłową pracą crona, to można sprawdzić kolejne punkty z poniższej listy.

• Czy cron jest uruchomiony? Upewniamy się wpisując ps ax | grep cron i oczekując, że cron pojawi się na liście!
• Czy cron pracuje prawidłowo? Próbujemy: * * * * * /bin/echo "foobar" >> /nasz_plik, a następnie upewniamy się że cron działa
• Czy zadanie uruchamia się poprawnie? Próbujemy: * * * * * /bin/foobar > /nasz_plik 2>&1, szukamy błędów w pliku /nasz_plik
• Czy cron uruchamia zaplanowane zadania? Sprawdzamy logi crona w poszukiwaniu błędów, przeważnie jest to plik /var/log/cron.log lub /var/log/messages
• Czy jest jakiś plik dead.letter? Zazwyczaj, gdy wystąpi problem, cron wysyła maila. Sprawdzamy pocztę, a także plik ~/dead.letter

Musimy pamiętać, że każdy pakiet crona jest inny, a zakres funkcjonalny może się znacznie różnić między poszczególnymi wersjami. W zależności od tego, z której wersji korzystamy, warto zapoznać się ze stronami podręcznika dla crontaba, fcrontaba lub anacrontaba.

Powodzenia!

Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike.