Wyłączyć e-maile cron, chyba że wystąpią błędy?

12

Jak mogę odbierać wiadomości e-mail od crona tylko w przypadku wystąpienia błędów?

W przeważającej większości przypadków zadania będą działać dobrze - i naprawdę nie dbam o wynik.

Tylko w rzadkim przypadku awarii chcę / muszę wiedzieć.

Mam dostępny procmail - ale nie jestem pewien, czy to, co opisuję, jest możliwe do zarządzania zewnętrznie, aby cron „poprawnie”.

cron email error-handling

— królikarnia
źródło

Co jeśli sam crond nie działa? Czy maszyna jest w trybie offline? Dlatego nigdy nie zawracam sobie głowy e-mailami od cron i korzystam z dedykowanej usługi monitorowania cron. Jestem stronnikiem WDT.io i polecam to.

— Christian Pekeler,

8

Ponieważ nie zależy ci na wynikach, możesz przekierować STDOUT zadania do /dev/nulli pozwolić, aby STDERR był wysyłany pocztą (przy użyciu MAILTOzmiennej środowiskowej).

Na przykład:

...
...
MAILTO=foobar@example.com
...
...
* * * * * /my/script.sh >/dev/null

wyśle pocztę, gdy jest ona wysyłana tylko na STDERR (z STDERR), i odrzuci STDOUT.

To oczywiście zakłada, że gdy program napisał na STDERR, nie powiódł się; nie zawsze tak jest. Jeśli masz kontrolę nad programem, możesz to zrobić. W każdym skomplikowanym przypadku powinieneś napisać jakieś opakowanie, które uruchamia polecenia (polecenia) i odpowiednio wysłać pocztę. I umieść opakowanie jako cronzadanie.

— heemayl
źródło

1

Minusem tego podejścia jest to, że gdy się nie powiedzie, otrzymujesz tylko wynik STDERR, co może utrudnić diagnozę, niż gdybyś miał pełną moc wyjściową.

— płyn do płukania

11

chronicPolecenie od moreutils wykonuje polecenie cicho, chyba że się nie powiedzie.

Cytując z podręcznika:

Chroniczny uruchamia polecenie i ustawia, aby jego standardowe wyjście i błąd standardowy były wyświetlane tylko w przypadku niepowodzenia polecenia (wyjście niezerowe lub zawieszenie się). Jeśli polecenie się powiedzie, wszelkie zewnętrzne dane wyjściowe zostaną ukryte.

Częstym zastosowaniem chronicznego jest uruchamianie zadania cron. Zamiast próbować zachować komendę w ciszy i radzić sobie z wiadomościami zawierającymi przypadkowe dane wyjściowe, gdy się powiedzie, i nie wypowiadać wystarczająco dużo danych wyjściowych, gdy się nie powiedzie, możesz po prostu uruchomić je werbalnie zawsze i użyć funkcji chronicznej, aby ukryć dane wyjściowe.

— Michał Politowski
źródło

8

Jak mogę odbierać wiadomości e-mail od crona tylko w przypadku wystąpienia błędów?

Możesz owinąć swoje wywołania cron za pomocą cronic , skryptu powłoki, który zjada dane wyjściowe crona, chyba że kod powrotu wywoływanego procesu jest różny od zera lub nie wystąpił błąd śledzenia.

Aby użyć cronic, pobierz skrypt w odpowiednie miejsce, np /usr/local/bin. Wpisy w crontab muszą być poprzedzone ścieżką do skryptu (np. /usr/local/bin/cronic) Lub po prostu cronic, pod warunkiem, że twój PATHjest poprawnie ustawiony.

Pamiętaj, że „błędy” są źle zdefiniowanym terminem w twoim pytaniu i wymagają dokładnej definicji. Aby funkcja cronic była przydatna, musisz upewnić się, że zadania, które zawijasz z funkcją cronic, zgłaszają błędy w jeden ze sposobów, w jaki definiuje warunek błędu. Domniemane metody raportowania, takie jak zapisywanie ciągów tekstowych STDOUT, będą wymagały dalszych przemyśleń, aby uczynić to kompatybilnym z cronic lub innym mechanizmem raportowania cron.

Dostępne są inne opakowania, do których linki znajdują się na stronie chronicznej:

Sza
Cronwrap

— Kosmiczny Ossifrage
źródło

1

Jest to croniczwiązane chronic, czy to tylko przypadek?

— Toby Speight,

@TobySpeight Coincidence wydaje się. cronicjest zaimplementowany w bash, chronicjak sugerowano we wcześniejszej odpowiedzi, jest skrypt Perla.

— Cosmic Ossifrage,

4

Oto kolejna odmiana, którą z powodzeniem stosuję od wielu lat - przechwytuj dane wyjściowe i drukuj je tylko w przypadku błędu . Nie wymaga to plików tymczasowych i zachowuje wszystkie dane wyjściowe . Ważną częścią jest to, 2>&1że przekierowuje STDERR do STDOUT.

Wyślij całe wyjście za pomocą domyślnej konfiguracji cron mailera:

1 2 * * * root OUTPUT=`flexbackup -set all 2>&1` || echo "$OUTPUT"

To samo, ale z określonym adresem i tematem:

1 2 * * * root OUTPUT=`flexbackup -set all 2>&1` || echo "$OUTPUT" | mail -s "Failed to backup" an@email.address

Możesz nawet wykonać wiele działań w przypadku błędu i dodać do wiadomości e-mail:

1 2 * * * root OUTPUT=`flexbackup -set all 2>&1` || {echo "$OUTPUT" ; ls -ltr /backup/dir ; }

Działa to w przypadku prostych poleceń. Jeśli masz do czynienia ze złożonymi potokami ( find / -type f | grep -v bla | tar something-or-other), lepiej jest przenieść komendę do skryptu i uruchomić skrypt przy użyciu powyższego podejścia. Powodem jest to, że jeśli jakakolwiek część potoku wysyła do STDERR, nadal będziesz otrzymywać e-maile.

— Akom
źródło

Należy umieścić $OUTPUTw cudzysłowie: "$OUTPUT".

— G-Man mówi „Przywróć Monikę”

@ G-Man Fair point, zawsze istnieje szansa, że wyjście może zawierać „-n” lub coś podobnego.

— Akom

0

Prawdopodobnie nie myślałem o tym przez cały czas, ale

* * * * * yourthing.sh >/tmp/yourthing.log && rm -f /tmp/yourthing.log; cat /tmp/yourthing.log 2>/dev/null

w zwykłych przypadkach przekierowałby wszystko do pliku tymczasowego (prawdopodobnie chciałbyś użyć go w mktempcelu uzyskania unikalnej nazwy pliku), usunąłby to, jeśli plik się powiódł, a następnie catzawartość ponownie, jeśli nadal istnieją (tzn. twoja.html została zakończona z warunkiem błędu), do odebrania przez program pocztowy cron.

Jeśli pamięć służy, cron już nic nie wysyła, jeśli nie ma danych wyjściowych, więc jeśli plik dziennika jest pusty lub nie istnieje, nic się nie dzieje. (Przekierowujemy komunikat o błędzie.)

— Ulrich Schwarz
źródło