Am 06/09/2015 um 10:37 AM schrieb Kyek, Andreas, Vodafone DE:

Schuss ins blaue - ein Skript aus cron hat NICHT das gleiche environment wie der angemeldete User - sicher das dein Skript nicht anläuft und wegen nicht gesetztem environment nicht laufen kann?

War auch gerade mein Verdacht...hab noch ganz oben eine PATH-Zeile eingefügt.... PATH=/sbin:/usr/sbin:/bin:/usr/bin Dann noch ein "logger "läuft"" in mein Script...nichts im Log zu finden. Hab auch vom Script "date" in ne Datei auf /tmp schreiben lassen...die Datei gibts ebenfalls nicht.

Gruß

Daniel

Am 09.06.2015 10:42, schrieb Kyek, Andreas, Vodafone DE:

Daniel Spannbauer wrote:

...

so langsam zweifle ich an mir...ich will eigentlich nur alle 10 min. ein Script anwerfen.

Das Script liegt auf /root/, ist ausfürbar und läuft von der Kommandozeile aus wie es soll.

Ich habe also in /etc/cron.d/ eine Datei "owncloud-sync" angelegt. Diese enthält folgende Zeile: */10 * * * * root /root/owncloud-client

Cron habe ich neu gestartet...aber es passiert nichts. Kein Eintrag in den Logfiles, kein Anlegen von Temp-Dateien....einfach nichts. Auch wenn ich die Zeile direkt in /etc/crontab eintrage....nichts.

Zweite Idee: a crontab file ... must NOT be executable or writable for anyone else but the owner

(aus "man cron")

Andreas

Hi,

1. (wie Andreas schon schrieb): Umgebungsvariablen, insbesondere PATH prüfen.

2. um crontab-Konfigurationsfehler auszuschließen, vielleicht mal

*/10 * * * * root /bin/date >/tmp/test.log

versuchen.

3. Manche Programme brauchen zwingend ein zugeordnetes Terminal, um zu funktionieren - Stdio/err umleiten hilft hier:

*/10 * * * * root /root/owncloud-client </dev/null >/dev/null 2>&1

just my 2ct

cu jth

Am Tue, 09 Jun 2015 12:12:50 +0200 schrieb Markus Heinze max@freecards.de:

Ansonsten schreib ich root Tasks mittels crontab -e dorthin wo sie meines erachtens hingehören ggf. dies mal prüfen

Diese beiden Arten von crontab sollte man trotz ihrer Ähnlichkeit nicht verwechseln. crontab -e und Konsorten ist für user-spezifische cronjobs, die nicht versehentlich irgendwo unter /var abgelegt werden.

System-Jobs sollten hingegen nach /etc/cron* wandern und benötigen auch eine divergierende Syntax, um die UID, unter der sie laufen sollen, zu übergeben. Das ist ja bei den benutzerspezifischen per Anlage festgelegt.

Unter den System-Jobs sind die Jobs unter /etc/cron*/* typischerweise Mitbringsel eines Pakets, wohingegen /etc/crontab eigene, hostspezifische System-Jobs enthält.

Leider gibt es für die System-Jobs kein einfaches Analogon zu crontab -e mit seinem Syntax-Check.

Hallo Daniel,

Am 09.06.2015 um 13:33 schrieb Daniel Spannbauer: [...]

...

Auch wenn ich die Zeile direkt in /etc/crontab eintrage....nichts.

Jemand ne Idee?

Hat sich erledigt...aber fragt mich nicht warum.

Ich hab in meine Datei unter /etc/cron.d wirklich nochmal einen weiteren Eintrag eingefügt: */10 * * * * root /bin/date >/tmp/test.log Cron neu gestartet...geht. Zeile wieder gelöscht...cron neu gestartet...geht.

Möglicherweise hast Du am Zeilenende kein Linefeed gehabt. Durch das hinzufügen einer weiteren Zeile hast Du dann ein Linefeed für den ersten Eintrag.

Ich falle da auch immer mal wieder in diese Fallgrube ...

Manchmal möchte man wirklich.....

Ursache also nicht geklärt, aber es geht.

s.o.

Gruß Manfred