[gelöst] Cron nervt mit mails

[holger.lehn]

Hi,

ich habe ziemlich viel auf cron realisiert. nn merke ich aber, dass mir CRON bei jeder Jobausführung eine mail schickt....z.B. wenn ich mit fetchmail meine Mails hole, oder mit fetchnews meine nes hole ,usw.

jetzt habe ich heute 1295 mails bekommen !

Wie gewöhn ich den dem CRON ab, dass er immer mails schickt ???

[Savar]

packe hinter die Zeilen in der Crontab einfach folgendes (hier meine Crontab)

Code: Alles auswählen

0 0-23/2 * * * /home/vmail/check@tne.localhost.net/SPAMHAM.sh > /dev/null 2>&1

wobei das was hinter "SPAMHAM.sh" das ist, was du bei dir einfügen musst

[fuzzy]

Hallo holger.lehn,
hier noch ein Linktipp:
http://www.rootforum.de/forum/viewtopic ... c9fc587f36

Gruß fuzzy

[holger.lehn]

Hi,

danke für die tips, aber ...

- die Ausgabe unleiten funktioniert sicherlich, aber ich will das gar keine Ausgabe stattfinden.

- in meiner crontab ist keine mailto ziele die ich löschen könnten

==> man 5 crontab

In addition to LOGNAME, HOME, and SHELL, cron(8) will look at MAILTO if it has any reason to send mail as a result of running commands in ``this'' crontab. If MAILTO is defined (and non-empty), mail is sent to the user so named.

If MAILTO is defined but empty (MAILTO=""), no mail will be sent. Otherwise mail is sent to the owner of the crontab.

"MAILTO="" " eingefügt und scheint es z gehen...danke für eure Tips.

[Savar]

naja, jetzt kriegst du aber auch von allen anderen Tools die vielleicht kritischere Informationen haben keine Mail.. musst du aber selber wissen..

btw: ob ich die Fehlerausgabe ins "Nichts" leite oder Cron keine Ahnung hat wohin er es schicken soll, ist das gleiche.. der einzige Unterschied.. bei letzterem (so wie du es gemacht hat) wird Cron nochmal aktiv und muss schauen ob er eine Mail schicken kann..

[Silke]

Moin,

- die Ausgabe unleiten funktioniert sicherlich, aber ich will das gar keine Ausgabe stattfinden.

Das funktioniert nicht nur, das ist auch uebliche Praxis. Normalerweise leitet man auch
nur die "normalen" Ausgaben nach /dev/null - wenn ein Script Fehler erzeugt, solltest
du das eigentlich wissen wollen. Mit deiner jetzigen Konfiguration wirst du es aber
nicht erfahren.

Die Ausgaben finden uebrigens trotzdem statt, cron weiss halt nur jetzt nicht mehr,
wohin damit (also landen sie vermutlich eh in /dev/null, kann das sein?).

Gruss,
- Silke -

[Savar]

Die Ausgaben finden uebrigens trotzdem statt, cron weiss halt nur jetzt nicht mehr,
wohin damit (also landen sie vermutlich eh in /dev/null, kann das sein?).

Gruss,
- Silke -

Hmm.. naja ich denke eher das Cron die Ausgabe empfängt und dann diese einfach verwirrft wenn er nicht weiß wohin damit. Aber das ist auch nur geraten.
Ansonsten hattest du natürlich recht!

Gruß Savar

[holger.lehn]

Das ist zwar richtig, aber ... wie kriege ich CRON dazu mir das nicht zu sagen was ich nicht wissen will, aber trotzdem Fehlermeldungen zu kriegen ?

[Savar]

indem du NUR die Standardausgabe der Skripte per

Code: Alles auswählen

 > /dev/null

umleitest... mittels

Code: Alles auswählen

 2>&1

hattest du dann nämlich auch die Fehlerausgabe nach /dev/null umgeleitet... solange das Skript (oder ein Unterskript/Tool des Skriptes) keinen Fehler bringt, kriegst du auch keine Mail mehr!

[crack]

Laut Threadname ist das Problem gelöst aber ich wollte nur für's Protokoll eine Lösung aufzeigen. 2>&1 funktioniert bei mir manchmal nicht.

Mit 1>> kann man alle Meldungen die nach stout gehen umleiten, alles was nach stderr geht, also Fehlermeldungen, kann man mit 2>> umleiten.

Beispiel:
Ein

Code: Alles auswählen

rm nicht_vorhanden

erzeugt eigentlich eine Fehlermeldung das die Datei nicht vorhanden ist.
Mit

Code: Alles auswählen

rm nicht_vorhanden 2>> /dev/null

leitet man diese Fehlermeldung nach /dev/null.

Benny