Dlaczego cron wymaga MTA do logowania? Czy ma to jakąś szczególną zaletę? Dlaczego nie może utworzyć pliku dziennika, jak większość innych narzędzi?
Odpowiedzi:
Weź pod uwagę, że tradycyjnym „standardowym” sposobem rejestrowania danych jest syslog , w którym metadane zawarte w komunikatach to „kod obiektu” i poziom priorytetu. Kod obiektu można wykorzystać do oddzielenia strumieni dziennika od różnych usług, dzięki czemu można je podzielić na różne pliki dziennika itp. (Mimo że kody obiektów są nieco ograniczone, ponieważ mają ustalone tradycyjne znaczenia).
To, czego syslog nie ma, to sposób na oddzielne wiadomości dla różnych użytkowników lub od nich, a to jest coś, co cronwymaga tradycyjnego systemu dla wielu użytkowników. Nie ma sensu zbieranie wiadomości z zadań cron wszystkich użytkowników do wspólnego pliku dziennika, w którym może je zobaczyć tylko administrator systemu. Z drugiej strony, poczta e-mail oczywiście umożliwia wysyłanie wiadomości do różnych użytkowników, więc jest to logiczny wybór. Alternatywą byłoby, aby cron wykonał pracę ręcznie i utworzył pliki dziennika do katalogu domowego każdego użytkownika, ale zakłada się, że tradycyjny system uniksowy dla wielu użytkowników ma działający MTA, więc wdrożenie go w cronie byłoby w większości daremne ćwiczenie.
Oczywiście w nowoczesnych systemach mogą istnieć alternatywne opcje.
Zakładam, że przez „logowanie” rozumiesz przechowywanie rzeczywistej wydajności zadań. Bieg miejsc pracy jest już zarejestrowany w dzienniku w cron /var/cron/log(ścieżka może się różnić między systemami). Ten dziennik nie wymaga MTA.
Zadanie cron jest uruchamiane jako użytkownik, którego crontab jest częścią zadania.
W ogólnym przypadku nie ma gwarancji, że ten użytkownik będzie mógł tworzyć pliki w systemie (użytkownik może nie być użytkownikiem interaktywnym), zwłaszcza nie w /varhierarchii, w której zwykle tworzone są dzienniki. Dlatego najbezpieczniejszym sposobem powiadamiania użytkownika o błędach i innych danych wyjściowych z zadania jest ich zebranie i przesłanie użytkownikowi pocztą elektroniczną. Umożliwiłoby to również użytkownikowi skonfigurowanie przekierowania wiadomości e-mail, aby konto mogło zobaczyć np. Błędy w preferowanej lokalizacji.
Jeśli użytkownik chce zapisać dane wyjściowe zadania do pliku, może to zrobić za pomocą prostego przekierowania w pliku crontab:
0 */2 * * * "$HOME/scripts/myscript" >"$HOME/logs/myscript.log" 2>&1
Działa to "$HOME/scripts/myscript"co drugą godzinę, w godzinę i zapisuje wszystkie dane wyjściowe do "$HOME/logs/myscript.log". Uruchomienie tego zadania nie spowoduje utworzenia wiadomości e-mail, ponieważ wszystkie dane wyjściowe są przekierowywane. Bez tego 2>&1komunikaty o błędach byłyby nadal wysyłane pocztą e-mail.
To pozwala użytkownikowi wybrać, dokąd idzie wyjście.