Crontab + Sendmail

Crontab połączony z Sendmail to konfiguracja systemowa umożliwiająca wysyłkę powiadomień pocztowych o wynikach zaplanowanych zadań.

Crontab + Sendmail — czym jest to połączenie

Crontab + Sendmail oznacza zestawienie dwóch klasycznych mechanizmów systemu Unix i Linux: harmonogramu zadań oraz lokalnego agenta obsługującego przekazywanie wiadomości pocztowych. Crontab odpowiada za uruchamianie poleceń o określonych porach, natomiast Sendmail może przyjąć komunikat wygenerowany przez skrypt, nadać mu nagłówki i przekazać go do dalszej obsługi pocztowej. Dzięki temu wykonanie zadania może zostać zasygnalizowane wiadomością bez konieczności ręcznego sprawdzania każdego wpisu w dzienniku systemowym.

Takie rozwiązanie stosuje się między innymi przy kopiach zapasowych, czyszczeniu plików tymczasowych, kontroli zajętości dysku, odświeżaniu danych, sprawdzaniu dostępności usług oraz wykonywaniu cyklicznych skryptów administracyjnych. Sam harmonogram nie analizuje znaczenia wyniku polecenia. Uruchamia komendę i może przekazać jej standardowe wyjście oraz komunikaty błędów do lokalnego mechanizmu pocztowego. Dopiero poprawnie skonfigurowany Sendmail lub inny program pocztowy decyduje, czy wiadomość zostanie dostarczona lokalnie, przekazana do zewnętrznego hosta, czy zapisana w kolejce do późniejszej wysyłki.

Warto rozdzielić trzy elementy konfiguracji: moment uruchomienia, polecenie wykonywane przez crontab oraz sposób obsługi wiadomości. Błąd w pierwszej części może spowodować wykonanie zadania o niewłaściwej porze. Błąd w drugiej może oznaczać brak raportu albo raport opisujący niepełny wynik. Błąd w trzeciej często prowadzi do pozornie poprawnego działania zadania, przy jednoczesnym braku dostarczenia powiadomienia.

Crontab + Sendmail w kontekście technicznym i na tle innych metod

Wpis crontab składa się z pól opisujących minutę, godzinę, dzień miesiąca, miesiąc oraz dzień tygodnia, po których znajduje się polecenie. Można zaplanować wykonanie zadania o konkretnej godzinie, w wybrane dni albo w regularnych odstępach. Szczególną uwagę należy zwrócić na środowisko uruchomieniowe. Proces wywołany przez crona zwykle ma ograniczony zestaw zmiennych środowiskowych, inną wartość zmiennej PATH i inny katalog roboczy niż sesja uruchamiana ręcznie w powłoce. Polecenie działające po zalogowaniu może więc nie zadziałać identycznie po umieszczeniu w crontabie.

Sendmail może działać jako lokalny interfejs do przekazywania wiadomości, ale jego obecność nie gwarantuje dostarczenia poczty do każdej skrzynki. Znaczenie mają między innymi nazwa hosta, domena nadawcy, rozwiązywanie nazw DNS, rekordy pocztowe, reguły przekazywania, autoryzacja oraz polityka serwera odbiorcy. W niektórych środowiskach Sendmail jest wykorzystywany bezpośrednio, a w innych pełni funkcję zgodnego interfejsu dla innego agenta pocztowego. Z punktu widzenia zadania uruchamianego przez crona najważniejsze jest to, czy lokalne przekazanie wiadomości kończy się powodzeniem i czy ewentualne błędy są rejestrowane.

Alternatywą dla powiadomień pocztowych może być zapis do pliku dziennika, wysłanie komunikatu do systemu monitoringu albo przekazanie wyniku do usługi obsługującej alerty. Poczta ma jednak praktyczną zaletę: może zawierać pełny komunikat programu, kod zakończenia i fragment logu. Z drugiej strony trudniej zagwarantować, że wiadomość nie trafi do spamu, nie zostanie opóźniona przez kolejkę lub nie będzie odrzucona z powodu nieprawidłowych nagłówków. Dlatego pocztę warto traktować jako jeden z elementów kontroli, a nie jako jedyne źródło informacji o stanie zadania.

Crontab i Sendmail — typowe problemy oraz ich rozpoznawanie

Jednym z częstych problemów jest brak wiadomości mimo wykonania zadania. Przyczyną może być brak ustawionego adresata, wyciszenie standardowego wyjścia, nieprawidłowy format polecenia albo błędna konfiguracja lokalnego agenta pocztowego. Pomocne jest rozdzielenie testu na dwa etapy. Najpierw należy uruchomić samo polecenie z podobnym środowiskiem, jakie otrzymuje cron. Następnie warto sprawdzić ręczne przekazanie krótkiej wiadomości przez lokalny mechanizm pocztowy. Pozwala to ustalić, czy problem leży w harmonogramie, skrypcie, czy w obsłudze poczty.

Innym przypadkiem jest wysyłanie zbyt wielu raportów. Zadanie może zwracać tekst przy każdym uruchomieniu, nawet gdy wszystko działa prawidłowo. Jeżeli cron przekazuje standardowe wyjście do poczty, codzienna wiadomość może szybko stać się mało użyteczna. Lepszą praktyką jest generowanie raportu tylko wtedy, gdy wystąpi błąd, albo umieszczanie w wiadomości krótkiego podsumowania wraz z odwołaniem do pełnego logu. Nie należy jednak wyciszać wszystkich komunikatów bez sprawdzenia, czy nie zawierają informacji o częściowym wykonaniu zadania.

Problemy mogą wynikać również z uprawnień. Skrypt uruchamiany przez konkretnego użytkownika może nie mieć dostępu do pliku, katalogu, urządzenia lub programu pomocniczego. Znaczenie ma także kod wyjścia. Zakończenie procesu z kodem zero zwykle oznacza wykonanie bez błędu, ale nie potwierdza poprawności każdego etapu. Skrypt może zakończyć się formalnie poprawnie, mimo że pominięto pojedynczy plik lub nie udało się wykonać jednego z kroków. Warto zatem projektować raport tak, aby wskazywał liczbę przetworzonych elementów, pominięcia i błędy.

Do diagnozy przydają się logi crona, logi agenta pocztowego, kolejka wiadomości oraz dokładny zapis polecenia. Należy sprawdzić również kodowanie znaków i nagłówki, szczególnie gdy raport zawiera polskie znaki. Nieprawidłowy adres nadawcy może powodować odrzucenie wiadomości dopiero po przekazaniu jej poza lokalny system, dlatego test dostarczenia powinien obejmować rzeczywistą skrzynkę odbiorczą i folder spamu.

Crontab + Sendmail — praktyczne wskazówki konfiguracji

Najbezpieczniej jest używać pełnych ścieżek do programów i plików, jednoznacznie wskazywać katalog roboczy oraz zapisywać wynik do kontrolowanego pliku logu. Skrypt uruchamiany przez crona powinien mieć przewidywalne zachowanie przy braku sieci, niedostępnym dysku lub częściowym błędzie. Przydatne jest ograniczenie czasu wykonywania, aby zadanie nie uruchomiło kolejnej instancji przed zakończeniem poprzedniej. W przypadku dłuższych operacji można zastosować mechanizm blokady albo sprawdzenie, czy poprzedni proces nadal działa.

Adres odbiorcy powinien być zapisany w sposób łatwy do odnalezienia i zmiany, ale bez umieszczania danych uwierzytelniających bezpośrednio w skrypcie. Warto ustalić stały temat wiadomości, zawierający nazwę zadania i jego stan, na przykład powodzenie, ostrzeżenie albo błąd. Treść powinna podawać czas rozpoczęcia, czas zakończenia, kod wyjścia oraz najważniejsze komunikaty. Przy większej liczbie zadań taki schemat ułatwia filtrowanie poczty i szybkie rozpoznanie źródła problemu.

Po każdej zmianie należy wykonać test ręczny, a następnie poczekać na rzeczywiste uruchomienie według harmonogramu. Samo ręczne uruchomienie nie sprawdza różnic w uprawnieniach i środowisku. Trzeba też obserwować kolejkę pocztową, ponieważ lokalne przyjęcie wiadomości nie jest równoznaczne z dostarczeniem jej do adresata. Jeżeli zadanie jest ważne, wskazane jest dodatkowe monitorowanie świeżości logu lub potwierdzanie wykonania niezależnym mechanizmem.

W razie kłopotów z konfiguracją można skorzystać z pomocy serwisu komputerowego w Warszawie. Warszawskie Pogotowie Komputerowe 24/7 przyjmuje zgłoszenia dotyczące diagnostyki systemu, harmonogramów zadań, logów i konfiguracji powiadomień, a naprawy z reguły realizowane są do 3 dni roboczych.

Kiedy zgłosić Crontab + Sendmail do serwisu

Do serwisu warto zgłosić problem wtedy, gdy zadanie uruchamia się nieregularnie, raporty przestały docierać, pojawiają się powtarzające komunikaty o błędach albo poczta jest wysyłana do niewłaściwych odbiorców. Pomoc może być potrzebna także po zmianie systemu, przeniesieniu danych na inny dysk, aktualizacji programów pocztowych lub zmianie ustawień sieciowych. W takich sytuacjach pozornie drobna różnica w ścieżce, uprawnieniach lub nazwie hosta może przerwać cały łańcuch działania.

Przed przekazaniem urządzenia dobrze przygotować opis oczekiwanego harmonogramu, przykładowy komunikat błędu, czas ostatniego poprawnego powiadomienia oraz informację, czy samo zadanie wykonuje się prawidłowo. Nie należy usuwać logów przed diagnozą, ponieważ mogą wskazywać moment i przyczynę usterki. Jeżeli w raporcie znajdują się hasła, klucze lub inne dane poufne, należy je wcześniej zabezpieczyć i przekazać tylko informacje niezbędne do odtworzenia problemu.

Weryfikacja może obejmować sprawdzenie wpisów crontaba, środowiska procesu, uprawnień skryptu, kodów zakończenia, lokalnej kolejki pocztowej, nagłówków wiadomości oraz logów systemowych. Po usunięciu przyczyny warto wykonać próbę kontrolną o ustalonej porze i potwierdzić zarówno uruchomienie zadania, jak i dostarczenie wiadomości. Takie podejście pozwala odróżnić awarię harmonogramu od problemu z samym skryptem lub przekazywaniem poczty.