cronjob startet nicht

[daskas]

servus,
ich habe das problem, dass die cronjobs, die ich mit

sudo crontab -e

erstelle nicht ausgeführt werden. der eintrag in der crontab lautet dann zb.

*/1 * * * * /Users/<username>/testjames.txt

erstelle ich eine crontab mit

crontab -e

und trage dann den gleichen job wie oben ein, passiert was. ich erhalte minütlich mail vom system. ergo wurde der job wenigstens angestoßen.
warum funzt das mit der sudo crontab dann nicht????
da ich teile des systems backupen will, brauche ich die vollen zugriffsrechte von root.
jemand ideen?
gruz

 

[oneOeight]

-u Specify the name of the user whose crontab is to be tweaked. If
this option is not given, crontab examines "your" crontab, i.e.,
the crontab of the person executing the command. Note that su(1)
can confuse crontab and that if you are running inside of su(1)
you should always use the -u option for safety's sake.

 

[daskas]

@oneOeight
also ich "tweake" schon die root crontab. das ist nicht das problem. ich habe einmal die crontab des users unter /var/cron/tabs/<username> und einmal die von root unter /var/cron/tabs/root mit den gleichen jobs. einmal läufts und einmal nicht.
oder habe ich da was falsch verstanden?
gruz kasp

 

[MacMark]

10.4 bevorzugt launchd anstelle von cron.

 

[daskas]

@macmark
das habe ich auch schon gehört. allerdings eher um die systemeigene wartung auszuführen (daily, weekly usw.) wenn ich mich nicht irre. dass deshalb crontab nicht mehr funzt wäre doch seltsam, insbesondere wenn die usercrontab angestoßen wird......

 

[maceis]

Cron funktioniert aber immer noch.
Gestartet wird cron jedoch von launchd.
Eigentlich sollte launchd Änderungen in /etc/crontab und in /var/cron/tabs bemerken und dann cron starten.

Wenn das nicht klappt, musst Du halt cron von Hand starten oder ein altes StartupItem einsetzen.

HTH

 

[maceis]

Habs gerade mal versucht und die /etc/crontab wie folgt geändert.

# The periodic and atrun jobs have moved to launchd jobs
# See /System/Library/LaunchDaemons
#
# minute    hour    mday    month   wday    who command
*   *   *   *   *   root echo "Hallo" > /dev/ttyp4

Ab der folgenden vollen Minute hatte ich ein "Hallo" auf dem entsprechenden Terminal.
Funktioniert also auf den ersten Blick tadellos.

Auf den zweiten Blick, wirkt sich hier auch der Bug aus, der zur verzögerten Ausführung der zeitgesteuerten "Jobs" durch launchd führt, wenn der Rechner im Ruhezustand war.
Der Bug ist seit 10.4.0 bekannt. Ziemlich erbärmlich, dass Apple das noch nicht gefixt hat.

Lösung: Cron wie unter <10.4 mit Hilfe eines StartupItems starten.

HTH

 

[tomtom42]

Hi daskas,

wie sieht es denn mit den Eigentümer und Berechtigungen für dein
'/Users/<username>/testjames.txt'
aus?
Im Terminal mal ls -al /Users/<username>/testjames.txt eingeben.

Vielleicht hat ja root keine 'execute' rechte ?

Gruß,
Tom

 

[daskas]

servus,
wenn ich mir mit dem tool lingon die jobs ansehe die laufen ist /usr/sbin/cron gestartet. der agent ist com.vix.cron !?

@maceis
dann kann es eigentlich nicht das problem sein, dass der dienst nicht initialisiert ist, oder??
ich vermute irgendein syntax problem in der crontab selbst, habe aber keine schimmer was das sein könnte. benuzte keine userspezifischen variablen im pfad zum auszuführenden skript??
greetz

 

[maceis]

Ach - jetz hab ich noch mal Deinen Eintrag gelesen.
Das Format ist flasch:

# minute    hour    mday    month   wday    who command
     ^       ^       ^      ^        ^       [color=red][b]?[/b][/color]        ^
    */1      *       *      *        *              /Users/<username>/testjames.txt

 

[daskas]

@tomtom42
das habe ich diesmal nicht vergessen ;-) alle gruppen haben das x stehen und können ausführen. aus dem terminal selbst funzt auch alles, bloß aus der crontab nicht.
gruz

 

[daskas]

@maceis
ich dachte der benutzer wäre optional. hatte da aber auch schon "root" eingetragen beim testen. das hat auch nicht geklappt.
jetzt passiert aber gerade was. ich muss mal genau durchdringen was, aber auf jeden fall haben eure tips erstmal weitergeholfen.
gruz

 

[daskas]

so, leider nix neues....
wenn ich eingebe

 crontab -e
*/1 * * * * echo "--- test ---" > /dev/ttyp4

schreibt er mir das terminalfester4 voll, genau wie maceis es gesagt hat.
gebe ich nun

sudo crontab -e
Password:
*/1 * * * * root echo "------testausgabe----" > /dev/ttyp4

ein passiert nüscht.
das ist doch zum verrückt werden.

 

[daskas]

servus,
ich und die konsole :motz kopfkratz

irgendwie hatte sich ein syntaxfehler eingeschlichen. doppeltes blank oder so. beim kompletten neuaufbau des sudo cronjobs war er nicht mehr drin. dank an alle, die mich zum "weiterschrauben" ermutigt haben.
wieder ein schritt weiter pepp

 

[tomtom42]

Hi daskas,

geht jetzt alles oder noch nicht ?

Hab' mich mal schlau gemacht ... das mit dem Usernamen gilt NUR für den system crontab in dem file "/etc/crontab".
Bei ALLEN user-crontab files (auch für user 'root') darf der username nicht erscheinen.

Hier mal ein Beispiel das hier prima funktioniert:
sudo crontab -u root -e

# test crontab for user root
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin
HOME=/var/log
# settings just done ...
* * * * * /bin/date >> /tmp/test.txt;
* * * * * /usr/bin/whoami >> /tmp/test.txt;

Bis dann,
Tom

 

[maceis]

Prima;
jetzt brauchst Du mir nur noch erklären, was Du mit diesem Konstrukt "*/1" bezwecken möchtest .

 

[daskas]

@tomtom42
ja jetzt geht alles. die erkenntnis, dass die usercrontabs nicht mit dem usernamen ausgestattet werden ist mir auch durch probieren und der entsprechenden fehlermeldung gekommen.

sudo crontab -u root -e

scheint redundant zu

sudo crontab -e

zu sein, bzw redundant zu

login: root 
password:
crontab -e

zu sein.

@maceis
tja inkrementelle verringerung des aufruf intervalls von ursprünglich */15, ohne nachzudenken

dabei hätte ich schwören können, dass ich peniebel auf den syntax geachtet habe