Autostart welche Möglichkeiten gibt es?

  • Hallo,


    ich arbeite mich gerade in das Thema Autostart ein. OS ist Buster.


    bisher habe ich folgende Möglichkeiten gefunden, welche für Buster möglich wären.

    1. #init.d

    2. #Systemd

    3. #Cron-job


    Ich finde allerdings kaum etwas über die Vor-Nachteile.

    Welche würdet ihr bevorzugen und warum?

  • 1. und 3. sind Sys V Relikte, die wegen der Rückwärtskompatibilität auch in 2. über Generatoren funktioniert.


    Die Frage ist aber auch, was Du unter Autostart überhaupt verstehst.



    Servus !

    RTFM = Read The Factory Manual, oder so

  • ja und weil Du letztens mit abgespeckter grafischer Oberfläche unterwegs warst, solltest Du auch beschreiben, was Du starten willst und in welcher Umgebung (grafisch oder nicht)

  • Ich würde mich auf so wenig wie möglich beschränken. Also den alten "Kram" zur Kenntnis nehmen, aber eher meiden. Perfekt ist wohl keines der Systeme. Abhängigkeitsprobleme hat man bei jedem. Einfach zu benutzen/verstehen sind die Autostartdatei und die .desktop Dateien. Dann kommt wohl Cron (etwas komplizierter) und vermutlich am schwierigsten systemd (sehr mächtig). Es gibt aber auch Leute die sagen systemd sei "kaputt".

  • daxb wie meinst du kaputt?


    kle ich befolge deinen Rat und mach step by step. erstmal über die Möglichkeiten informieren. Was nehme ich für was, das pro und contra usw. Und dann geh ich erst an die Programme, welche ich starten will. Aber im ersten step werde ich versuchen vom Lite aus einen einfachen Prozess zu starten, dann mal eine *.sh und mich so rantasten.


    fred0815 danke, werde ich alle durchlesen die Links.


    RTFM Autostart sind für mich Prozesse/Dienste, welche beim startup des Systems gleich mitgeladen werden und dann nicht mehr extra estartet werden müssen.


    hyle es geht ja wie kle schon geschrieben erstmal darum, was alles geht und wofür was gut ist.

    • Official Post

    Ok, dann zitiere ich mich mal selbst aus einem anderen Thread (Automatische Programmausführung)

    Kommt eben darauf an, was das Programm machen soll und welche Abhängigkeiten (z.B. Netzwerk) das Programm benötigt.


    Pauschal gesagt und ohne auf Details tiefer einzugehen: Ohne irgendwelche Abhängigkeiten und ohne Ausgabe reicht ein Cronjob. Mit Abhängigkeiten eine Systemd Service Unit. Mit Ausgabe ggf. sogar die .bashrc (wobei das etwas unsauber ist.)


    Bei einem System mit Desktop und einem Programm mit GUI oder Ausgabe im Terminal ist eine *.desktop-Datei die erste Wahl, wobei da auch ein Cronjob funktionieren kann.

  • hyle

    also, damit ich das richtig verstehe, Cronjob für einfache Starts? Meines Wissens hat der sogar den Vorteil, dass er vom Systemstart unabhängig arbeitet. Quasi ein sheduler?

    Systemd, falls Abhängigkeiten sein sollen und init.d gar nicht mehr hernehmen?


    *.desktop ist doch auch systemd oder? die hat ja *.service, *.target,...?

  • llutz OK ja hab grad die links aus #4 durch. Anderer Pfad und alles. Zwar ähnlich wie systemd vom Aufbau her, allerdings ein eigenständiges System.


    Kann man also sagen, systemd für Prozesse/Dienste ohne grafische Oberfläche und bei grafischer Oberfläche *.desktop?

    Cronjob für einfache Starts ohne Abhängigkeiten, bzw. sheduled tasks, welche nicht zwingend an den Bootvorgang gekoppelt sind?

  • Gut, dann vergesse ich mal den init.d und rc.local kram und konzentrier mich auf systemd und danach Cronjob.


    ##Systemd Beispiel.


    sudo nano /etc/systemd/system/baresip.service


    chmod +x baresip.service

    sudo systemctl enable baresip.service



    wäre das so dann die korrekte Vorgehensweise am Beispiel baresip?

  • kle ok, die Anleitung oben wäre ja dann direkt für root ausgelegt. Was ja im Bootvorgang auch nicht nachteilig wäre. Auflisten geht ja auch als user dann.

  • meinst Du den baresip-service?

    2 Fragen

    1.) soll der unter root laufen? Also wenn Du als pi im system bist, rufst Du dann baresip mit sudo auf?

    2.) Du machst den baresip.service executable. Das ist nicht notwendig und auch nicht richtig.

    Executable müssen nur Programme, Shell-Skripte oder Python-Progamme sein, die man direkt mit dem Dateinamen aufruft.


    Services werden z.B. über sudo systemctl <opt> <name> gesteuert.

    <opt> := status | start | stop | restart | enable | disable;

    <name> := "der Name des service (ohne .service)"


    Edit: verwechselte nicht den service und das Programm das im service aufgerufen wird. Letzteres sollte executable sein, ist es sicher auch. Schaue mit ls -l /usr/local/bin/baresip nach.

    Verändere die Rechte von installierten Programmen nicht. Damit gefährdet Du die Sicherheit des Systems.

    Edited 2 times, last by kle ().

  • kle


    das ist meine baresip.service

    in /etc/systemd/system/ startet der Dienst auch, aber ich bekomme keinen Ton. Alsa connection refused.


    in /etc/systemd/user/ startet der Dienst nicht.


    Manuell starte ich ihn über baresip -v Da läuft auch alles einwandfrei.

  • Woher kennst Du baresip -v oder baresip -f /home/pi/.baresip ?

    Kannst Du mir einen Link zur baresip-Doku posten.


    1.) ändere mal den /etc/systemd/system/baresip.service so:

    (Info: pi-Homeverzeichnis setzen und ...)

    2.) nach Änderung: sudo systemctl daemon-reload

    3.) starte baresip mit sudo systemctl start baresip

    4.) schaue nach Fehlern mit:

    • sudo journalctl -u baresip
    • sudo systemctl status baresip

    5.) poste Kommandos mit deren Ausgaben im Codeblock

    6.) poste cat ~/.asoundrc und cat /etc/asound.conf

    Schönen Gruß, kle