BTW: Wenn es Probleme mit Abhängigkeiten in der user-unit gibt, evtl. auch mit:
DefaultDependencies=notesten.
Die zugänglichen targets für eine user-unit, kann man auch mit z. B.:
systemctl --user list-units --type=target --allanzeigen lassen.
systemd mein.service startet und beendet sich? Schau mal ob du hier fündig wirst!
Oha, das habe ich in #57 nicht so verstanden.
Mein Fehler! War noch zu früh und ich konnte mich noch nicht richtig artikulieren. 
Hatte den Beitrag aus diesem Grund auch ein paar mal editiert.
Ich habe nun die ursprüngliche Anleitung in #45 aktualisiert und die Unterschiede zwischen Lite- und Desktop-Systemen eingearbeitet.
Bei der ganzen Testerei, insbesondere nun auf meinem frischen Lite-System, bin ich immer wieder darüber gestolpert, dass nachfolgende Tools/Scripte (noch) nicht existierten oder auf Fehler liefen, dies aber in den Logs von journalctl oder bei systemctl status --user ... nicht unbedingt sichtbar wurde.
Es sah oft so aus, als würde die systemd-unit fehlerfrei gestartet, aber ohne sichtbare Erfolge gleich wieder beendet.
Ohne sichtbare Fehlermeldungen ist man nahezu aufgeschmissen.
Also ist es sehr sinnvoll, zuerst die aufgerufenen Programme bzw. deren Parameter usw. sorgfältig zu testen und erst dann in systemd einzubinden.
Das ist zwar eigentlich logisch/klar, aber noch nie wurde mir das so deutlich wie bei diesem "Projekt".
Die zugänglichen targets für eine user-unit, kann man auch mit z. B.:
Codesystemctl --user list-units --type=target --allanzeigen lassen.
Das ist bei mir im Lite-System dann:
$ systemctl --user list-units --type=target --all
UNIT LOAD ACTIVE SUB DESCRIPTION
basic.target loaded active active Basic System
● blockdev@dev-mmcblk0p1.target not-found inactive dead blockdev@dev-mmcblk0p1.target
bluetooth.target loaded inactive dead Bluetooth
default.target loaded active active Main User Target
paths.target loaded active active Paths
shutdown.target loaded inactive dead Shutdown
sockets.target loaded active active Sockets
sound.target loaded inactive dead Sound Card
timers.target loaded active active Timers
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
9 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.Interessanterweise kommt beim ins multi-user.target gebootete Desktop-System dasselbe heraus und trotzdem lässt sich dort WantedBy=multi-user.target erfolgreich verwenden. 
Also gibt es unter der Haube noch weitere Unterschiede zwischen den Systemarten...
Interessanterweise kommt beim ins multi-user.target gebootete Desktop-System dasselbe heraus und trotzdem lässt sich dort WantedBy=multi-user.target erfolgreich verwenden.
In welchen runlevel booten deine Systeme (lite und Desktop)?
who -r
ls -l /lib/systemd/system/runlevel*?
Poste mal bitte von beiden Systemen die Ausgabe von
systemctl get-defaultGruß, noisefloor
Ohne sichtbare Fehlermeldungen ist man nahezu aufgeschmissen
Du kannst im [Service]-Block mal
StandardError=journal
StandardOutput=journaltesten.
//Edit
BTW: Du kannst auch anzeigen lassen ob bzw. welchen runlevel (target) deine service-unit bei der bzw. für die Ausführung, benötigt. Z. B.:
systemctl --user show -p WantedBy werbung.serviceIn welchen runlevel booten deine Systeme (lite und Desktop)?
Codewho -r ls -l /lib/systemd/system/runlevel*
Das Desktop-System ist Bullseye, das Lite Bookworm, ich hoffe, das ist hier nicht von Bedeutung.
Bei beiden Systemen abgesehen vom jeweiligen Datum:
Runlevel 3 2025-05-19 09:21lrwxrwxrwx 1 root root 15 6. Sep 2024 /lib/systemd/system/runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 6. Sep 2024 /lib/systemd/system/runlevel1.target -> rescue.target
lrwxrwxrwx 1 root root 17 6. Sep 2024 /lib/systemd/system/runlevel2.target -> multi-user.target
lrwxrwxrwx 1 root root 17 6. Sep 2024 /lib/systemd/system/runlevel3.target -> multi-user.target
lrwxrwxrwx 1 root root 17 6. Sep 2024 /lib/systemd/system/runlevel4.target -> multi-user.target
lrwxrwxrwx 1 root root 16 6. Sep 2024 /lib/systemd/system/runlevel5.target -> graphical.target
lrwxrwxrwx 1 root root 13 6. Sep 2024 /lib/systemd/system/runlevel6.target -> reboot.target
/lib/systemd/system/runlevel1.target.wants:
insgesamt 0
/lib/systemd/system/runlevel2.target.wants:
insgesamt 0
/lib/systemd/system/runlevel3.target.wants:
insgesamt 0
/lib/systemd/system/runlevel4.target.wants:
insgesamt 0
/lib/systemd/system/runlevel5.target.wants:
insgesamt 0Poste mal bitte von beiden Systemen die Ausgabe von
Codesystemctl get-defaultGruß, noisefloor
Bei beiden:
$ systemctl get-default
multi-user.targetBTW: Du kannst auch anzeigen lassen ob bzw. welchen runlevel (target) deine service-unit bei der bzw. für die Ausführung, benötigt. Z. B.:
Codesystemctl --user show -p WantedBy werbung.service
Bei beiden Systemen
$ systemctl --user show -p WantedBy werbung.service
WantedBy=default.target... obwohl ja im Desktop -System steht:
[Install]
WantedBy=multi-user.targetJa, ich habe gelesen, dass default.target ein Link auf das "echte" aktuelle target ist. Man solle aber explizit das echte target bei WantedBy= angeben.
Genau das ist ja das komische hier: default.target ist ein Verweis auf ein echtes Target, ootb multi-user.target. Dieses Target ist erreicht, wenn das System einsatzbereit ist und sich mehrere Nutzer einloggen könnten. Das multi-user.target ist nicht an ein grafisches System gebunden.
Deswegen ist das ganze hier noch ein bisschen mysteriös, warum wie was wo wann funktioniert (oder eben nicht).
Gruß, noisefloor
Ja, ich habe gelesen, dass default.target ein Link auf das "echte" aktuelle target ist. Man solle aber explizit das echte target bei WantedBy= angeben.
Schau mal auf deinen beiden Systemen (lite und Desktop), für --user und ohne --user nach, mit z. B.:
systemctl --user list-dependencies default.target
systemctl list-dependencies default.target
systemctl --user status default.target # bei loaded
systemctl status default.target # bei loaded
ls -la /usr/lib/systemd/user/default.target
file /usr/lib/systemd/user/default.target
cat /usr/lib/systemd/user/default.target
ls -la /usr/lib/systemd/system/default.targetBTW: Bei deinem Desktop-System (für nicht bzw. ohne --user) sollte das default eigentlich so:
:~$ systemctl get-default
graphical.target, wegen:
:~# ls -la /usr/lib/systemd/system/default.target
lrwxrwxrwx 1 root root 16 Mar 6 15:56 /usr/lib/systemd/system/default.target -> graphical.target(oder gleichwertig) sein.
Das Desktop-System ist Bullseye, das Lite Bookworm, ich hoffe, das ist hier nicht von Bedeutung.
Bei beiden Systemen abgesehen vom jeweiligen Datum:
BashRunlevel 3 2025-05-19 09:21
D. h. Du hast (nur) das Desktop-image installiert und dieses Desktop-System nicht so konfiguriert, dass es auch in den (runlevel5.target ->)graphical.target bootet, oder? Ist das beim TE auch so?
1.) Auf dem Desktop-System boote ich ja zum Testen der Framebuffer-Slideshow nur bis zum multi-user.target per:
$ sudo systemctl set-default multi-userDaher kommt hier korrekt raus:
$ systemctl get-default
multi-user.targetDer system Link zeigt weiterhin auf graphical.target:
$ ls -la /usr/lib/systemd/system/default.target
lrwxrwxrwx 1 root root 16 6. Sep 2024 /usr/lib/systemd/system/default.target -> graphical.targetund beim User ist es default:
$ ls -la /usr/lib/systemd/user/default.target
-rw-r--r-- 1 root root 471 2. Feb 2021 /usr/lib/systemd/user/default.targetAber klar, das in /usr/lib/systemd/ sind ja nur die Defaults!
In den konfigurierten Verzeichnissen /etc/systemd/ ist es dagegen:
$ ls -l /etc/systemd/system/default.target
lrwxrwxrwx 1 root root 37 19. Mai 14:06 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.targetbzw. bei einem bis in den Desktop bootenden Desktop-System
$ ls -l /etc/systemd/system/default.target
lrwxrwxrwx 1 root root 36 19. Mai 14:01 /etc/systemd/system/default.target -> /lib/systemd/system/graphical.target
$ systemctl get-default
graphical.target2.) Beim Lite-System ...
$ systemctl get-default
multi-user.target... sind die Defaults in /usr/lib/systemd/ exakt wie im Desktop-System:
$ ls -la /usr/lib/systemd/system/default.target
lrwxrwxrwx 1 root root 16 Mar 21 12:38 /usr/lib/systemd/system/default.target -> graphical.target$ ls -la /usr/lib/systemd/user/default.target
-rw-r--r-- 1 root root 471 Mar 6 12:43 /usr/lib/systemd/user/default.target... und das Konfigurierte erwartungsgemäß multi-user.target
$ ls -l /etc/systemd/system/default.target
lrwxrwxrwx 1 root root 37 Nov 19 14:40 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.targetDas sieht also alles gut und verständlich aus.
Erklärt aber noch nicht das Verhalten in der user-Unit bzgl. WantedBy=multi-user.target
D. h. Du hast (nur) das Desktop-image installiert und dieses Desktop-System nicht so konfiguriert, dass es auch in den (runlevel5.target ->)graphical.target bootet, oder? Ist das beim TE auch so?
Da (mir) zu Beginn des Threads nicht klar war, dass der TE ein Lite-System nutzt, hatte ich mein Desktop-System halt per
sudo systemctl set-default multi-usernur bis zum multi-user.target booten lassen.
Später habe ich dann parallel auf einem anderen Raspi ein Lite System aufgesetzt, um dem TE besser folgen (und evtl. weiter helfen) zu können.
Erklärt aber noch nicht das Verhalten in der user-Unit bzgl. WantedBy=multi-user.target
Versuch bzw. teste mal mit:
DefaultDependencies=no, in der [Unit]-Section der user-service-unit.
Versuch bzw. teste mal mit:
CodeDefaultDependencies=no, in der [Unit]-Section der user-service-unit.
Das ändert nichts am Verhalten.
Ich denke, hier können wir erst einmal Schluss machen. Mein Ehrgeiz, akademisch noch weiter in die Tiefe zu gehen, ist zumindest gerade erschöpft.
Wenn der TE Bergwichtel sich wieder meldet und noch Probleme haben sollte, schauen wir weiter.
Der will ein Passwort, für das Skript, das den Cursor deaktiviert
Nutze statt
echo 0 > /sys/class/graphics/fbcon/cursor_blinkfolgenden Aufruf:
echo 0 | sudo tee /sys/class/graphics/fbcon/cursor_blinksimonz Entschuldige bitte, das ich erst heute antworte, aber ich lag etliche Tage lang flach.
Noch einmal vielen Dank für Deine Hilfen bei fbi, systemd. Seit gestern schnurrt das System.
echo 0 | sudo tee /sys/class/graphics/fbcon/cursor_blink
Auf die Idee kam ich nicht. Müßte ich ausprobieren. Ich habe das Gefühl, das der Aufruf von sudo schon das Passwort haben will, obwohl in der sudoers der Befehl für ohne Passwortabfrage definiert ist. Was von der Konsole aus auch funktioniert, aber nicht als Systemd-Service.
Deswegen habe ich die Sache anders gemacht. Ich schalte den Cursor in der cmdline.txt mit vt.global_cursor_default=0 aus. Der RPi wird eh nur über ssh bedient.
Don’t have an account yet? Register yourself now and be a part of our community!
