Cronjob läuft (schon wieder) nicht...

[zoiX]

Vllt. erinnert sich jemand an den alten Thread, vermutlich eher nicht. Darum nochmal das Szenario: Auf dem Linux-Server in meinem Arbeitskreis läuft ein Script (besser: soll ein Script laufen), dass alle 10 Minuten auf einem FTP-Server nach neu abgelegten Dateien sucht und diese sortiert auf dem Arbeitskreis-Server ablegt.

Vorneweg: Das Skript funktioniert soweit, wenn ich es aus der Shell heraus selbst starte und es funktioniert auch unabhängig vom Ausführungsort (beim letzten Mal war eine relative Pfadangabe das Problem, darum hab ich das diesmal gleich getestet ).

Damit dieses Script jetzt alle zehn Minuten läuft, hab ich also

sudo nano crontab -e

bemüht und in die crontab folgendes eingetragen:

*/10 * * * * /home/samba/NMR-Sicherung/NMR_Gans.py &> /home/samba/NMR-Sicherung/Logs/cron.log

Gleich vorweg: Das Script selbst legt die Bildschirmausgabe auch in einem Logfile ab (oder soll es tun), aber weil ich ein solches Logfile nie vorfinde dachte ich, ich leite die Bildschirmausgabe halt auch "händisch" nochmal in ne Datei um.
So...das Ergebnis des ganzen:

/var/log/syslog sagt, der cronjob wird alle 10 Minuten von Root aufgerufen. Soweit gut. /Logs/cron.log wird angelegt. Soweit auch gut. Ein Logfile, dass das Script hätte anlegen müssen find ich nicht. Und /Logs/cron.log ist zwar existent, aber leer. Zu erwähnen, dass auch sonst nichts passiert ist, was das Script hätte tun müssen ist wohl überflüssig.

In meiner Ratlosigkeit hab ich noch ein kleines Script geschrieben. Das sieht so aus:

#!/usr/bin/env python3.3
# coding: utf 8

print('Hallo Welt!')

Auch das hab ich in die crontab eingetragen, auszuführen alle 10 Minuten, Ausgabe in ne Datei. Ergebnis: Die Datei find ich, sie ist aber leer.

Hilfö!

 

[HERR 2FICKENDEHUNDE]

Was für eine Shell ist das?

 

[zoiX]

Erm...ich greif halt via ssh vom Mac an meinem Arbeitsplatz auf den Server zu. Für detailliertere Informationen brauch ich ne Anleitung, wie ich drankomm, wirklich fit bin ich mit Linux halt nicht...

 

[HERR 2FICKENDEHUNDE]

das Umlenkungszeichen &>hat mich irritiert, scheint aber unter BASH zu funktionieren. Was für ein Betriebssystem hat der Server auf dem der job ausgeführt wird?

versuch mal

*/10 * * * * /home/samba/NMR-Sicherung/NMR_Gans.py > /home/samba/NMR-Sicherung/Logs/cron.log 2>&1

 

[Shihatsu]

ps via ssh ausführen. Da kommt dann irgendwo sowas wie bash, csh, zsh oder ähnliches vor -> das ist deine Shell.

 

[zoiX]

ps via ssh ausführen. Da kommt dann irgendwo sowas wie bash, csh, zsh oder ähnliches vor -> das ist deine Shell.

  PID TTY          TIME CMD
 1151 pts/0    00:00:00 bash
 1167 pts/0    00:00:00 ps

bash also, wa?

@2FH: probier ich, berichte dann in 10 Minuten...

 

[HERR 2FICKENDEHUNDE]

Wenn es bash ist sollte deine Variante auch funktionieren, das scheint nicht das Problem zu sein.

Das Shebang #!/usr/bin/env python3.3 sieht noch ungewöhnlich aus für mich. Also bei mir würde da #!/usr/bin/python drinstehen?

€: ah nee, dass scheint auch ok zu sein, wenn man python3.3 benutzt.

 

[zoiX]

Das Problem, das damit gelöst werden sollte ist, dass python programm.py dazu führt, dass der Server programm.py mit Python 2.6 interpretiert. python3.3 programm.py verhindert das. Mein Hallo_Welt.py ist aus der Shell heraus genau so, wie es oben steht auch ausführbar (eben wie das Sicherungsscript auch). Auch Hallo_Welt.py &> Datei.txt legt eine korrekt gefüllt Datei.txt an, wenn ichs aus der Shell ausführe - nur als cronjob funktionieren weder Sicherungsscript noch Hallo_Welt.py...

Ich bin mir ziemlich sicher, dass sich irgendwo ein unfassbar dummer Fehler verbirgt, aber ich seh ihn einfach nicht...

Edit: Mit der Umlenkungsvariante von 2FH steht was in cron.log:

/usr/bin/env: python3.3: No such file or directory

Also ist wohl doch das Shebang das Problem...
Hab das /env mal entfernt, aber:
"#!/usr/bin/python3.3" führt zu "-bash: ./NMR_Gans_final: /usr/bin/python3.3: Defekter Interpreter: Datei oder Verzeichnis nicht gefunden", wenn ich das Programm versuche aus der Shell zu starten - schätze, dann brauch ich gar nicht erst drauf zu hoffen, dass es als cronjob läuft...

 

[HERR 2FICKENDEHUNDE]

Also spontan sehe ich da jetzt keinen Fehler. Cronjobs haben allerdings keine eigenes Environment, also Variablen, die du zb als normaler User automatisch durch .profile oder .bashrc gesetzt hast, zb $PATH, sind nicht gesetzt. Wenn du da noch irgendwelche eigene Variablen geplegt hast, dann sind die ebenfalls nicht aktiv. Dein Hallo Welt Skript sollte aber auf jeden Fall funktionieren.

€: lad ma deine .bashrc voher:

*/10 * * * * . ~/.bashrc; /home/samba/NMR-Sicherung/NMR_Gans.py > /home/samba/NMR-Sicherung/Logs/cron.log 2>&1

 

[Horst Schlemmer]

Also das Script funktioniert, wenn du es von Hand aufrufst, aber nicht, wenn es vom Cron aufgerufen werden soll?
Eventuell das hier mal testen:
http://askubuntu.com/questions/117978/script-doesnt-run-via-crontab-but-works-fine-standalone

 

[zoiX]

Hab den Fehler, 2FH's Umlenkungssyntax, die ja zu 'ner Fehlermeldung geführt hat und die Bemerkung, das Cronjobs kein Environment haben sei Dank. Er konnte den python3.3-Interpreter einfach nicht finden, weil dessen Pfad ne Umgebungsvariable ist, die der Cronjob ja nicht kennt.

Mit dem Shebash #!/usr/bin/env /usr/local/bin/python3.3 funktionierts jetzt.

Danke für die Denkanstöße!