[Cron] Mails abstellen

Post by Andreas Kohlbach
Ich bin offenbar zu dumm zum Googlen.
Ich moechte Hinweise auf fehlgeschlagene Cron Jobs unterbinden. Soweit
versuchte ich hinten an den Befehl schon nach > /dev/null umzuleiten. Ich
habe nun auch ein MAILTO drin. Scheibar mag er es nicht, wenn es an einen
nicht excistierenden User geleitet wird, dass ich immer noch einen
Bouncer bekomme.

Was Du suchst ist die Umleitung von STDERR.
http://tinyurl.com/q94m9 sollte Dich inspirieren.

A!S

--
Kein weiser oder tapferer Mann legt sich auf die Schienen der
Geschichte und wartet, daß der Zug der Zukunft ihn überfährt.
-- Dwight David Eisenhower

Daniel Michalik

2006-05-20 22:44:29 UTC

Post by Andreas Kohlbach
Ich moechte Hinweise auf fehlgeschlagene Cron Jobs unterbinden. Soweit
versuchte ich hinten an den Befehl schon nach > /dev/null umzuleiten. Ich
habe nun auch ein MAILTO drin. Scheibar mag er es nicht, wenn es an einen
nicht excistierenden User geleitet wird, dass ich immer noch einen
Bouncer bekomme.

Ganz ins blaue geraten, ohne es zu überprüfen:
MAILTO an einen existierenden User. Mails dorthin gibt es nur, wenn der
Cronjob auf Stdout oder Stderr etwas ausgibt. Möchtest du das
verhindern, solltest du beides(!) auf /dev/null umleiten. Du schreibst,
dass fehlgeschlagene Cronjobs an dich berichtet werden, diese
geben auf Stderr aus. Du leitest aber nur Stdout um.

Über Sinn oder Unsinn des Ganzen musst du selbst entscheiden, der
technische Weg dorthin sollte so funktionieren. Man korrigiere mich,
wenn ich falsch liege.

-daniel-

--
http://www.blackamp.de

GPG-Key: 0x53BE81EC
Fingerprint: A854 4C0A FF1A 09DF 5433 0EF8 1CF0 0213 53BE 81EC

Erkan Yanar

2006-05-21 00:56:47 UTC

Naja das mit dem Bouncer hat nichts mit Mögen zu tun. Aber da Du schon
MAILTO gefunden hast

#v+
man 5 crontab

... If MAILTO is defined but empty (MAILTO=""), no mail
will be sent. ^^^^^^^

#v-

tschazu
erkan

Andreas Kohlbach

2006-05-21 20:51:06 UTC

Post by Erkan Yanar

Naja das mit dem Bouncer hat nichts mit Mögen zu tun. Aber da Du schon
MAILTO gefunden hast
#v+
man 5 crontab
... If MAILTO is defined but empty (MAILTO=""), no mail
will be sent. ^^^^^^^
#v-

Danke, auch an die anderen. Warum habe ich das nicht gesehen?

Wegen Sinn bzw. Unsinn. Ich habe hier eine sehr walkige Internet
Anbindung, woran ich erstmal nichts aendern kann (aber bald). Fetchnews
soll alle halbe Stunde mal holen. Da das wegen der Verbindung oft
fehlschlaegt, kommen Mails. Die muss ich nicht haben, weil es nicht so
wichtig ist, wenn das mal fehlschlaegt. Irgendwann klappts schon, und
wenn keine neuen News da sind, weiss ich schon warum (ausser ihr habt
alle keine Lust mehr zum Posten ;-).

--
Andreas
PGP Key available on public key servers
Mailfilter rules http://www.tombstones.org.uk/~ankman/filterrules.html

Alexander Skwar

2006-05-21 07:52:29 UTC

Post by Andreas Kohlbach
Ich bin offenbar zu dumm zum Googlen.

Auf jeden Fall bist Du hier falsch. Die Frage ist nicht Linuxspezifisch.
Flup2 gesetzt.

MAILTO wird nicht von allen crons unterstützt. Darum besser gar nicht
erst daran gewöhnen.

Alexander Skwar

--
I have often regretted my speech, never my silence.
-- Publilius Syrus

Juergen Ilse

2006-05-24 19:41:23 UTC

Hallo,

Hast du die Standardfehlerausgabe nicht auch nach /dev/null geschoben?
Warum nicht?

Post by Andreas Kohlbach
Ich habe nun auch ein MAILTO drin. Scheibar mag er es nicht, wenn es an
einen nicht excistierenden User geleitet wird, dass ich immer noch einen
Bouncer bekomme.

Was sollte es fuer einen Sinn haben, die Mail an eine ungueltige
Mailadresse zustellen zu wollen? Wenn du die ins Nirwana senden
willst, solltest du einen leeren "MAILTO" Eintrag verwenden:

MAILTO=''

Aus "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.

Gilt aber so moeglicherweise nur fuer den Vixie cron ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

Alexander Skwar

2006-05-24 20:13:11 UTC

Post by Juergen Ilse
Hallo,

Hast du die Standardfehlerausgabe nicht auch nach /dev/null geschoben?
Warum nicht?

Weil man das nicht will. Fehlerausgaben haben meist einen Sinn und
sollten nicht ignoriert werden, es sei denn, man weiß, was man tut.

Post by Andreas Kohlbach
Ich habe nun auch ein MAILTO drin. Scheibar mag er es nicht, wenn es an
einen nicht excistierenden User geleitet wird, dass ich immer noch einen
Bouncer bekomme.

Was sollte es fuer einen Sinn haben, die Mail an eine ungueltige
Mailadresse zustellen zu wollen? Wenn du die ins Nirwana senden
MAILTO=''

Und auch Dir sei gesagt, das nicht jede crontab Implementation
MAILTO unterstützt, weshalb man sich sowas am besten gar nicht
erst angewöhnt. Man sollte sich nur an Sachen gewöhnen, die in
IEEE 1003.1 definiert sind - und das ist MAILTO eben nicht.

http://opengroup.org/onlinepubs/009695399/utilities/crontab.html

Um Mails von einem Befehl auszuschalten, sorge man dafür, das
der Befehl keine Ausgaben erzeugt. Das geht teilw. durch "--quiet"
Parameter oder halt immer durch "> /dev/null" (und "2> /dev/null",
wobei man das aber nicht will, wie gesagt).

Post by Juergen Ilse
Gilt aber so moeglicherweise nur fuer den Vixie cron ...

Ah :)

Ja, gilt nur für vixie cron. Bzw.: Keine Ahnung bzgl. "nur". Gilt
aber definitiv nicht für alle crons. fcron unterstützt MAILTO
schonmal nicht.

Alexander Skwar

--
<dhd> perl < /dev/bdsm
<knghtbrd> you have a /dev/bdsm?
<dhd> sure, it's a pseudosadomasochistic random number generator

Christian Schneider

2006-05-24 20:25:36 UTC

[ MAILTO in crontab(5) ]

Post by Alexander Skwar
Ja, gilt nur für vixie cron. Bzw.: Keine Ahnung bzgl. "nur". Gilt
aber definitiv nicht für alle crons. fcron unterstützt MAILTO
schonmal nicht.

MAILTO nicht, aber mailto

#v+
mailto email-address(name of file's owner)

Mail output (if needed) to "email-address". It can be either a
single user-name or a fully qualified email address. A mailto
declared and empty (string "") is equivalent to "mail(false)".

See also: options mail, forcemail, nolog.
#v-

Alexander Skwar

2006-05-24 20:59:43 UTC

Post by Christian Schneider
[ MAILTO in crontab(5) ]

Post by Alexander Skwar
Ja, gilt nur für vixie cron. Bzw.: Keine Ahnung bzgl. "nur". Gilt
aber definitiv nicht für alle crons. fcron unterstützt MAILTO
schonmal nicht.

MAILTO nicht, aber mailto

Danke (natürlich auch an Erkan).

Alexander Skwar

--
Some marriages are made in heaven -- but so are thunder and lightning.

Juergen Ilse

2006-05-25 04:02:46 UTC

Hallo,

Post by Christian Schneider
[ MAILTO in crontab(5) ]

Post by Alexander Skwar
Ja, gilt nur für vixie cron. Bzw.: Keine Ahnung bzgl. "nur". Gilt
aber definitiv nicht für alle crons. fcron unterstützt MAILTO
schonmal nicht.

MAILTO nicht, aber mailto

In manchen Versionen auch MAILTO:
---------- aus man 5 fcrontab der Version 2.0.2 ----------
Plus, the special variable MAILTO allows you to tell fcron to whom it
has to mail the command's output. Note that MAILTO is in fact equiva-
lent to a global declaration of the option mailto (see below). It is
only used for backward compatibility, so you should use the option
mailto directly.
---------------------------------------------------------

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

Erkan Yanar

2006-05-24 20:35:30 UTC

Alexander Skwar schrieb:
[snip]

Post by Alexander Skwar
Und auch Dir sei gesagt, das nicht jede crontab Implementation
MAILTO unterstützt, weshalb man sich sowas am besten gar nicht
erst angewöhnt. Man sollte sich nur an Sachen gewöhnen, die in
IEEE 1003.1 definiert sind - und das ist MAILTO eben nicht.
http://opengroup.org/onlinepubs/009695399/utilities/crontab.html

Da gebe ich Dir Recht.

Post by Juergen Ilse
Gilt aber so moeglicherweise nur fuer den Vixie cron ...

Ah :)
Ja, gilt nur für vixie cron. Bzw.: Keine Ahnung bzgl. "nur". Gilt
aber definitiv nicht für alle crons. fcron unterstützt MAILTO
schonmal nicht.

Da nicht:

man 5 fcrontab
#v+
Plus, the special variable MAILTO allows you to tell fcron to whom it
has to mail the command's output. Note that MAILTO is in fact
equivalent to a global declaration of the option mailto (see below).
It is only used for backward compatibility, so you should use the
option mailto directly.
#v-

tschazu
erkan

--
über den grenzen muß die freiheit wohl wolkenlos sein

Juergen Ilse

2006-05-25 03:58:22 UTC

Hallo,

Hast du die Standardfehlerausgabe nicht auch nach /dev/null geschoben?
Warum nicht?

Weil man das nicht will.

Andreas will das in diesem Fall schon, das war der Grund fuer diesen
Thread ...

Post by Alexander Skwar
Fehlerausgaben haben meist einen Sinn und sollten nicht ignoriert
werden, es sei denn, man weiß, was man tut.

Dieser Thread ist aus der Frage entstanden, wie man die Mail bei
fehlgeschlagenen cron-jobs los werden kann, also genau um die
Faelle, wo man bei cron-jobs (hoffentlich) weiss was man tut
(die Mail wird ja *genau* *dann* generiert, wenn der cron-job
Ausgaben erzeugt ...).

Post by Andreas Kohlbach
Ich habe nun auch ein MAILTO drin. Scheibar mag er es nicht, wenn es an
einen nicht excistierenden User geleitet wird, dass ich immer noch einen
Bouncer bekomme.

Was sollte es fuer einen Sinn haben, die Mail an eine ungueltige
Mailadresse zustellen zu wollen? Wenn du die ins Nirwana senden
MAILTO=''

Und auch Dir sei gesagt, das nicht jede crontab Implementation
MAILTO unterstützt,

Hast du mein Posting ueberhaupt gelesen? einige Zeilen weiter unten
habe ich darauf hingewiesen, dass das mit dem MAILTO evt. nur mit
dem Vixie cron funktioniert (bei fcron bin ich mir nicht sicher,
beim Dillon cron bin ich mir sicher, dass MAILTO so nicht funktio-
niert ...). Oder war dein Beitrag eher ein "Reflex" auf den Wunsch,
Fehlerausgaben zu unterdruecken und/oder die Moeglichkeit auch
weniger portable Konstrukte verwenden zu koennen?

Post by Alexander Skwar
Um Mails von einem Befehl auszuschalten, sorge man dafür, das
der Befehl keine Ausgaben erzeugt. Das geht teilw. durch "--quiet"
Parameter oder halt immer durch "> /dev/null" (und "2> /dev/null",
wobei man das aber nicht will, wie gesagt).

Andreas wollte genau das und hat das auch sehr deutlich geschrieben.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
PS: Da du anscheinend so sicher bist, dass fcron das "MAILTO" Feature
nicht unterstuetzt: fcron 2.0.2 kennt es durchaus ...

Alexander Skwar

2006-05-25 08:27:41 UTC

Post by Alexander Skwar
Und auch Dir sei gesagt, das nicht jede crontab Implementation
MAILTO unterstützt,

Hast du mein Posting ueberhaupt gelesen?

Ja, habe ich. Und Du? Du hast mein Posting scheinbar nicht ganz
gelesen, oder wie erklärt sich Deine Nachfrage?

Post by Juergen Ilse
einige Zeilen weiter unten
habe ich darauf hingewiesen, dass das mit dem MAILTO evt. nur mit
dem Vixie cron funktioniert

Und ich habe dann darauf mit

| Ah :)
|
| Ja, gilt nur für vixie cron.

geantwortet.

Allerdings gestehe ich ein, das ich Deinen Hinweis auf vixie Cron noch
nicht gelesen habe, als ich den "Und auch Dir sei gesagt[...]" Absatz
geschrieben habe.

Post by Juergen Ilse
PS: Da du anscheinend so sicher bist, dass fcron das "MAILTO" Feature
nicht unterstuetzt: fcron 2.0.2 kennt es durchaus ...

Nein, ich bin mir nicht so sicher. Wie kommst Du auf die Idee?
<news:***@m-id.message-center.info> ist erheblich
vor Deinem Posting gepostet worden.

Alexander Skwar

--
Don't be irreplaceable, if you can't be replaced, you can't be promoted.

Andreas Kohlbach

2006-06-01 15:04:28 UTC

Hast du die Standardfehlerausgabe nicht auch nach /dev/null geschoben?
Warum nicht?

Weil man das nicht will.

Andreas will das in diesem Fall schon, das war der Grund fuer diesen
Thread ...

Right. :-)

Post by Alexander Skwar
Fehlerausgaben haben meist einen Sinn und sollten nicht ignoriert
werden, es sei denn, man weiß, was man tut.

Ich haette es vielleicht anders angehen sollen, und statt MAILTO=""
besser dem Job (fetchnews) sagen sollen, keine Ausgaben zu produzieren,
so das moeglich ist.

Andere Jobs sollen ja ruhig Mails generieren, nur fetchnews halt nicht.

| man fetchnews
| No manual entry for fetchnews
| See 'man 7 undocumented' for help when manual pages are not available.

F***!

| fetchnews -h
| Usage: fetchnews [-q] [-v] [-x #] [-l] [-n] [-f] [-P] [-w]
| -q: quiet, suppress some warnings, cancels -v
| [...]

Ah. :-)

Ich hoffe mal es "supresst" alles, dass Cron wirklich keine Mail
generiert. Werde ich die Tage mal testen.

--
Andreas
PGP Key available on public key servers
Mailfilter rules http://www.tombstones.org.uk/~ankman/filterrules.html

Sebastian Niehaus

2006-06-11 19:33:00 UTC

Andreas Kohlbach <***@email.com> writes:

[...]

Post by Andreas Kohlbach
| fetchnews -h
| Usage: fetchnews [-q] [-v] [-x #] [-l] [-n] [-f] [-P] [-w]
| -q: quiet, suppress some warnings, cancels -v
| [...]
Ah. :-)
Ich hoffe mal es "supresst" alles, dass Cron wirklich keine Mail
generiert.

,----
| crystalline:~$ /usr/sbin/fetchnews -q
| warning: news.arcor.de: cannot resolve host name: Temporary failure in name resolution
| warning: news.sunsite.dk: cannot resolve host name: Temporary failure in name resolution
| warning: news.gmane.org: cannot resolve host name: Temporary failure in name resolution
| warning: news.online.de: cannot resolve host name: Temporary failure in name resolution
| warning: news.motzarella.de: cannot resolve host name: Temporary failure in name resolution
| warning: linuxprinting.org: cannot resolve host name: Temporary failure in name resolution
| crystalline:~$
`----

Andreas Kohlbach

2006-06-11 23:42:55 UTC

Post by Sebastian Niehaus
[...]

Das war hier mittlerweile auch, aber ich wollte mich nicht weiter
blamieren. ;-)

Mit der Umleitung von stdout und stderr tuts aber.

--
Andreas
PGP Key available on public key servers
Mailfilter rules http://www.tombstones.org.uk/~ankman/filterrules.html

Heike C. Zimmerer

2006-05-25 09:31:59 UTC

Post by Juergen Ilse
Hast du die Standardfehlerausgabe nicht auch nach /dev/null geschoben?
Warum nicht?

Weil man das nicht will. Fehlerausgaben haben meist einen Sinn und
sollten nicht ignoriert werden, es sei denn, man weiß, was man tut.

Ich würde mal davon ausgehen, dass dieser "es sei denn" - Fall
vorliegt, denn der OP hat gezielt danach gefragt.

Nun weiß ich nicht, was 'man' will. Ich will aber schon mal Befehle
loslassen, die (u.U. sogar normalerweise) fehlschlagen und halte es
für denkbar, dass das öfters vorkommt.

Gruß,

Heike

Thorsten Kampe

2006-05-25 10:01:56 UTC

* Alexander Skwar (2006-05-24 21:13 +0000)

Post by Juergen Ilse
MAILTO=''

Super Logik. Man sollte also nie die Funktionalität eines Programms
voll nutzen, weil vielleicht eine andere Implementation das nicht
unterstützt?

Ich gebe dir recht, daß das Ignorieren von Fehlermeldungen (ausser in
genau definierten Fällen) bedenklich ist. Aber Vixie Cron hat die
Mailto-Funktion aus genau diesem Grunde und deshalb sollte man sie
auch nutzen, wenn man diesen cron verwendet.

Joachim Moskalewski

2006-05-25 06:27:11 UTC

Juergen Ilse <***@usenet-verwaltung.de> schrieb:

[ MAILTO ]

Post by Juergen Ilse
Gilt aber so moeglicherweise nur fuer den Vixie cron ...

Kleine Ergänzung: Wer trotz umgeleiteter Ausgaben oder mailto-Einträge
hartnäckig Emails von irgend einer cron-Variante zugeschickt bekommt,
sollte evtl. noch einen Blick in jene Scripte werfen, die cron startet -
auch diese können u.U. Emails generieren und verschicken ...

Und zu dem "warum" man diese Emails evtl. gar nicht haben will: Ich will
solche Informationen eher in /var/log vorfinden. Und ständig die
Meldung, dass mein Rechner kein FQDN hat (was er gar nicht braucht und
auch so bleiben wird) ist einfach nur lästig.

Ciao,
:) Jo

Andreas Kohlbach

2006-06-01 15:10:26 UTC