Autostart von Scripten / Programmen

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • UnderConstruction.jpg
    Under Construction


    Diese Anleitung befindet sich derzeit im Aufbau, daher ist der Inhalt noch unvollständig und ggf. die Struktur etwas durcheinander.


    Automatisches Starten von Scripten / Programmen


    Da hier immer wieder Probleme / Fragen bezüglich des automatischen starten's, sowie das Ausführen von Scripten / Programmen im Hintergrund, auftauchen und der alte Thread leider nicht gepflegt wird, habe ich mich dazu entschlossen hier eine Zusammenfassung zu erstellen sowie weitere Tipps und Hinweise zusammen zu tragen.


    Fragen, Anregungen usw bitte im alten Thread stellen! :danke_ATDE:


    [an=Index][/an]Index:

    • [al=Intro]Einführung[/al]
    • [al=Options]Möglichkeiten[/al]


      • Folgende Möglichkeiten gibt es:
      • [al=crontab]Benutzer-Crontab[/al]
      • [al=crontab]System-Crontab[/al]
      • [al=rcLocal]/etc/rc.local[/al]
      • [al=initd]init- oder auch Runlevel- Script[/al] seit Debian Jessie auch [al=systemd]systemd[/al]
      • [al=bashrc]~/.bashrc und ~/.profile[/al]
      • [al=lxde]LXDE / Desktop[/al]
      • [al=additionals]Sonstige Möglichkeiten[/al]


    [an=Intro][/an]Einführung:

    Als erstes solltet Ihr euch fragen: Wann soll / muss mein Script ausgeführt werden?

    Wenn das Script/Programm beispielsweise eine Grafische Umgebung (wie den Desktop, LXDE) benötigt kann/darf das Script/Programm erst dann ausgeführt werden nachdem der Desktop gestartet wurde. Ist das der Fall müssen also jene Möglichkeiten verwendet werden die explizit für solche Fälle gedacht sind.


    Die nächste Frage wäre: Welche Berechtigungen sind zwingend notwendig?

    Nicht jedes Script/Programm sollte man mit root-Rechten ausführen (ist nur selten notwendig). Das birgt nicht nur ein Sicherheitsrisiko, sondern ist auch entscheidend wenn es darum geht in welchem Verzeichnis das Script/Programm liegt.

    Grundsätzlich ist es so das normale Benutzer nicht auf die Verzeichnisse anderer Benutzer zugreifen dürfen - das wäre nämlich unsicher und uncool. Der "pi" Benutzer sieht also nicht die Dateien in /root/ da er darauf nicht zugreifen kann. root darf allerdings alles, was aber wie gesagt nicht immer Sinnvoll ist, also seht bitte davon ab aus Bequemlichkeit einfach root zu verwenden.


    Wenn man diese zwei Fragen geklärt hat kann man die für sich am besten geeignete [al=Options]Möglichkeit[/al] wählen, wobei oftmals nicht nur eine verwendet werden kann.


    An dieser Stelle auch noch ein Hinweiß wenn ihr etwas, zwar nicht automatisch (bei Systemstart/Reboot) starten lassen aber mit der Konsole weiter arbeiten wollt, das Script/Programm dann also im Hintergrund ausgeführt werden soll:

    Sobald ihr euch anmeldet, egal ob über Netzwerk oder direkt via Tastatur, wird für diese Sitzung ein sog. tty Terminal erzeugt.
    Alle innerhalb dieses Terminals ausgeführten Programme/Scripts werden bei Beendigung/Schließung der Sitzung aber auch wieder beendet/gekillt, indem automatisch ein Signal ' SIGHUB ' an die Prozesse geschickt wird. Die meisten Programme/Scripts reagieren auf dieses Signal und beenden sich dann.
    Für die meisten Scripts/Programme gibt es aber auch hierfür eine [al=Options]Möglichkeit[/al], die ich unter [al=additionals]Sonstige Möglichkeiten[/al] aufzeigen werde.


    = > [al=Index]Index[/al] < =

  • [an=Options][/an]Möglichkeiten:


    [an=crontab][/an]Crontab

    Der Cron-Daemon ist ein Dienst, der automatisch Skripte und Programme zu vorgegebenen Zeiten starten kann. Der auszuführende Befehl wird in einer Tabelle, der "cron tab", gespeichert. Ein Cron-Job kann aber auch für System-Starts eingerichtet werden. Hierfür dient das Schlüsselwort @reboot

    Sollte während der automatisierten Ausführung ein Fehler auftreten, so versucht Cron, diese Fehlermeldung per E-Mail an den Systemadministrator bzw den Benutzer zu schicken. Dies ist allerdings nur möglich, wenn ein sogenannter "Mail Transfer Agent" (kurz MTA) - beispielsweise Postfix - installiert ist.

    Die häufigsten Probleme die mit Crontab auftreten haben mit dem sog. PATH zu tun.
    Gibt man einen Befehl ein sucht Linux in der Umgebungsvariable PATH (in der einzelne Verzeichnisse hinterlegt sind) nach diesem Befehl... Falls sich ein Befehl/Script nicht innerhalb von den $PATH Verzeichnissen befindet kann es auch nicht ausgeführt werden.. Es gibt zudem unterschiedliche PATH Variablen, ein mal die vom Benutzer und dann noch die von Diensten usw.
    Cron benutzt von sich aus nicht die PATH-Variable des Users, sondern PATH="/usr/bin:/bin", sodass man entweder einen anderen PATH definieren oder die benutzten Programme mit vollem / absolutem Pfad aufrufen muss. Es ist also stets zu empfehlen den vollständigen / absoluten Pfad zu einem Script anzugeben.


    Genauere Details zu diesem Thema entnehmt ihr am besten dem separater Thread bezüglich Crontab: FAQ ==> Nützliche Links / Linksammlung ==> crontab / cron jobs


    [an=rcLocal][/an]/etc/rc.local

    Hierbei handelt es sich um ein sh Script was relativ weit am Ende des Bootvorgangs ausgeführt wird. Es gibt hierzu 3 wichtige Dinge zu beachten:

    - Da es sich um ein Script handelt muss es Ausführrechte besitzen. Also am besten nicht überschreiben, dann gibt es auch kein Problem mit dem Dateiformat bzw Zeilenende-Zeichen von Windows...
    - Alle Befehle müssen vor dem "exit 0" stehen. Das "exit 0" muss bestehen bleiben da Linux sonst annimmt das es ein Problem gab.
    - Handelt es sich um ein Script was sich nicht nach Ausführung möglichst bald wieder beendet, muss dies in den Hintergrund geschickt werden damit /etc/rc.local den Bootvorgang nicht blockiert, da sonst gewartet wird bis der Eintrag/Befehl beendet wurde..


    [an=initd][/an]init- oder auch Runlevel- Script bzw systemd

    Befinden sich im Verzeichnis /etc/init.d/ und beruht noch auf dem alten SysVinit, welches aber nach und nach abgelöst und durch systemd ersetzt wird.

    Der Aufbau der Datei ist sehr wichtig:
    - Oben muss der sog. LSB Header stehen in dem Wichtige Informationen definiert werden. Der sieht auf den ersten Block wie unwichtige Kommentare aus, sind es aber nicht! Was dort steht wird ausgelesen, verifiziert und angewendet.
    - Im Script muss auf das Parameter "start" und "stop" reagiert werden, denn damit werden die Scripts aufgerufen.
    - "Exit Code"s signalisieren SysVinit ob das Script erfolgreich oder fehlerhaft ausgeführt wurde, müssen also wie bei /etc/rc.local auch vorhanden sein.

    Seit Debian Jessie wird der Startvorgang von systemd geregelt, was das booten beschleunigt und auch flexibler gestaltet. Hier gilt es zu beachten das die /etc/init.d/ Scripts fast alle erst später ausgeführt werden, auch /etc/rc.local wird ziemlich spät ausgeführt.
    Man kann einen Graphen erzeugen lassen, wie lange das booten gedauert hat aber vor allem wann welcher Dienst/Script gestartet wurde, oder wie lange es den Bootvorgang ausgebremst (dunkelrot) hat:

    Code
    sudo systemd-analyze plot > /tmp/startup.svg

    die dadurch erzeugte *.svg kann man dann mit einem Webbrowser betrachten, entweder über einen Webserver auf dem Pi, oder die Datei auf den eigenen Computer übertragen und via Drag&Drop zB in Firefox.


    [an=bashrc][/an]~/.bashrc und/oder ~/.profile

    " ~/ " ist das Heimatverzeichnis des jeweiligen Benutzers (wird auch in der Umgebungsvariable HOME hinterlegt (echo $HOME)).
    Sofortiger 'Autostart' funktioniert aber nur wenn sich jemand automatisch anmeldet, denn erst dann werden diese Dateien ausgeführt.


    [an=lxde][/an]LXDE / Desktop

    Setzt das Programm X11 bzw eine Grafische / Desktop Oberfläche (GUI) voraus, kann es erst "automatisch gestartet" werden wenn X11 bereits läuft und somit würden Wege über crontab oder /etc/rc.local usw nicht funktionieren, denn die werden viel früher ausgeführt als die Desktop Oberfläche!
    Stell euch LXDE als ein Programm mit vielen Bereichen vor. Wenn das Programm startet werden davon auch noch andere Sachen gestartet. Erst wird ein Window-Manager gestartet, dann wird ein Session-Manager gestartet usw.
    Kurzform: Setzt euer Programm LXDE o.ä. voraus, muss es auch erst dann starten wenn LXDE bereits läuft.


    [an=additionals][/an]Sonstige Möglichkeiten

    Hier möchte ich zu den eher nicht direkt zum "Autostart" gehörigen Möglichkeiten eingehen um Scripte/Programme auch nach dem Logout weiter laufen zu lassen.


    [an=udev][/an]udev

    Eine eher untypische aber dennoch in gewissen Situationen brauchbare Möglichkeit wird auch mit UDEV ermöglicht. Wenn das automatische ausführen eines Scripts von einem bestimmten Gerät abhängig sein soll, dann kann man ein vom Kernel ausgelöstes Event verwenden also zB sobald das Gerät erkannt wurde wird ein Script ausgeführt. UDEV überwacht quasi alle Kernel Meldungen - grob gesagt.

    Man kann Regeln angeben, indem man im Verzeichnis /etc/udev/rules.d/ eine Steuerdatei anlegt. Der numerische Präfix des Dateinamens regelt dabei die Reihenfolge der Abarbeitung der Dateien.

    Beispiel:

    Soll ein Script sofort ausgeführt werden sobald I2C verfügbar ist, legt man zB die Datei /etc/udev/rules.d/51-i2c.rules an und trägt darin die folgende Regel ein:

    Code
    KERNEL="i2cdev*", RUN+="/bin/bash /usr/local/sbin/startI2C.sh"
    #
    # oder (nur eins von beidem!)
    #
    SUBSYSTEM=="i2c-dev", RUN+="/bin/bash /usr/local/sbin/startI2C.sh"


    Damit wird ein bash Script /usr/local/sbin/startI2C.sh ausgeführt.
    In diesem Script tragt ihr dann eine Zeile ein um dein Python Script in den Hintergrund zu schicken, und wichtig ist das am Ende der bash Datei ein "exit 0" vorkommt...

    Code
    /usr/bin/python /path/to/script.py &
    exit 0

    Werft auch mal ein Blick in die Datei /etc/udev/rules.d/99-com.rules


    = > [al=Index]Index[/al] < =

Jetzt mitmachen!

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