Re: Mail von Cron kommen nicht an

Matthias Fechner <idefix(at)fechner.net> wrote:
> * Oliver Fromme <olli(at)lurza.secnetix.de> [15-06-05 12:51]:
> > Hast Du eigentlich mal in /var/log/maillog reingeschaut?
> > Wie unterscheiden sich die dortigen Einträge zwischen einer
> > cron-generierten Mail und einer manuell generierten Mail?
> > Irgendeinen Unterschied muß es ja geben ...
>
> Ja, da gibt es auch einen Unterschied, bei einem Fehler bekomme ich
> die folgenden Zeilen:
> 2005-06-15 11:46:00 1DiUTA-000As1-V2 <= <> R=1DiUTA-000As0-UX U=mailnull P=local S=701
> 2005-06-15 11:46:04 1DiUTA-000As1-V2 => root(at)fechner.net R=dnslookup T=remote_smtp H=mail.fechner.net [83.120.0.234] X=TLSv1:DHE-RSA-AES256-SHA:256
> 2005-06-15 11:46:04 1DiUTA-000As1-V2 Completed
>
> Von der Konsole bekomme ich mit dem Aufruf: [...]
> 2005-06-15 13:29:30 1DiW59-000BNq-61 <= root(at)fechner.net U=root P=local S=551
> 2005-06-15 13:29:34 1DiW59-000BNq-61 => root(at)fechner.net R=dnslookup T=remote_smtp H=mail.fechner.net [83.120.0.234] X=TLSv1:DHE-RSA-AES256-SHA:256
> 2005-06-15 13:29:34 1DiW59-000BNq-61 Completed

Hmm. Ich kenne exim leider nicht genau genug, um diese
Logzeilen mit Sicherheit deuten zu können. Ich muß zuge-
ben, mit sendmail-, postfix- und qmail-Logs mehr vertraut
zu sein. :-)

> hier scheint die Mail anders übergeben zu werden.

Ja. Evtl. bringt es was, mal in der exim-Doku zu gucken,
damit man die Log-Einträge interpretieren kann. U=xxx
scheint die UID zu sein, unter der die Mail abgeschickt
wurde. Der cron macht da offenbar ein setuid auf den
mailnull-User -- Du kannst ja testweise mal versuchen,
dasselbe manuell zu machen (»su -mf testuser«, und dann
wieder /usr/sbin/sendmail usw.). Das R=xxx scheint so
eine Art ID für diesen Mailtransfer zu sein. S=701 und
S=551 ist offenbar ein Status. Aber Spekulieren kann
hier in die Irre führen -- guck lieber mal in die exim-
Doku.

> > - Trace ihn und alle seine Children (als root):
> > strace -v -o crontrace -s 9999 -ff -p $CRONPID
> > (Nötigenfalls vorher strace aus den Ports installieren.)
>
> hm, irgendwas passt da wohl nicht:
> Process 43396 attached - interrupt to quit
> crontrace: Bad file descriptor
 < [...]
> syscall trouble
> zsh: exit 1 strace -v -o crontrace -s 9999 -ff -p 43396

Autsch. Funktioniert strace bei Dir überhaupt? Geht z.B.
ein »strace date« bei Dir? Das sollte ca. 15 Zeilen Ausga-
be produzieren. Wenn nicht: Hast Du das strace auf dieser
Release compiliert? Da es sehr systemnah ist, reagiert es
empfindlich auf Kerneländerungen. Bei einem Update des
Systems sollte man daher strace neu bauen (und auch andere
systemnahe Programme wie z.B. lsof). Hast Du procfs auf
/proc gemountet? Früher brauchte strace das, aber ich
dachte eigentlich, daß das inzwischen nicht mehr so sei.

Notfalls versuch mal »ktrace -i -p $CRONPID«. Nachdem der
cronjob gelaufen ist, mit »ktrace -C« das Tracen wieder
disablen (nicht vergessen!). Den Trace kann man sich dann
mit »kdump« anschauen. Ist nicht so schön und übersicht-
lich wie die Ausgabe von strace, aber in der Not frißt der
Teufel Fliegen. ;-)

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
Python is executable pseudocode.  Perl is executable line noise.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message