oh oh das hört sich nicht gut an.
Du meinst also es wird noch schwerer??
mfg
oh oh das hört sich nicht gut an.
Du meinst also es wird noch schwerer??
mfg
Python Programm über Netzwerk starten.? Schau mal ob du hier fündig wirst!
Nein, ich meine das steht doch schon richtig in dem Link von Dir aus #42: https://webnist.de/automatisches-…pi-mit-systemd/
//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 ?
Ich lese gerade im Demo
Hier ist ein Beispiel für eine SQLite3-Datenbankdatei im Unterordner data und eine Fonts-Datei im Unterordner fonds:
mfg
ist dann eine datei wo alle pfade beschrieben sind ?
Nein. das ist eine andere schon vorhandene Unit, die das Netzwerk gestartet hat. Finger weg davon!
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)
[Unit]
Description=Test
[Service]
ExecStart=/home/hyle/pythonvenv/bin/python /home/hyle/skripte/von_avi/testtest.py
WorkingDirectory=/home/hyle/pythonvenv
StandardOutput=inherit
StandardError=inherit
Restart=always
[Install]
WantedBy=multi-user.target
Display More
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.
#!/bin/bash
FLAGFILE="/home/hyle/Desktop/flagtest"
UNITNAME="test.service"
while true; do
if [ -e $FLAGFILE ]
then
systemctl --user start $UNITNAME
else
systemctl --user stop $UNITNAME
fi
sleep 3
done
Display More
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
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
CodeExecStart= 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:
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):
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:
:~ $ 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.
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:
vs.
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:
Ein weiterer Unterschied (soweit ich das bisher verstehe) ist:
Eine user-Unit kann vom User ohne sudo etc. administriert werden. Eine system-unit nicht.
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
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.
Hallo,
ach so, jetzt habe ich es auch verstanden... Ja, das ist der Unterschied. Also sonst wüsste ich auch keinen.
Gruß, noisefloor
Don’t have an account yet? Register yourself now and be a part of our community!