Python Programm über Netzwerk starten.

  • Nein, ich meine das steht doch schon richtig in dem Link von Dir aus #42: https://webnist.de/automatisches-…pi-mit-systemd/

    Code
    [Unit]
    Description=beispiel
    After=network.target
     
    [Service]
    ...

    :green_wink:

    //Edit

    Bzw. wobei in dem Fall wohl Requires= statt After= besser geeignet wäre.

  • Kann das sein das ich damit noch weitere Daten mit angeben muss um auch dann auf

    die mariadb zugreifen kann ? network.target ist dann eine datei wo alle pfade beschrieben sind ?

    Code
    [Unit]
    Description=beispiel
    After=network.target


    Ich lese gerade im Demo

    Code
    Hier ist ein Beispiel für eine SQLite3-Datenbankdatei im Unterordner data und eine Fonts-Datei im Unterordner fonds:


    mfg

  • Ich habe das mit einer Flag-Datei und dem Bash-Skript mal grob durchgespielt. Einen Webserver habe ich im Testsystem gerade nicht laufen, aber mit PHP eine Datei erstellen oder löschen ist ja kein Hexenwerk.

    Ok, eine leere Datei /home/hyle/Desktop/flagtest erstellt.

    Eine User Service Unit /home/hyle/.local/share/systemd/user/test.service erstellt. (die Verzeichnisse systemd und user musste ich erstellen)

    und ein Bash-Skript, das alle drei Sekunden nachschaut, ob die Flag-Datei da ist oder nicht und entsprechend die Service Unit startet oder stoppt.

    Durch die Unit wird das Skript auch nicht mehrfach gestartet, aber man könnte das natürlich auch noch abfragen, ob das Skript läuft und darauf reagieren. Das habe ich aber erstmal gelassen.

    Falls das mal jemand einbauen möchte, dann hier ein Schnipsel

    Bash
    SCRIPTNAME="/home/hyle/skripte/von_avi/testtest.py"
    
    PID="$(ps aux | grep -v grep | grep $(basename $SCRIPTNAME) | awk '{print $2}')"
    if [[ ! -z "$PID" ]]; then
      echo "läuft"
    else
      echo "gestoppt"
    fi

    Hier läuft das so.

  • Eine kleine Frage noch, wie muss man es machen um zb. eine text datei auf den Raspberry zu senden

    Hallo,

    Programmieren und Systemadministration ist nicht raten. Wild aus X Videos / Tutorials / Fundstücken im Netz Sachen ohne Verständnis Zusammenkopieren geht schief. Zumal im gegebenen Fall systemd ja ausführlich dokumentiert ist und es auch eine gute, deutschsprachige Anleitung unter https://wiki.ubuntuusers.de/systemd gibt.

    Im Screenshot oben läuft mindestens eine Unit zu viel, nämlich die mit `sudo` in der Befehlszeile. Am besten alle eigenen Unit deaktivieren, löschen und dann neu ansetzen.

    Zu deiner Info: wenn die Direktive `User` in einer Unit nicht drin steht, dann wird die Unit _immer_ immer Root-Rechten ausgeführt. Von daher ist `sudo` in Units grundsätzlich _nie_ notwendig.

    network.target ist dann eine datei wo alle pfade beschrieben sind ?

    Nein, das ist wild geraten und die Aussage ist falsch. `After`, `Require`, `Before` und `Wants` sind Direktiven, die sagen, in welcher Abhängigkeit die eigenen Unit von den in den Direktiven angegeben Units gestartet werden soll. Wenn man z.B. ein Skript hat, dass auf jeden Fall für die Korrekte Funktion eine stehende Netzwerkverbindung braucht, dann nimmt man `After=network-online.target` als Direktive für die eigene Unit. Die Unterschiede zwischen den Direktiven sind in der systemd Doku ausführlich erklärt, ebenso gibt es da eine Erklärung zu den diversen Targets. Letzteres kann man 1x lesen, damit man eine leise Ahnung hat, was da drin steht. Das muss man sich sicherlich aber nicht alles merken.

    Eine kleine Frage noch, wie muss man es machen um zb. eine text datei auf den Raspberry zu senden

    Anderes Thema -> bitte einen eigenen, neuen Thread dafür starten.

    Gruß, noisefloor

  • Ich denke sudo hat gefehlt

    Code
    ExecStart= sudo /home/pi/Desktop/dht_test/myenv/bin/python /home/pi/Desktop/dht_test/dht-datalogger.py
    Code
    ● beispiel.service
         Loaded: loaded (/etc/systemd/system/beispiel.service; enabled; preset: enabled)
         Active: active (running) since Tue 2025-02-04 17:55:46 CET; 7s ago
       Main PID: 2019 (sudo)
          Tasks: 4 (limit: 454)
            CPU: 1.457s
         CGroup: /system.slice/beispiel.service
                 ├─2019 sudo /home/pi/Desktop/dht_test/myenv/bin/python /home/pi/Desktop/dht_test/dht-datalogger.py
                 ├─2020 /home/pi/Desktop/dht_test/myenv/bin/python /home/pi/Desktop/dht_test/dht-datalogger.py
                 └─2021 /home/pi/Desktop/dht_test/myenv/lib/python3.11/site-packages/adafruit_blinka/microcontroller/bcm283x/pulseio/libgpiod_pulsein --pulses 81 --queue 7801 -i gpiochip0 4

    BTW: Wenn Du deine service-unit gestartet hast und dadurch das python-Script aktiv ist, poste die Ausgabe von:

    Code
    ps -fp $(pgrep python) -o ppid,user
    pidof python python3
  • Im Screenshot oben läuft mindestens eine Unit ...

    BTW: Welche parent-PID (PPID) hat der Dienst (die Anwendung) die von einer system-service-unit mit der Direktive "User=<user>", gestartet wird? Ich frage, weil ich keine system-units mit der Direktive "User=<user>" benutze.

  • rpi444: bezüglich PPID - aus dem Kopf (weil ich gerade von meine aktuellen Position keine Zugriff auf den Server habe, wo eine Unit mit `User=USERNAME` läuft): in der Ausgabe von `ps aux` taucht der Prozess ganz "normal" auf, als auf oberster Ebene mit Nutzer und Gruppe USERNAME. Vom Prinzip so, als würdest du das Programm / Skript vom Terminal als Nutzer starten.

    Gruß, noisefloor

  • Vom Prinzip so, als würdest du das Programm / Skript vom Terminal als Nutzer starten.

    OK, d. h. man könnte damit keinen Dienst/Anwendung starten, der z. B. während der Laufzeit auf einem Port < 1024 lauscht und nicht als root läuft? Z. B. per system-service-unit (ohne "User="-Direktive):

    Code
    :~ $ ps -fp 580,623 -o ppid,user
       PPID USER
          1 nobody
          1 irc

    werden per system-service-unit mit root-Rechten gestartet (können auf priv. Ports lauschen) und laufen danach unter nobody und irc.

    vs. user-service-unit:

    Code
    :~ $ ps -fp $(pgrep python) -o ppid,user
       PPID USER
        572 <user>
    Code
    :~ $ ps -fp 572
    UID          PID    PPID  C STIME TTY          TIME CMD
    <user>        572       1  0 Feb04 ?        00:00:02 /lib/systemd/systemd --user

    Das python-Script (mit der parent-PID 572) kann einen priv. Port (oder gleichwertig) nicht benutzen.

    Wi-Fi_Signal_Strength  txpower
    iptables chains order scheme iptables-diagram
    nftables-diagram

    Meine PIs

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

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

    PI4B/8GB Bookworm-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, Mumble-Server, botamusique, ample

    Edited once, last by rpi444 (February 5, 2025 at 11:07 AM).

  • OK, d. h. man könnte damit keinen Dienst/Anwendung starten, der z. B. während der Laufzeit auf einem Port < 1024 lauscht und nicht als root läuft?

    Richtig, die Unit läuft mit den Rechten von USERNAME los und so gestartete Units können den Nutzer nicht wechseln, siehe auch https://www.freedesktop.org/software/syste…exec.html#User= im 1. Abschnitt. Also sowas was z.B. manche Webserver machen, also als root Starten und dann auf www-data runter stufen geht nicht. Es läuft immer als USERNAME mit den entsprechenden Einschränkungen / Sicherheitsregeln.

    Gruß, noisefloor

  • Es läuft immer als USERNAME mit den entsprechenden Einschränkungen / Sicherheitsregeln.

    D. h. der (einzige) Unterschied zwischen einer user-unit und einer system-unit mit "User="-Direktive, ist der Parent-Prozess für den Dienst der mit der unit gestartet wird:

    Code
    <user>        572       1  0 Feb04 ?        00:00:02 /lib/systemd/systemd --user

    vs.

    Code
    root           1       0  0 Feb04 ?        00:00:21 /sbin/init -> /lib/systemd/systemd
  • D. h. der (einzige) Unterschied zwischen einer user-unit und einer system-unit mit "User="-Direktive, ist der Parent-Prozess für den Dienst der mit der unit gestartet wird:

    Nein. Der größere Unterschied ist, dass User-Units gestartet werden, wenn der User, dem die User-Unit gehört, sich einloggt (kann man mit `enable-linger` übersteuern, ist aber ein anderes Thema). Systemweite Units starten halt beim Systemstart. Beim Herunterfahren werden erst User Units gestoppt, dann systemweite Units.

    Die Gemeinsamkeit ist schon, dass die Units per default mit Nutzer gehören, der sie startet. Bei systemweiten Units also Root, bei User-Units der Nutzer, der die Unit angelegt und aktiviert hat. Bei systemweiten Units kann man den Nutzer mit der `User=` Direktive überschreiben. Kein Ahnung, ob das auch bei User-Units geht, habe ich nie probiert. Dürfe aber eigentlich aufgrund des Rechtesystems nicht gehen, weil normalen Nutzer die Rechte fehlen, Programmeals andere Nutzer auszuführen.

    Gruß, noisefloor

  • Eine user-Unit kann vom User ohne sudo etc. administriert werden.

    Genau! Wenn der User in seinem Bereich ohne sudo rumkaspert kann er nicht versehentlich das System(d) zerstören. Auch das systemctl --user daemon-reload ging gestern ziemlich sicher ohne sudo.

  • Nein.

    Da gibt es noch mehr Unterschiede, aber das Alles meinte ich nicht. Mit geht es nur um den Dienst bzw. die Anwendung die via unit (user-unit bzw. system-unit mit user-Direktive) gestartet wird.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!