Frage zur crontab

[Pix]

Hallo,

ich versuche im Moment mit cron bzw. mit der crontab zurechtzukommen.
Man liesst immer, dass man die /etc/crontab nicht verändern sollte.
Also mache ich ein 'crontab /etc/crontab' um eine Kopie anzulegen und diese
dann mit 'crontab -e' zu bearbeiten.

Problem 1:
-------------
Die Kopie liegt in /var/spool/cron/crontabs/root.
Leider wird diese überhaupt nicht ausgeführt. Ich bekomme ein Mail in der steht

/bin/sh: line 1: root command not found

Das heisst, die Kopie wird ausgelesen, aber gibt eine Fehlermeldung zurück.

Inhalt der Kopie:

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.vOvhJP/crontab installed on Wed Jul 5 08:26:52 2006)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=enibas

# m h dom mon dow user command

*/1 * * * * root logger "eigene crontab"

Problem 2:
-------------
Meine Orginal crontab wird zwar abgearbeitet, aber ich bekomme keine Mail.

Inhalt der Orginal crontab:

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file.
# This file also has a username field, that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=enibas

# m h dom mon dow user command
#17 * * * * root run-parts --report /etc/cron.hourly
#25 6 * * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.daily
#47 6 * * 7 root test -x /usr/sbin/anacron || run-parts --report /etc/cron.weekly
#52 6 1 * * root test -x /usr/sbin/anacron || run-parts --report /etc/cron.monthly
#

*/1 * * * * root logger "root hat geloggt in messagas"

Beide Dateien sind bis auf die Meldung identisch. Es kommt aber trotzdem zu einem unterschiedlichen Verhalten.

Von der Orginal crontab bekomme ich keine Mail über den Vollzug und die Kopie wird gar nicht erst abgearbeitet.

Kann mir bitte jemand mal die Materie erklären wo das Problem liegt?

Danke Dirk

[gms]

warum sollte die /etc/crontab nicht verändert werden ?
Die "/etc/crontab" ist im "system crontab" Format, mit dem Kommando "crontab" beabeitest du jedoch crontab's im "user crontab" Format.
Das "system crontab" Format hat eine Spalte zusätzlich und zwar eine User-Spalte die direkt vor dem Kommando steht. Es ist daher nicht verwunderlich, wenn der cron daemon, diese Spalte als Kommando interpretiert und es zu Fehlern wie

Code: Alles auswählen

/bin/sh: line 1: root command not found

kommt.

Gruß
gms

[fuzzy]

Hallo Pix,

ich hoffe dieser Link ist hilfreich für Dich
http://www.rootforum.de/forum/viewtopic.php?t=16846

Gruß fuzzy

[Pix]

Das "system crontab" Format hat eine Spalte zusätzlich und zwar eine User-Spalte die direkt vor dem Kommando steht

So eindeutig und klar habe ich das noch in keinem meiner Dokus zu cron gelesen.
Vielen Dank für den super Hinweis !!

Ist die systemweite crontab wie eine Art allgemeine Konfigurationsdatei zu sehen, in der man Optionen reinscheiben kann, die dann automatisch auch für die crontab's im "user crontab" Format gelten, oder sind in die user-crontab auch alle Optionen gültig die in der systemweiten crontab zulässig sind?
Zum Bsp. die Option 'MAILTO='
Ich glaube aus dem Link von Fuzzy herausgelesen zu haben, dass diese Option nur in der systemweiten crontab zulässig ist. Hoffe ich habe nicht wieder was falsch verstanden, aber dass probiere ich erstmal aus, bevor ich mich wieder melde.

Vielen Dank euch beiden
Dirk

[gms]

Ist die systemweite crontab wie eine Art allgemeine Konfigurationsdatei zu sehen, in der man Optionen reinscheiben kann, die dann automatisch auch für die crontab's im "user crontab" Format gelten

nein, die crontabs sind völlig unabhängig

oder sind in die user-crontab auch alle Optionen gültig die in der systemweiten crontab zulässig sind?

Die Settings für "SHELL", "PATH" können auf alle Fälle auch in der user-crontab gesetzt werden. Über "MAILTO" steht nichts Gegenteiliges in den Manpages, es ist aber eigentlich unüblich. Die Mails für die user-crontab werden "normalerweise" an die entsprechenden User gesendet werden.

Gruß
gms

[Pix]

Die Mails für die user-crontab werden "normalerweise" an die entsprechenden User gesendet werden.

Aber doch nur, wenn die Option MAILTO=xxx in der user-crontab gesetzt wurde.
Richtig?

Zur Option MAILTO=xxx habe ich nochmal eine Frage bzw. eine riesen Verständnisproblem.

Wenn ich hinter MAILTO= einen Namen schreibe, geht eine Mail an den Nutzer, der hinter
MAILTO= steht, und zwar in jedem Falle. Das heisst, es ist egal, ob die Kommandos in der
systemwide-crontab oder user-contab erfolgreich abgearbeitet wurden oder auf einen Fehler gestoßen sind.
Der Nutzer bekommt IMMER eine Mail, sofern die Option aktiv ist.
So ist mein Verständnis von MIALTO=xxx

Aber irgendwie funktioniert das bei mir nicht so, wie gedacht.
Ich bekomme nur eine Mail, wenn das Kommando nicht abgearbeitet werden kann, oder auf einen
Fehler stößt. Wird das Kommando erfolgreich bearbeitet erhalte ich keine Mail.

Laut Doku zu cron macht es keinen Unterschied, sofern die Option aktiviert ist, geht immer eine Mail los.

Frage:
Habe ich eine Verständnisproblem, oder woran kann es liegen, dass bei einer erfolgreichen
Bearbeitung des Kommandos der Nutzer keine Mail erhält?

Danke Dirk

[gms]

Die Mails für die user-crontab werden "normalerweise" an die entsprechenden User gesendet werden.

Aber doch nur, wenn die Option MAILTO=xxx in der user-crontab gesetzt wurde.
Richtig?

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.

wenn MAILTO also nicht definiert wurde, sollten die mails an den "Crontab Owner" gesendet werden

Wenn ich hinter MAILTO= einen Namen schreibe, geht eine Mail an den Nutzer, der hinter
MAILTO= steht, und zwar in jedem Falle. Das heisst, es ist egal, ob die Kommandos in der
systemwide-crontab oder user-contab erfolgreich abgearbeitet wurden oder auf einen Fehler gestoßen sind.
Der Nutzer bekommt IMMER eine Mail, sofern die Option aktiv ist.
So ist mein Verständnis von MIALTO=xxx

"erfolgreich" ist ja relativ, daher wurde der Mechanismus auch so implementiert, daß es nicht relevant ist, ob ein Kommando erfolgreich abgearbeitet wurde oder auf einen Fehler gestoßen ist.

Das Kommando muß allerdings einen Output (endweder auf STDOUT oder STDERR) erzeugt haben:

When executing commands, any output is mailed to the owner of the
crontab (or to the user named in the MAILTO environment variable in the
crontab, if such exists).

Gruß
gms

[Pix]

Hallo gms,

irgendwie stehe ich wohl voll auf der Leitung.

... If MAILTO is defined (and non-empty), mail is sent to the user so named.

Wenn die Option MAILTO definiert ist, also das Feld dahinter nicht leer ist, wird eine Mail zu dem Nutzer gesandt, der durch MAILTO benannt wurde.
Also eine Mail unabhängig vom Ergebnis wird auf jeden Fall gesandt.
Diese Option macht Sinn, wenn der Besitzer der crontab eine Mail sich selbst oder einem anderen User zukommen lassen will.

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

Falls MAILTO frei bleibt, wird keine Maill versandt, egal wie das Resultat ist.

Otherwise mail is sent to the owner of the crontab

Ansonsten werden Mails zum Besitzer der crontab geschickt.

An diesem Punkt habe ich wohl Hörner auf dem Kopf. Begreife ich nicht.
Ist MAILTO frei, geht keine Mail los, ist MAILTO definiert, geht eine Mail zum User der durch MAILTO angegeben wird.

Aber genau das funktioniert nicht.
Ich schicke die Mail zu einem anderen Nutzer, also zu einem Nutzer der nicht Besitzer der crontab ist.
Konkret: ich habe die user-crontab als root bearbeitet, aber die Mail geht an einen normalen Nutzer. Ich benutze als Mailprogramm 'mutt' und aus Sicherheitgründen sollte User root keine Mails als root lesen.
Wenn ich also hinter MAILTO=nutzer eingebe, dann muss eine Mail an nutzer gehen, in jedem Fall.

Das funktioniert nur, wenn der Befehl in der crontab nicht abgearbeitet werden kann.
Das heisst, stößt die user-crontab von root auf einen Fehler geht eine Mail an nutzer.
Ist der Befehl erfolgreich, geht keine Mail los.

Warum?

Dirk

[nepos]

Wahrscheinlich, weil dein Befehl bei Erfolg keinerlei Ausgaben auf STDOUT oder STDERR produziert. Dann schickt cron auch keine Mail los. Wenn du willst, dass auch bei Erfolg ne Mail geschickt wird, muesstest du dir da eventuell noch ne Ausgabe einbauen so a la:

Code: Alles auswählen

deinbefehl && echo "Job erfolgreich gelaufen"

Durch das && erreichst du, dass das echo nur dann laeuft, wenn deinbefehl erfolgreich gelaufen ist.

[fuzzy]

[...]
Das funktioniert nur, wenn der Befehl in der crontab nicht abgearbeitet werden kann.
Das heisst, stößt die user-crontab von root auf einen Fehler geht eine Mail an nutzer.
Ist der Befehl erfolgreich, geht keine Mail los.

Warum?

cron ist "so eingestellt", das eine Mail nur bei "fehlern" oder bei einer "scriptausgabe" losgeht.
Aus meiner Sicht müsstest Du dann, wenn Du immer eine Mail haben willst, Dein Script so anpassen, dass es immer eine Ausgabe erzeugt.
...hier zwei Beispiele:

Code: Alles auswählen

fuzzy@sarge:/tmp$ cat /usr/local/bin/test-shellscript
#!/bin/sh -x

  /bin/echo "`/bin/date +%Y-%m-%d`  `/usr/bin/uptime` " >> /tmp/date.txt
  /bin/echo "alles gut"

fuzzy@sarge:/tmp$ /usr/local/bin/test-shellscript
++ /bin/date +%Y-%m-%d
++ /usr/bin/uptime
+ /bin/echo '2006-07-08   11:33:22 up 13 min,  2 users,  load average: 0.00, 0.00, 0.00 '
+ /bin/echo 'alles gut'
alles gut

Code: Alles auswählen

fuzzy@sarge:/tmp$ cat /usr/local/bin/test-shellscript-ohne-output 
#!/bin/sh

  /bin/echo "`/bin/date +%Y-%m-%d`  `/usr/bin/uptime` " >> /tmp/date-ohne-output.txt

fuzzy@sarge:/tmp$ /usr/local/bin/test-shellscript-ohne-output 
fuzzy@sarge:/tmp$

Der Inhalt der Dateien /tmp/date.txt und /tmp/date-ohne-output.txt sieht (zur gleichen Zeit ausgeführt) gleich aus.
Diese beiden Scripte als cron ausgeführt werden regelhaft eine andere Mailausgabe bzw. keine Mailausgabe "ergeben".

Hilft Dir das?

Gruß fuzzy

PS: nepos war deutlich schneller

[Pix]

...cron ist "so eingestellt", das eine Mail nur bei "fehlern" oder bei einer "scriptausgabe" losgeht.

Woher weißt du das, bzw. wo kann ich es nachlesen?

Ich denke, solche wichtige Info's sollten unbedingt in den Manpages stehen.

Hilft Dir das?

Obige Info war 'Gold' wert. Das Thema MAILTO hat mich schon seit Tagen beschäftigt.

Muss ehrlich gestehen, mit Scriptprogrammierung kenne ich mich gar nicht aus.
Also nehme ich dein Script als Anreiz um mal in das Thema reinzuschnuppen.

Vielen Dank euch beiden
Dirk

[fuzzy]

...cron ist "so eingestellt", das eine Mail nur bei "fehlern" oder bei einer "scriptausgabe" losgeht.

Woher weißt du das, bzw. wo kann ich es nachlesen?

Ich denke, solche wichtige Info's sollten unbedingt in den Manpages stehen.
[...]
Also nehme ich dein Script als Anreiz um mal in das Thema reinzuschnuppen.

[quote=""man cron""]
[...]
NOTES
[...]
cron then wakes up every minute, examining all stored crontabs, checking each
command to see if it should be run in the current minute. When executing com-
mands, any output is mailed to the owner of the crontab (or to the user nam
ed in the MAILTO environment variable in the crontab, if such exists). The chil-
dren copies of cron running these processes have their name coerced to upperc
ase, as will be seen in the syslog and ps output.
[...]
[/quote]
[edit]
gms und nepos hatten das entsprechende auch schon genannt/zitiert.
[/edit]

...also, ich will nicht sagen, das es da sofort "einleuchtend" steht, aber es ist in "man cron" enthalten

...also ich würde diese test-shellscripte als user (betreffender user muss das script lesen und ausführen können) mit

Code: Alles auswählen

fuzzy@sarge:/tmp$ crontab -e

aufrufen bzw. einrichten..., nach abspeichern, kann man das Ergebnis so anschauen:

Code: Alles auswählen

fuzzy@sarge:/tmp$ crontab -l 

 */5 * * * * /usr/local/bin/test-shellscript
 */5 * * * * /usr/local/bin/test-shellscript-ohne-output

also in diesem Fall, werden alle 5 Minuten diese Scripte ausgeführt.
Die jeweiligen Ergebnisse kannst Du als "Mails" erhalten, in den /tmp/date* dateien nachsehen und unter /var/log/syslog sollten entsprechend die cron-Einträge auftauchen.

Code: Alles auswählen

grep -i cron /var/log/syslog

Gruß fuzzy