Błąd „(CRON) informacji (brak zainstalowanego MTA, odrzucanie danych wyjściowych)” w dzienniku systemowym

Mam nową instalację systemu Ubuntu 12.04.1 LTS i wielu serwerów.

Nie dodałem żadnych zadań cron ani nie edytowałem mojego crontab na tych serwerach, jednak mniej więcej w tym samym czasie dla każdej maszyny dostaję 75% skok procesora i następujące informacje w moim dzienniku systemowym w momencie wzrostu:

CRON[8380]: (CRON) info (No MTA installed, discarding output)

Mam zainstalowany mono-complete i uruchamiam serwer internetowy stosu usług.

Jaki jest najlepszy sposób, aby temu zapobiec? Chciałbym móc usunąć skok CPU.

Linux używa poczty do wysyłania powiadomień do użytkownika. Większość dystrybucji Linuksa ma zainstalowaną usługę pocztową (w tym MTA). Ubuntu nie.

Możesz zainstalować usługę pocztową, na przykład postfiks, aby rozwiązać ten problem.

sudo apt-get install postfix

Lub możesz to zignorować. Nie sądzę, że niemożność cron do wysyłania wiadomości ma coś wspólnego ze skokiem procesora (jest to związane z podstawowym zadaniem wykonywanym przez cron). Najbezpieczniej jest zainstalować MTA, a następnie przeczytać wiadomości ( muttjest to dobry czytnik poczty systemowej).

Dzieje się tak, ponieważ Twoje zadania cron generują dane wyjściowe, a następnie demon cron próbuje wysłać je pocztą e-mail (tj. Root). Jeśli nie potrzebujesz tego wyjścia, najłatwiejszym sposobem rozwiązania tego jest odrzucenie go na crontabie:

sudo crontab -e

i dodaj >/dev/null 2>&1do każdej pracy:

* * * * * yourCommand >/dev/null 2>&1

W moim przypadku wiadomość wskazywała na problem z uprawnieniami w skrypcie bash, ale nie widziałem go, dopóki nie zainstalowałem MTA.

Zgodnie z sugestią uruchomiłem:

sudo aptitude install postfix

Wybrałem „Lokalny” podczas instalacji i po ponownym uruchomieniu zadania cron:

sudo tail -f /var/mail/<user>

W moim przypadku wymieniłem

<user>

z „rootem”.

Byłem wtedy w stanie zobaczyć wynik błędu związany z uprawnieniami.

Jak stwierdzono we wcześniejszej odpowiedzi, dzieje się tak, ponieważ zadania cron generują dane wyjściowe, a następnie demon cron próbuje wysłać je pocztą e-mail. Jeśli nie chcesz (lub nie możesz) zainstalować MTA, ale chcesz zobaczyć dane wyjściowe, możesz przekierować dane wyjściowe zadania cron do pliku dziennika. Edytuj plik crontab za pomocą

crontab -e

(użyj, sudojeśli problem dotyczy crontab roota) i dodaj po każdym poleceniu, tak jak poniżej:>> /some/log/file 2>&1

0 3 * * * cmd   >> / some / log / file 2> & 1

Jeśli w wierszu znajduje się wiele poleceń, oddzielonych przez ;,  &&  lub ||, należy wykonać powyższe czynności dla każdego polecenia, w następujący sposób:

0 3 * * * cmd 1   >> / some / log / file 2> & 1;  cmd 2   >> / some / log / file 2> & 1

lub zgrupuj je w następujący sposób:

0 3 * * * ( cmd 1 ;   cmd 2 )   >> / some / log / file 2> & 1

Jeśli chcesz zignorować stdout i przechwycić tylko stderr, użyj zamiast tego. Umieść plik dziennika w dowolnym miejscu - w katalogu domowym , a nawet jeśli masz pewność, że nie będziesz go przechowywać.> /dev/null 2>> /some/log/file/var/log/tmp

Następnie spójrz na plik dziennika po uruchomieniu zadania.

W crontab dodaj to jako pierwszy wiersz:

MAILTO=""

Zapobiegnie to próbom wysłania wiadomości e-mail przez crona.

Jeśli nie chcesz instalować MTA (co obecnie nie jest mi potrzebne), możesz przesłać wyniki zadania cron do pliku dziennika.

sudo crontab -e

wtedy z twoją pracą crona wyglądałoby to tak.

0 3 * * * /cmd/to/run >> /var/log/somelogfile.log

możesz po prostu ogonić dziennik i zobaczyć, co się stało

sudo tail -f -n 50 /var/log/somelogfile.log

To właśnie robiłem na każdym serwerze, na którym widzę tę wiadomość w syslog

To stare pytanie, ale istnieje dodatkowa odpowiedź, która jest przydatna w niektórych okolicznościach.

Przeprowadź wyjście polecenia cron, loggeraby znalazły się w syslog.

Jest to nieco łatwiejsze niż instalacja postfiksa i umieszcza to wyjście w syslog obok innych dzienników. To polecenie przechwytuje stdout AND stderr, więc nie zobaczysz No MTA installedkomunikatu i zobaczysz wszystkie wyniki w syslog.

Przykładowy wpis cron:

0 3 * * * (cmd1;  cmd2) 2>&1 | logger -t mycmd

Możesz przeglądać dzienniki za pomocą swojego tagu, mycmdużywając:

grep 'mycmd' /var/log/syslog

Jedna strona efekt dodawania /dev/null 2>&1do komendy crona jest to, że zarówno odrzucić STDERRi STDOUT(błąd standardowy, jak i wyjście). Działa to dobrze, jeśli nie chcesz żadnych wiadomości e-mail od crona. Ale jeśli chcesz, aby Twoje błędy były wysyłane pocztą e-mail, użyj >/dev/nullzamiast tego. Przeczytaj ten post na blogu, aby uzyskać więcej wyjaśnień .

Jednak nadal będziesz musiał zainstalować MTA (agent przesyłania poczty), aby wysłać e-maile o błędach. Postfix jest wystarczająco prosty do zainstalowania za pomocą:sudo apt-get install postfix

1. Najpierw zainstaluj postfix, aby rozwiązać problem

   sudo apt-get install postfix
   

2. Jeśli Ubuntu, możesz edytować crontabplik

   sudo vim /etc/crontab
   

3. Uwaga, edytuj górny plik, nie kod w pierwszym wierszu, i wpisz

   MAILTO=root // current system user
   

4. Po cronwykonaniu dowolnego zadania otrzymasz wiadomość e-mail

   mail
   

Możesz ustawić MAILTO=””zmienną na początku crontabpliku. Spowoduje to również wyłączenie powiadomienia e-mail. Edytuj / Otwórz swoje zadania cron:

$ crontab -e

W górnej części pliku wpisz:

MAILTO=""

https://www.cyberciti.biz/faq/disable-the-mail-alert-by-crontab-command/

Miałem ten problem przy użyciu narzędzi Kitematic Docker .
Idź do pojemnika magento i kliknij exe.

Następnie uruchomić

apt-get update

Dzieje się tak, jeśli próbujesz uruchomić Magento na Kitematic. Dziennik pokaże ten błąd na maszynie wirtualnej:

potrzebuję aktualizacji.

Przepraszam, jeśli się zgubiłeś, ale tak to działa. Gubisz się, ale po prostu poczytaj o tym, a kawałki pewnego dnia się połączą. Bądź cierpliwy.