Speicherort der Scripte für zeitgesteuerte Systemaufgaben (cron jobs) @reboot ?

  • Ich versuche gerade, einen SendEmail-Befehl, der im Befehlsfenster funktioniert, bei Neustart (@reboot) ausführen zu lassen.

    Inzwischen habe ich herausgefunden, dass man mit

    [font="Courier, monospace"]sudo apt-get install gnome-schedule[/font]

    eine Cron Gui installieren kann, die eine Aufgabenplanung zulässt.

    Zunächst überrascht mich, dass der Hilfebutton im Dialogfenster von "Zeitgesteuerte Systemaufgaben" nicht funktioniert: "Anzeigen der Hilfe fehlgeschlagen. Fehler beim Ausführen des mit diesem Speicherort verknüpften Befehls der Vorgabeaktion."

    Aber auch mein Script funktioniert dort sogar bei sofortiger Direktausführung (mittels des Papierflieger-Icons) nicht.

    Fragen:
    (a) Funktioniert der Hilfebutton bei Euch auch nicht?
    (b) Kann die Nichtausführung des SendEmail-Befehls daran liegen, dass es vielleicht nicht ausreicht, ausschließlich den SendEmail-Befehl in die Script-Datei zu schreiben? Was muss in die Script-Datei mindestens noch rein?
    (c ) Welche Dateierweiterung muss so eine Script-Datei haben?
    (d) Wo genau sind die Speicherorte für solche Script-Dateien, die bei Neustart (@reboot) ausgeführt werden?

  • Speicherort der Scripte für zeitgesteuerte Systemaufgaben (cron jobs) @reboot ?? Schau mal ob du hier fündig wirst!

    • Offizieller Beitrag

    ne GUI? für Crons? Sorry, aber die brauch niemand und ich glaub du wirst hier auch keinen finden der eine solche nutzt. Ohne dein Script/Befehl zu kennen kann dir keiner helfen. Das Script Kann keine oder jeder dateiendung haben die du willst. Dateiendungen spielen und Linux nur zur Orientierung eine Rolle. Die Script kannst du speichern wo du willst.

  • Zitat von "r123" pid='298575' dateline='1504682848'


    ... Script-Dateien, die bei Neustart (@reboot) ausgeführt werden?

    Da dein Script beim Ausführen Internetzugang braucht, solltest Du testen ob beim Ausführen von @reboot, der Internetzugang von deinem PI aus, immer und zuverlässig vorhanden ist.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    • Offizieller Beitrag

    In so ein Script gehört ein Shebang und es sollte ausführbar sein. In und zum Script absolute Pfade benutzen! Beachte auch, dass direkt nach einem Neustart das Netzwerk noch nicht zur Verfügung steht.

  • Hallo,

    die Verfügbarkeit desNetzwerks kannst du einfach sicherstellen, indem die eine systemd Service Unit statt eines Cron-Jobs nimmst und als Abhängigkeit in der Service Unit das `network.target` angibst.

    Wo die Skriptdateien liegen ist eigentlich egal, so lange die Benutzerrechte des ausführenden zulassen, dass das Skript gelesen werden kann. In der systemd Service Unit oder im Cron-Job musst du dann auch die absoluten Pfade zum Skript angeben.

    Gruß, noisefloor

  • Zitat von "noisefloor" pid='298584' dateline='1504684475'


    die Verfügbarkeit desNetzwerks kannst du einfach sicherstellen, indem die eine systemd Service Unit statt eines Cron-Jobs nimmst und als Abhängigkeit in der Service Unit das `network.target` angibst.

    Mit hoher Wahrscheinlichkeit ist der Internetzugang hier (noch) eher nicht das Hauptproblem.
    Mit dem Hinweis auf die systemd Service Unit befasse ich mich gerne später.
    Jetzt will ich wenigstens überhaupt einen einzigen Cron-Job zum Laufen bringen.
    Am besten einen, der gar kein Internet benötigt.

    Was nimmt man da am besten?

    crontab -e zeigt derzeit folgendes an:

    * * * * * /home/pi/xyprojekt/Email_versenden # JOB_ID_2
    * * * * * dmesg # JOB_ID_3
    * * * * * /home/pi/xyprojekt/dmesg # JOB_ID_4

    Fragen:
    Ist das mit dem /home/pi... so in Ordnung oder nicht?
    Kann der Job mit der JOB ID_3 funktionieren oder nicht?

  • Den Pfad einer installierten Anwendung findest du mittels:

    Code
    which programmname


    dmesg findet sich dann so:

    Code
    which dmesg
    /bin/dmesg


    Das gilt natürlich nicht für selbst geschriebene Scripte.
    Da kannst du nachlegen, dann geht das aber auch.

  • Zitat von "r123" pid='298597' dateline='1504689021'


    crontab -e zeigt derzeit folgendes an:
    * * * * * dmesg # JOB_ID_3


    Fragen:
    Kann der Job mit der JOB ID_3 funktionieren oder nicht?

    Ja, aber du wirst nichts sehen. "dmesg" schreibt seine Ausgaben nach STDOUT (normalerweise ein Terminal), das du im cron-Job nicht hast.
    Wenn Mail für cron eingerichtet ist, bekommst du die Ausgaben per Mail, ansonsten verschwinden sie im Nirvana (bzw in irgendwelchen Logs, je nach setup).

    Den Tipp mit den absoluten Pfaden bekamst du ja schon.

    Der einfachste Test für cron ist (imho):

    Code
    * * * * * /usr/bin/date >>/tmp/crontest.txt


    Der schreibt dir jede Minute aktuelle Zeit/Datum in die Datei. Wenn nicht, ist etwas kaputt.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (6. September 2017 um 11:32)

    • Offizieller Beitrag
    Zitat von "r123" pid='298597' dateline='1504689021'


    Ist das mit dem /home/pi... so in Ordnung oder nicht?

    Nur mit Shebang im Script und wenn dieses ausführbar ist. Und wenn am Ende der Crontab eine Leerzeile ist. ;)

    Infos zu cron findest Du z.B. hier: https://wiki.ubuntuusers.de/Cron

  • Zitat von "llutz" pid='298601' dateline='1504689676'


    Der einfachste Test für cron ist (imho):

    Code
    * * * * * /usr/bin/date >>/tmp/crontest.txt


    Der schreibt dir jede Minute aktuelle Zeit/Datum in die Datei. Wenn nicht, ist etwas kaputt.


    Bei mir findet er den Pfad zu /usr/bin/date nicht.
    Deshalb habe ich Folgendes versucht:
    mv /tmp/Testname /tmp/testname_umbenannt
    Das funktioniert als Einzelbefehl im Ausführungsfenster, aber nicht als Cronjob.

    Als Cronjob führt dies nicht zur Umbenennung, sondern zur Neuerzeugung einer Datei mit dem Namen tmp2gldSM.
    Diese Datei hat folgenden Inhalt:
    echo Press ENTER to continue and close this window.
    read
    exit

  • Danke für den Tipp mit der GUI, werde ich heute abend gleich mal ausprobieren. ;)

    1. Natürlich muss da ein @reboot davor, wenn der Job beim Starten ausgeführt werden soll.
    2. Ausgeführt wird der Job immer im aktuellen Verzeichnis. Muss der Job auf Dateien im eigenen Verzeichnis zugreifen, musst Du vorher dahin wechseln.
    Nicht: @reboot ... /home/pi/meinverzeichnis/meinjob
    Sondern: @reboot ... cd /home/pi/meinverzeichnis && meinjob
    3. Es gibt wie immer unter Linux mindestens 3 Möglichkeiten, wo der cronjob liegen kann. Vorzugsweise hast Du ja den Userjob gewählt. Da musst Du nur schauen, mit welchen Rechten Dein Programm laufen soll.

    Ja, eine Möglichkeit zu sagen, starte das Programm 2 min nach dem Reboot würde ich mir auch wünschen, da der Raspi auch immer erstmal Zeit aktualisieren muss. Das muss man dan wahrscheinlich mit Scripten machen.

  • Zitat von "r123" pid='298610' dateline='1504692521'

    Bei mir findet er den Pfad zu /usr/bin/date nicht.

    Code
    which date

    verrät ihn dir.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (6. September 2017 um 12:16)

    • Offizieller Beitrag
    Zitat von "Timm Thaler" pid='298611' dateline='1504692749'

    Ja, eine Möglichkeit zu sagen, starte das Programm 2 min nach dem Reboot würde ich mir auch wünschen, da der Raspi auch immer erstmal Zeit aktualisieren muss. Das muss man dan wahrscheinlich mit Scripten machen.

    Die gibt es mit @reboot sleep 120; /pfad/zum/script

  • Zitat von "Timm Thaler" pid='298611' dateline='1504692749'


    ...
    Muss der Job auf Dateien im eigenen Verzeichnis zugreifen, musst Du vorher dahin wechseln.
    Nicht: @reboot ... /home/pi/meinverzeichnis/meinjob
    Sondern: @reboot ... cd /home/pi/meinverzeichnis && meinjob
    ...


    Mit Verlaub, das ist (so) Unsinn.
    Das Wechseln in das Programmverzeichnis (korrektes setzen von $PWD) ist nur dann notwendig, wenn die dort liegenden Programme/Scripte fälschlicherweise relative Pfade (relativ zu $PWD) benutzen. Das sollte man ohnehin vermeiden.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (6. September 2017 um 12:48)

  • Zitat von "Timm Thaler" pid='298617' dateline='1504695322'


    Naja, mir sind unter Linux schon so viele Varianten von "das macht man aber so" und "das macht man aber ganz anders" untergekommen, dass ich mit Aussagen wie "das sollte man ohnehin vermeiden" vorsichtig wäre.


    Ich sage auch nicht, dass es nicht gemacht wird. Ich sage "wer das macht ist doof" :)

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (6. September 2017 um 12:59)

  • Ich mache das so, wenn ich die Config-Dateien für meine Programme ablege. In den Configs steht dann, wo das Programm die Pfade zu anderen Dateien findet. Gern auch als absolute Pfade. Aber erstmal muss es ja selbst die Config finden.

    Und die Unart, die Configs als versteckte Dateien oder in versteckten Ordnern ins Home des Users zu klatschen, wahlweise auch irgendwo anders unter etc... finde ich unmöglich.

  • Die "Unart" ist historisch gewachsen, gilt als best-practise und funktioniert sehr gut.
    Systemweite Configs nach /etc/, User-Configs im $HOME, neuerdings in $HOME/.config (XDG_basedir). Da weiß man wo man suchen muss.

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (6. September 2017 um 13:43)

  • Zitat von "hyle" pid='298613' dateline='1504693244'


    Die gibt es mit @reboot sleep 120; /pfad/zum/script


    Danke! Mit Euren Hinweisen habe ich es nun zum Laufen gekriegt und dabei Folgendes herausgefunden, was mir bisher nicht klar war:
    (a) Der Pfad /home/pi/xyprojekt/... ist absolut genug.
    (b) Einträge in crontab können, aber müssen keine Script-Dateien sein.
    (c ) Wenn eine Script-Datei verwendet wird:
    - Pure Nennung ihres Pfades führt die Script-Datei schon aus.
    - Shebang in Script-Datei für crontab nicht erforderlich (Shebang ändert aber das Datei-Icon in eins mit Zahnrad).
    (d) Durch Verwenden des Semicolons lassen sich ein kleines Script auch ohne Script-Datei als Cron-Job definieren (Beispiel: @reboot sleep 12s; SendEmail ....)
    (e) Internetzugang steht hier etwa 9s nach Erstausführung des Cron-Jobs.
    (f) SendEmail funktioniert nicht so ohne Weiteres mit Umlauten im Betreff.

    Einmal editiert, zuletzt von r123 (6. September 2017 um 15:39)

  • Zitat von "r123" pid='298633' dateline='1504705103'


    (c ) Wenn eine Script-Datei verwendet wird:
    - Pure Nennung ihres Pfades führt die Script-Datei schon aus.
    - Shebang in Script-Datei für crontab nicht erforderlich (Shebang ändert aber das Datei-Icon in eins mit Zahnrad).

    Ohne Shebang wird das Script von der system-shell (/bin/sh, meist Link auf /bin/dash) ausgeführt. Wenn dein Script damit läuft, stimmt obiges. Würdest du so ein Script starten, welches z.B. bash-spezifische Anweisungen (oder python, ruby, sonstwas) enthält, klapt das nicht mehr. Deswegen ist es immer ratsam einen gültigen Shebang in Scripten zu haben.

    Wenn du nichts zu sagen hast, sag einfach nichts.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!