Debugging von Cronjobs

[Marco Moock]

Hallo zusammen!

Ich bekomme grade Mails von fehlerhaften Cronjobs.
Gibt es da ne Möglichkeit, die sinnvoll unter den gleichen Bedingungen
wie unter cron zu debuggen, sprich Ausgabe der ausgeführten Befehle,
strace o.Ä.?

Subject: Cron <***@ryz> [ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi

/bin/sh: 1: Syntax error: word unexpected

Subject: Cron <***@ryz> test -x /etc/init.d/sendmail && test -x /usr/share/sendmail/sendmail && test -x /usr/libexec/sendmail/sendmail && /usr/share/sendmail/sendmail cron-msp

Failed to find executable job: No such file or directory

[Peter Heitzer]

Post by Marco Moock
Hallo zusammen!
Ich bekomme grade Mails von fehlerhaften Cronjobs.
Gibt es da ne Möglichkeit, die sinnvoll unter den gleichen Bedingungen
wie unter cron zu debuggen, sprich Ausgabe der ausgeführten Befehle,
strace o.Ä.?

Unter cron laufen die Jobs mit reduziertem Environment, u.A. ist
PATH AFAIK auf /bin:/usr/bin beschränkt. Am besten lässt du dir mal
das Environment ausgeben mittels minimalem Cronjob.
#!/bin/sh
set >/tmp/env.txt

Dann kannst du versuchen, eine interactive Shell mit diesem Environment
zu bauen.

Beachte auch, daß /bin/sh sich nicht genauso wie die bash verhält.

[Marco Moock]

Post by Peter Heitzer
Unter cron laufen die Jobs mit reduziertem Environment, u.A. ist
PATH AFAIK auf /bin:/usr/bin beschränkt. Am besten lässt du dir mal
das Environment ausgeben mittels minimalem Cronjob.
#!/bin/sh
set >/tmp/env.txt
Dann kannst du versuchen, eine interactive Shell mit diesem
Environment zu bauen.

Gibt es da wirklich keine Option zum Debuggen?
Das Problem dürfte ja bei mir nicht zum ersten Mal aufgetreten sein.

Ich versuche jetzt rauszufinden, wie Debian das ganze Cron-Geraffels
startet und schaue, ob ich den Fehler da reproduzieren kann.

[Gregor Szaktilla]

Post by Marco Moock

Post by Peter Heitzer
Unter cron laufen die Jobs mit reduziertem Environment, u.A. ist
PATH AFAIK auf /bin:/usr/bin beschränkt. Am besten lässt du dir mal
das Environment ausgeben mittels minimalem Cronjob.
#!/bin/sh
set >/tmp/env.txt
Dann kannst du versuchen, eine interactive Shell mit diesem
Environment zu bauen.

Gibt es da wirklich keine Option zum Debuggen?

Was konkret schwebt Dir denn vor? IMO sind die Mails von cron
aussagekräftig genug, um Fehler beheben zu können.

Wenn bei mir ein cron-Job Probleme macht, lasse ich ihn einfach
minütlich ausführen und lese, was cron dazu zu sagen hat.

Gruß

Gregor

[Tim Ritberg]

Post by Gregor Szaktilla

Post by Marco Moock

Post by Peter Heitzer
Unter cron laufen die Jobs mit reduziertem Environment, u.A. ist
PATH AFAIK auf /bin:/usr/bin beschränkt. Am besten lässt du dir mal
das Environment ausgeben mittels minimalem Cronjob.
#!/bin/sh
set >/tmp/env.txt
Dann kannst du versuchen, eine interactive Shell mit diesem
Environment zu bauen.

Gibt es da wirklich keine Option zum Debuggen?

Was konkret schwebt Dir denn vor? IMO sind die Mails von cron
aussagekräftig genug, um Fehler beheben zu können.
Wenn bei mir ein cron-Job Probleme macht, lasse ich ihn einfach
minütlich ausführen und lese, was cron dazu zu sagen hat.

Vorallem kann man den "Job" doch auch direkt selbst ausführen und
gucken. Wo ist das Problem?

Du kannst auch strace mit -f (Fork) auf dem Cron-Prozess laufen lassen.

Tim

[Peter J. Holzer]

Post by Tim Ritberg
Vorallem kann man den "Job" doch auch direkt selbst ausführen und
gucken. Wo ist das Problem?

Das Problem (oder zumindest ein Problem) ist, dass das Environment in
einem Cron-Job recht minimalistisch ist. Ein Script, das in der
interaktiven Shell problemlos funktioniert, funktioniert nicht
notwendigerweise als Cron-Job.

hp

[Tim Ritberg]

Post by Peter J. Holzer

Post by Tim Ritberg
Vorallem kann man den "Job" doch auch direkt selbst ausführen und
gucken. Wo ist das Problem?

Das Problem (oder zumindest ein Problem) ist, dass das Environment in
einem Cron-Job recht minimalistisch ist. Ein Script, das in der
interaktiven Shell problemlos funktioniert, funktioniert nicht
notwendigerweise als Cron-Job.

Ja und?
Mit strace sieht du dann alles. Das hast du untnern Tisch fallen lassen...

Tim

[Peter J. Holzer]

Post by Tim Ritberg

Post by Peter J. Holzer

Post by Tim Ritberg
Vorallem kann man den "Job" doch auch direkt selbst ausführen und
gucken. Wo ist das Problem?

Das Problem (oder zumindest ein Problem) ist, dass das Environment in
einem Cron-Job recht minimalistisch ist. Ein Script, das in der
interaktiven Shell problemlos funktioniert, funktioniert nicht
notwendigerweise als Cron-Job.

Ja und?

Vielleicht habe ich missverstanden, was Du mit "direkt ausführen"
meinst. Magst Du das technisch etwas präziser formulieren?

Post by Tim Ritberg
Mit strace sieht du dann alles. Das hast du untnern Tisch fallen lassen...

Für meine Erläuterung spielt die Verwendung oder Nicht-Verwendung von
strace keine Rolle. Wozu hätte ich das erwähnen sollen?

hp

[Tim Ritberg]

Post by Peter J. Holzer
Für meine Erläuterung spielt die Verwendung oder Nicht-Verwendung von
strace keine Rolle. Wozu hätte ich das erwähnen sollen?

Die Cronzeile führt man doch bei Probleme erstmal so auf der Console aus.
Ansosten:

Mit strace -f -p brauchst du nicht viel fummeln. Du guckst einfach was
es macht.

Tim

[Peter J. Holzer]

Post by Tim Ritberg

Post by Peter J. Holzer
Für meine Erläuterung spielt die Verwendung oder Nicht-Verwendung von
strace keine Rolle. Wozu hätte ich das erwähnen sollen?

Die Cronzeile führt man doch bei Probleme erstmal so auf der Console aus.

Also lag ich mit meiner Vermutung, dass Du das mit "direkt ausführen"
meinst, richtig. Und da hast Du eben genau das Problem, dass das
Environment auf der Konsole (exakter: In einer interaktiven Shell) nicht
das gleiche ist wie in einem Cron-Job, und es somit sein *kann*, dass ein
Script, das in der interaktiven Shell das gewünschte tut, als Cron-Job
etwas anderes macht (und umgekehrt).

Post by Tim Ritberg
Mit strace -f -p brauchst du nicht viel fummeln. Du guckst einfach was
es macht.

Klar, aber es ändert nichts am oben erwähnten Verhalten, also hatte es
in meiner Antwort nichts zu suchen. Bestenfalls hätte ich das als
Alternative zum "direkt ausführen" vorschlagen können, aber das haben
andere schon gemacht, und ich bin kein Freund von "es wurde zwar alles
schon gesagt, aber noch nicht von mir"-Postings.

hp

[Marco Moock]

Post by Gregor Szaktilla

Post by Marco Moock

Post by Peter Heitzer
Unter cron laufen die Jobs mit reduziertem Environment, u.A. ist
PATH AFAIK auf /bin:/usr/bin beschränkt. Am besten lässt du dir mal
das Environment ausgeben mittels minimalem Cronjob.
#!/bin/sh
set >/tmp/env.txt
Dann kannst du versuchen, eine interactive Shell mit diesem
Environment zu bauen.

Gibt es da wirklich keine Option zum Debuggen?

Was konkret schwebt Dir denn vor? IMO sind die Mails von cron
aussagekräftig genug, um Fehler beheben zu können.

Subject: Cron <***@ryz> test -x /etc/init.d/sendmail && test -x /usr/share/sendmail/sendmail && test -x /usr/libexec/sendmail/sendmail && /usr/share/sendmail/sendmail cron-msp (failed)

Failed to find executable job: No such file or directory

Leider finde ich das nicht so aussagekräftig, dass ich beurteilen
könnte, was genau hier nicht gefunden werden kann. Die im
Betreff genannten Dateien sind alle da.

Wenn ich als root im sh diese Zeile ausführe, kommt kein Fehler.
Ergo will ich unter Realbedingungen testen, aber halt mit
verbose-Ausgabe, damit ich sehe, was den Fehler wirft.

[Claus Reibenstein]

Post by Marco Moock

Post by Gregor Szaktilla
Was konkret schwebt Dir denn vor? IMO sind die Mails von cron
aussagekräftig genug, um Fehler beheben zu können.

Failed to find executable job: No such file or directory
Leider finde ich das nicht so aussagekräftig, dass ich beurteilen
könnte, was genau hier nicht gefunden werden kann.

Lass vor diesem Bandwurmbefehl mal ein "set -x" laufen. Dann solltest Du
in der Nachricht sehen können, welche Befehle ausgeführt werden. Das
könnte helfen, den Bösewicht zu identifizieren.

Gruß
Claus

[Peter J. Holzer]

Post by Claus Reibenstein

Post by Marco Moock

Post by Gregor Szaktilla
Was konkret schwebt Dir denn vor? IMO sind die Mails von cron
aussagekräftig genug, um Fehler beheben zu können.

Failed to find executable job: No such file or directory
Leider finde ich das nicht so aussagekräftig, dass ich beurteilen
könnte, was genau hier nicht gefunden werden kann.

Lass vor diesem Bandwurmbefehl mal ein "set -x" laufen.

Und schreib das ganze in ein Shell-Script und lass das von cron
ausführen.

Das macht das auch gleich etwas übersichtlicher.

hp

[Gregor Szaktilla]

Post by Marco Moock

Post by Gregor Szaktilla

Post by Marco Moock

Post by Peter Heitzer
Unter cron laufen die Jobs mit reduziertem Environment, u.A. ist
PATH AFAIK auf /bin:/usr/bin beschränkt. Am besten lässt du dir mal
das Environment ausgeben mittels minimalem Cronjob.
#!/bin/sh
set >/tmp/env.txt
Dann kannst du versuchen, eine interactive Shell mit diesem
Environment zu bauen.

Gibt es da wirklich keine Option zum Debuggen?

Was konkret schwebt Dir denn vor? IMO sind die Mails von cron
aussagekräftig genug, um Fehler beheben zu können.

Failed to find executable job: No such file or directory
Leider finde ich das nicht so aussagekräftig, dass ich beurteilen
könnte, was genau hier nicht gefunden werden kann. Die im
Betreff genannten Dateien sind alle da.

Dass sie da sind heißt nicht zwingend, dass sie von cron auch gefunden
werden. Um so ein Problem zu vermeiden, verwende ich immer den vollen
Namen eines Programms (also mit Pfad), wenn ich einen cron-Job anlege.

Gruß

Gregor

[Stefan Reuther]

Post by Marco Moock

Post by Gregor Szaktilla
Was konkret schwebt Dir denn vor? IMO sind die Mails von cron
aussagekräftig genug, um Fehler beheben zu können.

Failed to find executable job: No such file or directory

Es gibt immerhin wenigstens eine zweite Person mit dem Problem auf
unserem Planeten:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071709

Mein Debugging-Ansatz wäre hier ebenfalls, 'strace -f' auf den cron
anzusetzen, am besten als 'strace -f -efile'.


Stefan

[Tim Ritberg]

Post by Stefan Reuther

Post by Marco Moock

Post by Gregor Szaktilla
Was konkret schwebt Dir denn vor? IMO sind die Mails von cron
aussagekräftig genug, um Fehler beheben zu können.

Failed to find executable job: No such file or directory

Es gibt immerhin wenigstens eine zweite Person mit dem Problem auf
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071709
Mein Debugging-Ansatz wäre hier ebenfalls, 'strace -f' auf den cron
anzusetzen, am besten als 'strace -f -efile'.
Stefan

as I said..

Tim

[Marco Moock]

Post by Stefan Reuther
Es gibt immerhin wenigstens eine zweite Person mit dem Problem auf
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071709

Es liegt an der cron-Version 3.0pl1-190, ich bin jetzt auf 3.0pl1-189
zurück.
Das Problem muss also bei Debian behoben werden.

[Stefan Reuther]

Post by Marco Moock

Post by Stefan Reuther
Es gibt immerhin wenigstens eine zweite Person mit dem Problem auf
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071709

Es liegt an der cron-Version 3.0pl1-190, ich bin jetzt auf 3.0pl1-189
zurück.
Das Problem muss also bei Debian behoben werden.

ok, die -190 ist 'experimental'. Aber wenn ich mir den dort eingeführten
Patch anschaue: was zum Kopulationsakt?

+ snprintf(unit_buf, 255, "cron job uid=%d: %s",
+ e->uid, e->cmd);
+ snprintf(cmd_buf, 511,
+ "systemd-run --scope --user --unit=%s %s",
+ unit_buf, e->cmd);

Das hat nie funktioniert, und wird nie funktionieren, erklärt aber das
Problem: wenn der cron erkennt, dass er unter systemd läuft, und mit uid
12 die Kommandozeile 'a b c' ausführen soll, ruft er

systemd-run --scope --user --unit=cron job uid=12 a b c a b c

auf. Schön ohne Quoting. Und ohne Überlaufbehandlung.

Damit versucht systemd-run nun also "job uid=12 ..." auszuführen, und
beschwert sich zu Recht, dass es das nicht gibt.


Stefan

[Marco Moock]

Post by Stefan Reuther

Post by Marco Moock

Post by Stefan Reuther
Es gibt immerhin wenigstens eine zweite Person mit dem Problem auf
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071709

Es liegt an der cron-Version 3.0pl1-190, ich bin jetzt auf
3.0pl1-189 zurück.
Das Problem muss also bei Debian behoben werden.

ok, die -190 ist 'experimental'. Aber wenn ich mir den dort
eingeführten Patch anschaue: was zum Kopulationsakt?
+ snprintf(unit_buf, 255, "cron job uid=%d: %s",
+ e->uid, e->cmd);
+ snprintf(cmd_buf, 511,
+ "systemd-run --scope --user --unit=%s %s",
+ unit_buf, e->cmd);
Das hat nie funktioniert, und wird nie funktionieren, erklärt aber das
Problem: wenn der cron erkennt, dass er unter systemd läuft, und mit
uid 12 die Kommandozeile 'a b c' ausführen soll, ruft er
systemd-run --scope --user --unit=cron job uid=12 a b c a b c
auf. Schön ohne Quoting. Und ohne Überlaufbehandlung.
Damit versucht systemd-run nun also "job uid=12 ..." auszuführen, und
beschwert sich zu Recht, dass es das nicht gibt.

Danke für die Erklärung!

Ist weitergegeben und kann daher bei Debian angegangen werden.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071709

[Christian Garbs]

Mahlzeit!

Post by Stefan Reuther
ok, die -190 ist 'experimental'. Aber wenn ich mir den dort eingeführten
Patch anschaue: was zum Kopulationsakt?
+ snprintf(unit_buf, 255, "cron job uid=%d: %s",
+ e->uid, e->cmd);
+ snprintf(cmd_buf, 511,
+ "systemd-run --scope --user --unit=%s %s",
+ unit_buf, e->cmd);
Das hat nie funktioniert, und wird nie funktionieren, erklärt aber das
Problem: wenn der cron erkennt, dass er unter systemd läuft, und mit uid
12 die Kommandozeile 'a b c' ausführen soll, ruft er
systemd-run --scope --user --unit=cron job uid=12 a b c a b c
auf. Schön ohne Quoting. Und ohne Überlaufbehandlung.
Damit versucht systemd-run nun also "job uid=12 ..." auszuführen, und
beschwert sich zu Recht, dass es das nicht gibt.

Uff!

Immerhin sollte dann der hier zuvor gegebene Tipp "pack mal alles in
ein Shellskript und lass das von Cron aufrufen" funktionieren ;-)


Wilde Variante, das sorum abzulösen. Könnte man nicht auch die ganze
/etc/crontab parsen und daraus automatisiert Units + Timer anlegen?
So ähnlich wie das für die Mount-Units aus der /etc/fstab passiert?

Dann wäre man Cron ganz los. Und dabei kann man das Shell-Quoting
nochmal genauso zersägen ;-)

Gruß
Christian