.service startet mein Program nicht !?

L I V E Stammtisch ab 20:30 Uhr im Chat
  • Probier mal folgendes und schau mal nach, ob die Datei /home/pi/.Xauthority auch existiert.

    After und WantedBy sind verändert und Environment ist dazu gekommen.

    Hint: Manchmal ist es hilfreich die Dokumentation zu kennen. Und ja, die Doku ist scheiße ...

    Die Datei /home/pi/.Xauthority existiert !

    Leider funktioniert das auch nicht:

  • Mir ist noch eingefallen, dass ich in raspi-config Boot/Auto Login noch Desktop / CLI and Console Autologin aktiviert hatte.

    Habe nun mal wieder auf Console umgestellt und erhalte jetzt weniger Meldungen. Aber laufen tut es immer noch nicht.

  • Zitat

    Neither a valid executable name nor an absolute path: DISPLAY=/usr/bin/python3

    Das stimmt was nicht.

    Code
    sudo systemctl daemon-reload

    Lädt die Service-Units neu. Erst dann oder nach einem Neustart werden die Änderungen aktiv.

    Die Meldung mit dem Display weist noch darauf hin, dass bei ExecStart irgendwas Komisches drin steht.

    Dort wird eine ausführbare Datei erwartet und das DISPLAY= davor geht so nicht. Das wird nur von der Shell interpretiert, aber nicht von Systemd.

    Deswegen kann man mit Envorinment die Umgebungsvariablen für die Serive-Unit setzen.

    Wenn der xserver läuft, müsste das Programm auch als User laufen können/dürfen.

    In der .service Datei könntest du noch den User in der Sektion Service hinzufügen:

    Code
    [Service]
    User=pi

    Theoretisch sollte der User funktionieren. Aber möglicherweise bricht das Programm aus einem Grund ab, den wir momentan gar nicht sehen. Manchmal gehen Meldungen unter oder werden einfach nicht geloggt.

  • Hallo,

    DennisC: systemd ist grundsätzlich _nicht_ dafrü gemacht / geeignet, Programm zu starten die a) eine grafische Ausgabe (=eine GUI) haben oder b) in irgendeiner Form Interaktion mit dem Nutzer wollen.

    Systemweite systemd Service Units laufen beim Start des Systems - und das ist beide i.d.R. (noch) nicht gegeben. Ja, es gibt "Hacks", um das trotzdem möglich zu machen, aber nichts desto trotz ist der Autostartmechanismus deiner DE der richtige Weg dafür.

    Gruß, noisefloor

  • Hallo,

    DennisC: systemd ist grundsätzlich _nicht_ dafrü gemacht / geeignet, Programm zu starten die a) eine grafische Ausgabe (=eine GUI) haben oder b) in irgendeiner Form Interaktion mit dem Nutzer wollen.

    Systemweite systemd Service Units laufen beim Start des Systems - und das ist beide i.d.R. (noch) nicht gegeben. Ja, es gibt "Hacks", um das trotzdem möglich zu machen, aber nichts desto trotz ist der Autostartmechanismus deiner DE der richtige Weg dafür.

    Gruß, noisefloor

    Was ist eine DE ?

  • Da er das Projekt so normal starten kann, muss er irgendeinen X-Sever laufen haben.

    Es geht auch komplett ohne XServer. Es wird dann OpenGL + SDL2 verwendet.

    Hat auch den Vorteil, dass weniger Speicher und Strom verbraucht wird.

  • Ich habe nun schon einiges gegoogelt und es hat den Anschein als sei das grundsätzlich nicht so einfach ein Pygame Programm in den Autostart zu bekommen.

    Einige scheinen das Problem über den Aufruf eines Service in den Griff bekommen zu haben.

    Wenn ich einen einfachen Service erstelle und diesen ausführe, Startet mein Programm ebenfalls.:

    Code
    #! /bin/sh
    sudo python3 /home/pi/Frontend/main.py

    Versuche ich den Service dann jedoch über einen Cron-Job nach dem Booten zu starten, klappt es auch nicht.

  • Hallo,

    Was ist eine DE ?

    Desktop Environment, also die Desktop-Umgebung.

    Es geht auch komplett ohne XServer. Es wird dann OpenGL + SDL2 verwendet.

    Da bin ich mir nicht ganz sicher. Ja, Pygame setzt auf SDL2, aber bei meiner Schnellrecherche eben konnte ich nicht wirklich schlüssig klären, ob Pygame wirklich keinen Xserver braucht, weil alles direkt in den Framebuffer geht, oder ob das nicht doch anders ist.

    Gruß, noisefloor

  • noisefloor Meine kurze Recherche ergab das hier: https://learn.adafruit.com/pi-video-outpu…the-framebuffer

    Soweit ich das am Telefon erkennen kann, wird da kein X verwendet.

    Ich versteh nicht ganz was die in dem Link treiben.

    "Pointing Pygame to the Framebuffer"

    Was ist der Framebuffer ?

    Um nochmal auf die Variante mit dem Script zurück zu kommen.

    Macht es einen Unterschied ob ich es in einem Cron-Job starte oder über init.d ?

    Einige scheinen Erfolg damit zu haben ein Script über ~/.config/lxsession/LXDE-pi/autostart zu starten.

    Da ich jedoch Raspbian lite benutze habe ich kein LXDE oder sehe ich das falsch ?

    Ist es möglich und macht es sinn LXDE nach zu instalieren ?

    (letztendlich nehme ich ja lite weil ich ein schlankes Betriesystem möchte)

    3 Mal editiert, zuletzt von DennisC (28. April 2021 um 15:28)

    • Offizieller Beitrag

    Über init.d garnicht! ;)

    Ich kann am Telefon nicht so richtig mitarbeiten und bin erst in ca. 2h am PC. Dann würde ich mit Dir erstmal die .bashrc-Variante testen. Dazu wäre aber für den Notfall ein neuer User sinnvoll, der entweder Dein Skript starten oder sich per SSH verbinden kann oder beides.

  • Hallo,

    Soweit ich das am Telefon erkennen kann, wird da kein X verwendet.

    Ja, ABER diese Tutorial ist von 2012. Früher (...) war das auch wohl so, aber ich hatte auch Links gefunden, wo irgendwie implizit draus hervorging, dass neuere Vesion von Pygame (bzw. SDL2) einen laufenden Xserver brauchen - was ja nicht heißt, dass ein DE läuft.

    Zitat

    Was ist der Framebuffer ?

    -> https://de.wikipedia.org/wiki/Framebuffer#Linux-Framebuffer

    Macht es einen Unterschied ob ich es in einem Cron-Job starte oder über init.d ?

    Ja. init.de ist schon länger tot, das verwendet seit systemd keine mehr. Cron ist der "älter" Mechanismus, um Sachen periodisch auszuführen. Aktueller Stand der Dinge sind systemd Timer Units.

    Grundsätzlich ist aber auch Cron _kein_ geeigneter Mechanischmus, um etwas zu starten, was eine grafische Oberfläche hat. Das Grundproblem ist das gleich, was du mit systemd hast.

    Grundsätzlich wäre es für dich sicherlich hilfreich, wenn du dir mal anlegen würdest, was systemd so macht, bzw. wann da was läuft. Z.B. bei http://wiki.ubuntuusers.de/systemd. Was da steht läuft bei allen Linux-Systemen quasi gleich, da ist sehr wenig Ubuntu-spezifisches.

    Des Weiteren wäre es auch mal hilfreich, wenn du hier mal beschrieben würdest, was bei deinem System _genau_ bootet. Also bootet das in eine grafische Oberfläche ja/nein? Wenn ja, welche? Erfolgt ein automatischer Login eines User?

    Gruß, noisefloor

  • Über init.d garnicht! ;)

    Ich kann am Telefon nicht so richtig mitarbeiten und bin erst in ca. 2h am PC. Dann würde ich mit Dir erstmal die .bashrc-Variante testen. Dazu wäre aber für den Notfall ein neuer User sinnvoll, der entweder Dein Skript starten oder sich per SSH verbinden kann oder beides.

    Ich arbeite ausschließlich über SSH von einem PC aus an dem Pi, den HDMI Monitor lasse ich nur nebenbei laufen um das GUI anzuzeigen.

    Ich muss sagen, dass ich noch recht frisch bin was Linux angeht.

    In Python habe ich mich mittlerweile gut eingefunden, aber das hier sind Themen die momentan meinen derzeitigen Horizont sprengen.

    Du brauchst immer einen angemeldeten User. Sonst kann (nach Erreichen des Multiuse Levels) das Ausgabegerät keiner Shell (Programm) zugeordnet werden. Probiere halt einmal #19.

    Servus !

    Soll ich aus der .bashrc direkt ExecStart=/usr/bin/python3 /home/pi/Frontend/main.py aufrufen ?

    Einmal editiert, zuletzt von DennisC (28. April 2021 um 16:12)

  • Ich habe jetzt eine Variante gefunden die Funktioniert.

    Link

    Ich habe den Programmaufruf in /etc/rc.local vor dem exit 0 geschrieben, wie in dem Link vorgeschlagen.

    Auf diese Weise Wird mein GUI gestartet.

    Jetzt sagt Ihr mir nur noch bitte ob das so eine gute Idee ist oder totaler Murks!?

    • Offizieller Beitrag

    Dann sollte das aber auch per Cronjob oder Systemd Service Unit funktionieren. Du hast ja schon ein Shell-Skript (/home/pi/Frontend.sh) erstellt. Das muss dann aber auch ausführbar sein.

    Code
    chmod +x /home/pi/Frontend.sh

    Dieses rufst Du dann per Systemd Service Unit oder mit der Crontab auf.

    Übrigens sollte man das olle rc.local nicht mehr verwenden. Es ist nur eine Frage der Zeit, wann das aus Debian rausfliegt.

    Noch eine Frage: Braucht Dein Programm wirklich unbedingt root-Rechte (sudo)?

  • Dann sollte das aber auch per Cronjob oder Systemd Service Unit funktionieren. Du hast ja schon ein Shell-Skript (/home/pi/Frontend.sh) erstellt. Das muss dann aber auch ausführbar sein.

    Code
    chmod +x /home/pi/Frontend.sh

    Dieses rufst Du dann per Systemd Service Unit oder mit der Crontab auf.

    Übrigens sollte man das olle rc.local nicht mehr verwenden. Es ist nur eine Frage der Zeit, wann das aus Debian rausfliegt.

    Noch eine Frage: Braucht Dein Programm wirklich unbedingt root-Rechte (sudo)?

    Ohne sudo bekomme ich folgende Meldung:

    Python
    pi@raspberry:~$ python3 /home/pi/Frontend/main.py
    pygame 2.0.1 (SDL 2.0.9, Python 3.7.3)
    Hello from the pygame community. https://www.pygame.org/contribute.html
    Traceback (most recent call last):
      File "/home/pi/Frontend/main.py", line 13, in <module>
        from constants import *
      File "/home/pi/Frontend/constants.py", line 16, in <module>
        screen = pygame.display.set_mode((WIDTH, HEIGHT), flags)
    pygame.error: Could not initialize OpenGL / GLES library

    Mit dem Cronjob klappt es nicht. Ich habe, wie in #28 beschrieben, meinen Programmaufruf in crontab -e hinzugefügt.

    Das Shell-Skript habe ich davor mit sudo chmod +x /home/pi/Frontend.shausfürhbar gemacht.

    Was sind den denn die genauen Unterschiede zwischen einem Programmstart mit rc.local und Cronjob

    Möchte ich das Programm über Systemd starten, sind wir ja wieder beim Thema .service.

    Über die Frontend.service lässt sich das Programm gar nicht starten (#1).

    Einmal editiert, zuletzt von DennisC (29. April 2021 um 12:31)

  • Ich habe mich die letzten Tage dann doch noch einmal dran gemacht eine Alternative zu rc.local zu finden.

    Und habe es geschafft mein GUI über openbox zu starten.

    Dafür habe ich folgende Datei erstellt /home/pi/.bash_profile um ein openBox Fenster nach dem Boot zu öffnen:

    Code
    [[ -z $DISPLAY && $XDG_VTNR -eq 1 ]] && startx -- -nocursor

    Und unter /etc/xdg/openbox/autostart dann den Aufruf meines Programmes:

    Da es mir noch etwas an Erfahrung fehlt, blieb mir nichts anderes über als mittels try and error solange zu probieren bis das gewünschte Ergebnis folgt.

    Bin für Verbesserungsvorschläge oder Korrekturen offen :)

Jetzt mitmachen!

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