Rechte Frage?! Systemd-Service liefert nmcli[245510]: Error: failed to set Wi-Fi radio: Not authorized to perform this o

[jh47]

Liebe Forumsmitglieer,

hoffe bin hier mit systemd-Service-Frage in richtiger Schublade des Forums gelandet:
Ich habe eine Frage zu einer systemd-Unit, die ein Script nach einem Wake-Up nach einem Suspend durchführen soll (Debian 12)

Ich nutze ein Script, das ich auch nach Hochfahren des Computers ausführen lasse und das funktioniert dort einwandfrei.

Das Script wird von gnome selbst (?) gestartet, auf jeden Fall liegt eine startup.desktop-Datei unter ~/.config/autostart
und sieht wie folgt aus:

Code: Alles auswählen

[Desktop Entry]
Name=Startup
Comment=Gnome-Terminal mit Tmux mit Taskwarrior starten
Exec=gnome-terminal --maximize -e /home/jan/bin/startup.sh --zoom=1.2 --title Startup
Terminal=false
Type=Application
X-GNOME-Autostart-enabled=true

(Kontextabhängig, etwa je nach verfügbaren WLAN-Netz (z.B. zu Hause, Arbeit, unterwegs) werden dort u.a. Standard-Drucker, Wlan oder Lan-Verbindung gesetzt, eine tmux-Session gestartet usw.)

Nun habe ich die Situation, dass ich etwa zu Hause in Standby gehe, zur Arbeit fahre, Laptop aus Standby aufwecke
und weiterarbeite. Daher wäre es schön, wenn beim Wake-Up aus Standby auch automatisch das Startscript gestartet wird.

Dazu habe ich eine-Service Datei angelegt, die vom Aufbau her auch prinzipiell funktioniert (testweise durchgeführt und z.B. Text in Log-Dateien schreiben lassen). Es gibt
aber offenbar Rechte-Probleme, weil in dem Script nmcli radio wifi on/off - Befehle auftauchen, die zu Fehlermeldungen (und Scriptabbruch?) führen.

Code: Alles auswählen

[Unit]
Description=Test On Resume
After=suspend.target

[Service]
# User=root zum Testen, da hier nmcli-Befehl keine Fehlermeldung generiert, bei User=jan aber schon
User=root
# User=jan
# User=jan scheint notwendig, da wahrscheinlich sonst mit gnome-terminal (als root) grafische Umgebung nicht erreicht wird
Type=oneshot
Environment=DISPLAY=:0
# was eigentlich letztendlich funktionieren soll: 
# ExecStart=/usr/bin/gnome-terminal --maximize -e /home/jan/bin/startup.sh --zoom=1.2 --title Startup
# zum Testen als Minimalbeispiel, da nmcli Fehlermeldungen generiert
ExecStart=/usr/bin/nmcli radio wifi on

[Install]
WantedBy=suspend.target

# WantedBy=suspend.target ist notwendig,
# denn ohne wird das Exec-Script vor Suspend und nicht erst nach Wake-Up ausgeführt

Mittels User=root liefert systemctl start test den fehlerfreien Output

Code: Alles auswählen

Feb 12 15:55:00 t460sjan systemd[1]: Starting test.service - Test On Resume...
Feb 12 15:55:00 t460sjan systemd[1]: test.service: Deactivated successfully.
Feb 12 15:55:00 t460sjan systemd[1]: Finished test.service - Test On Resume.

Umschalten auf User=jan hingegen:

Code: Alles auswählen

Feb 12 15:59:23 t460sjan systemd[1]: Starting test.service - Test On Resume...
Feb 12 15:59:23 t460sjan nmcli[245510]: Error: failed to set Wi-Fi radio: Not authorized to perform this operation
Feb 12 15:59:23 t460sjan systemd[1]: test.service: Main process exited, code=exited, status=1/FAILURE
Feb 12 15:59:23 t460sjan systemd[1]: test.service: Failed with result 'exit-code'.
Feb 12 15:59:23 t460sjan systemd[1]: Failed to start test.service - Test On Resume.

Kurz gesagt habe ich nun folgendes Dilemma: Offenbar brauche ich User=root für nmcli-Befehle, aber User=jan für gnome-terminal Befehl, um Fenster mit/für tmux zu öffnen.
Wie mache ich das richtig (möglichst ohne Aufteilung in mehrere Scripte o.ä., aber gerne mit Anpassungen in startup.sh-Script selbst)?

Der Vollständigkeit halber Auszüge aus startup.sh-Script

Code: Alles auswählen

	# (1) docking-home: Dockingstation und keine Cherry-Tastatur
	if [[ "$(lsusb | grep Dock)" != "" &&  "$(lsusb | grep CHERRY)" = "" ]]
	then
		LOCATION="docking-home"
		nmcli radio wifi off

	# (2) docking-work: docking-station sonst
	elif [ "$(lsusb | grep Dock)" != "" ]
	then
		LOCATION="docking-work"
		nmcli radio wifi on

	...

case "$LOCATION" in 
	docking-home)
	...
	# Tmux, dazu weiteres Script tmuxtw aufrufen mit Einstellungen zu tmux
	gnome-terminal --maximize --zoom=1.2 -e "/home/jan/bin/tmuxtw"

	...

Herzlichen Dank für Hilfe, Hinweise, Tipps jeder Art,
lg jh47

[QT]

Keine Ahnung, was startup.sh noch alles so macht, aber der gezeigte Teil benötigt ja kein gnome-terminal und könnte einfach so als Script laufen lassen.

Ansonsten ist es halt ungeschickt, in 1 Aufgabe (systemd unit) unterschiedliche Berechtigungen zu benötigen. Dann musst Du das anders organisieren. Jedenfalls benötigst Du für WiFi on/off keine gnome-terminal Sitzung mMn.

[jh47]

was ich halt per se nicht verstehe, Skript läuft ja beim Hochfahren unter .config/... mit genau der gleichen Befehls-Aufrufzeile (und natürrlich gleichem Script-Inhalt) offenbar komplett durch. Entweder wirds dort komplett als root ausgeführt oder komplett als user, auf jeden Fall gehts ja und gnome-Terminal-Fenster ist da, und zeigt mir meine tmux-Sitzung an...

... und im terminal kann ich als user (ohne sudo) ja auch den funktionierenden nmcli-Test-Befehl ausführen...
(und ohne gnome-terminal kriege ich meine tmux-Sitzung ja nicht zu sehen..)

nmcli wird im startup-Skript halt auch benutzt, um kontext zu ermitteln, also etwa wenn folgendes wlan-netz sichtbar ist, weiß ich wo ich mich befinde und lege Drucker und anderes fest und öffne eben auch (kontextangepasste) tmux-Sitzung, gehört halt schon alles zusammen, finde ich, auch was Wartung und Übersichtlichkeit angeht...

[QT]

Verwechselst Du "hochfahren" mit "einloggen"? Was soll denn beim Hochfahren unter .config/ ausgeführt werden? Vielleicht wären mal vollständige Angaben sinnvoll. Offensichtlich hat aber der User "jan" nicht das Recht, WiFi ON oder OFF zu schalten, zumindest nicht per nmcli.

Irgendwie steige ich noch nicht bei Deinem Ansinnen genau durch.

Fürs erste würde ich Dir halt empfehlen, das WiFI Interface per NM Gnome Anwendung zu (de)aktivieren. WiFI on/off muss doch gar nicht sein mMn. Aber da komme ich wieder darauf zurück, dass es nicht klar ist, was Du erreichen willst.

dirty hack: Du könntest dem nmcli das SUID Bit setzen (und ausführbahr durch gewisse Gruppe limitieren). Dann läuft es immer als root egal wer es startet. Aber ich schreibe nicht umsonst, dass dieser Ansatz mMn "dirty" wäre. Auch nach jedem nmcli Upgrade könnte es sein, dass die Permissions wieder auf Standard sind und Dein Ansatz wieder nicht ginge, bis Du das SUID Bit wieder gesetzt hast.

[mat6937]

was ich halt per se nicht verstehe, Skript läuft ja beim Hochfahren unter .config/... mit genau der gleichen Befehls-Aufrufzeile (und natürrlich gleichem Script-Inhalt) offenbar komplett durch.

Statt mit einer system-service-unit und User=-Direktive, könntest Du auch mit einer user-service-unit versuchen und den user (mit z. B. "loginctl enable-linger <user>") so konfigurieren, dass die user-service-unit beim Systemstart auch ohne die Anmeldung/Einloggen des users, ausgeführt/gestartet werden kann.
Siehe auch: https://www.freedesktop.org/software/sy ... inctl.html

[TRex]

Code: das Icon </>

macht

[code]...[/code]

[jh47]

erst mal herzlichen Dank für Deine Antwort.

Wenn ich den komplett ausgeschalteten Laptop anschalte, komme ich momentan ohne weitere Benutzer-Interaktion automatisch zu dem Punkt, an dem mir eine kontext-angepasste im gnome-Terminalfenster geöffnete tmux-Session angezeigt wird, das meinte ich.

Das besagte Autostart-Script wird bei diesem gesamten Vorgang ja wahrscheinlich zum Zeitpunkt des (automatischen) Einloggens abgerufen und ausgeführt. Insofern ja, meine ich wohl präziser den Zeitpunkt des Einloggens.

Schalte ich den Laptop zu hause komplett aus (shutdown) und an der Arbeit wieder ein, wird mir an der Arbeit u.a. eine andere tmux-session (auch anderer Standardrucker, netzwerk-verbindung und ähnliches) angezeigt als zuhause. Das macht alles das Autostart-Script (alles nur wenn-dann-konstrukte)

Gleiches will ich auch erreichen (z.B. kontextangepasste im gnome-Terminalfenster geöffnete tmux-Session), wenn ich den Laptop zu hause -- statt auszuschalten -- in Suspend schicke und z.B. auf der Arbeit aus suspend zurückhole. Zwischen Suspend-Beginn und Wake-Up hat sich also u.U. der Kontext geändert. Das soll der Laptop bemerken und darauf adäquat reagieren. Daher der auf suspend.target bezogene Service, der eigentlich nur wieder das Autostart-Skript starten soll, wenn der Laptop aus Suspend zurückgeholt wird -- nur dass es hier mit dem gleichen Aufruf (Exec) des gleichen Skripts zum nmcli-Fehler kommt, wenn user=jan in service-Datei eingestellt ist.

Wenn ich als user eingeloggt bin, führt ein nmcli radio wifi on bzw. off im Terminal (ohne sudo, d.h. ohne Root-Rechte) zum An- und Ausschalten des Wlans. Die Rechte dazu habe ich offenbar...

Wlan soll ja gerade kontextabhängig ein- und ausgeschaltet werden -- und nicht pauschal (z.B. Docking-Station hat LAN-Kabel, also schalte in Docking-Station WLAN bitte aus).

Ist vielleicht einfach der Zeitpunkt (target-Angabe in service-Datei) der Skriptausführung nicht passend, etwa weil während der Rückkehr aus Suspend ein Algorithmus selbst erst mal auf Netzwerk zugreift und damit den Zugriff erst mal sperrt..?

Hoffe ich konnte mich jetzt etwas verständlicher machen...

[QT]

(z.B. Docking-Station hat LAN-Kabel, also schalte in Docking-Station WLAN bitte aus).

Ist das um Strom zu sparen oder warum muss das WLAN ausgeschaltet werden?

[jh47]

kurze Ergänzung: komme auch nach Wake-Up aus Suspend nicht automatisch auf login-Startbildschirm, sondern nur auf aktivierten Screensaver mit login-Abfrage und bin danach "direkt drin". Wenn ich xscreensaver-daemon ausschalte, bin ich nach Rückkehr aus suspend direkt wieder "drin".

Nur falls das für Analyse wichtig ist, etwa weil so vielleicht login-Routine (mit erneuter Durchführung der in .config abgelegten Autostart-Datei) auch nicht erneut angestoßen wird?!...

[QT]

Vielleicht magst Du wirklich mal in #1 die Code Blöcke wie von TRex angedeutet in die </> Code Tags setzen. Lässt sich einfach besser lesen

Ansonsten finde ich es gerade wirklich sehr knifflig, Deine exakte Situation, wann die Fehlermeldung auftritt zu verstehen.

Du kannst per nmcli das radio ein- und ausschalten, sofern Du eingeloggst bist. Nur die Scriptausführung nach Resume aus Suspend wirft den Fehler sofern in der Unit der User "jan" hinterlegt ist?

[jh47]

nein, stromsparen ist ja nicht zentral, es geht mir nur darum mit minimalem Code zu zeigen, dass nmcli zugriffsprobleme macht,
aber was ich kontextabhängig ja wirklich brauche, ist zum Wlan konnekten ist z.B.

nmcli c u 'XXX'

(davon abgesehen muss wlan ja nicht an sein, wenn mans gerade nicht braucht)

[jh47]

@mat6937
Danke für Hinweis, gehe ich morgen mal nach, jetzt ists schon zu spät geworden...

[jh47]

@QT:

zumindest mit Code-Blöcken hat schon mal funktioniert...

noch mal ein Versuch, Ordnung reinzubringen: Die Ausführung eines Skripts funktioniert in einer Situation, in einer anderen aber nicht. Woran liegt das? Etwas ausführlicher:

Die Ausführung eines Skripts funktioniert fehlerfrei, wenn es als Autostart-Eintrag unter ~/.config liegt und dadurch automatisch aufgerufen wird, nachdem der komplett ausgeschaltete Rechner angeschaltet wird, funktioniert aber nicht, wenn es als Service (mit User=jan-Eintrag) im Rahmen des Aufwachens aus Suspend-Status ausgeführt wird. Dann liefert es oben beschriebene Fehlermeldung. Meine Frage ist, warum das so ist und wie das behoben werden kann.

Da die Fehlermeldung sich auf einen im Skript vorkommenden nmcli-Befehl bezieht, könnte ich alternativ auch fragen, warum ein nmcli-Befehl als Service (mit User=jan-Eintrag) oben beschriebene Fehlermeldung liefert, wenn ich als user jan manuell aber im terminal den gleichen nmcli-Befehl absende, es zu keiner Fehlermeldung kommt und der Befehl auch korrekt ausgeführt wird.

[KP97]

Nur mal als Anhaltspunkte/Suchbegriffe:
Alles was in /etc/systemd/system steht, wird als root ausgeführt.
Alles was in /etc/systemd/user steht, wird als user ausgeführt, dort findet man u.a. die Audio Sachen.
Es gibt eine sleep.conf, da mal reinschauen.
Die manpages sind zu systemd sehr ausführlich, unbedingt auch da reinlesen.

Wenn der autostart ausgeführt wird, ist X schon komplett gestartet, was bei den services nicht unbedingt der Fall ist. Evtl. ist das der Grund.

[mat6937]

Wenn der autostart ausgeführt wird, ist X schon komplett gestartet, was bei den services nicht unbedingt der Fall ist. Evtl. ist das der Grund.

Das könnte man evtl. lösen/testen in dem man zum starten der (deaktivierten) (user-)service-unit, eine (user-)timer-unit benutzt.

Code: Alles auswählen

[Timer]
OnActiveSec=15

BTW: Ich muss z. B. den vino-server auch mit einer user-timer-unit (beim booten) starten, weil es mit der (aktiven) user-service-unit (richtigerweise) nicht funktioniert:

Code: Alles auswählen

:~$ systemctl --user cat vino-server.timer
# /home/<user>/.config/systemd/user/vino-server.timer
[Unit]
Description=start vino-server.service

[Timer]
OnActiveSec=30

[Install]
WantedBy=default.target timers.target

[king-crash]

Du könntest die Befehle die du ausführen möchtest in ein extra Skript auslagern, das du über sudo ohne Passwort ausführst.
/etc/sudoers:
"user host = (root) NOPASSWD: /dein/skript"

[michaa7]

Ich habe von all dem kaum Ahnung. Aber von was ich lese scheinen Ursache nicht die user- bzw root Rechte an sich zu sein sondern spezielle Unterschiede des Systemzustandes von resume vs. boot+login. Und ich stelle mir laienhaft die Frage: hat das system nach bzw beim resume nicht bereits sessionhashes o.ä. im RAM mit denen dann das script (insbesondere bei der WIEDERaufnahme) der wifi Verbindung kollidiert, was nicht passieren kann wenn das system frisch hochfährt? Eine Art Henne-Ei Problem?

Dann müßte man vor der Ausführung dieses Scripts erst den gesamten Netzwerkstack auf eine Art löschen, die jegliche diesbezügliche Daten im RAM ungültig macht.

Meine laienhaften 2cts

[mat6937]

Etwas ausführlicher:

Die Ausführung eines Skripts funktioniert fehlerfrei, wenn es als Autostart-Eintrag unter ~/.config liegt und dadurch automatisch aufgerufen wird, nachdem der komplett ausgeschaltete Rechner angeschaltet wird, funktioniert aber nicht, wenn es als Service (mit User=jan-Eintrag) im Rahmen des Aufwachens aus Suspend-Status ausgeführt wird.

Funktioniert das Script wenn es als Service-unit (... nicht mit Autostart-Eintrag unter ~/.config liegt, sondern) nachdem der komplett ausgeschaltete Rechner angeschaltet wird? Oder hast Du mit der service-unit, beim booten noch gar nicht versucht bzw. noch nicht getestet?

[jh47]

bin am Recherchieren in systemd. Mit Service-Unit habe ich es nach Booten noch nicht versucht, das wäre tatsächlich interessant. Danke für Hinweis.
Vorher werde ich jetzt als erstes mal testen, was bei rauskommt, wenn ich service-unit von /etc/... nach ~/.config/systemd/user/ verschiebe und dann berichten...

[mat6937]

Vorher werde ich jetzt als erstes mal testen, was bei rauskommt, wenn ich service-unit von /etc/... nach ~/.config/systemd/user/ verschiebe ...

Das sollte dann aber eine user-service-unit sein, ohne "User=<user>" und das aktivieren wird dann mit:

Code: Alles auswählen

systemctl --user enable <service-unit> 

gemacht. BTW: Evtl. musst Du auch:

Code: Alles auswählen

loginctl enable-linger <user>

benutzen. Die Parent-PID ist dann _nicht_ 1.

[jh47]

das könnte -- Dank Eurer Hinweise auf die Verzeichnisse -- der Durchbruch sein:
wusste nicht dass systemctl (systemweit) und systemctl --user quasi zwei getrennte Schubladen verwaltet,

... also ~/.config/systemd/user/test.service angelegt mit mir (user) als Besitzer:

Code: Alles auswählen

[Service]
Type=oneshot
Environment=DISPLAY=:0
ExecStart=/usr/bin/nmcli radio wifi on

[Install]
WantedBy=suspend.target

systemctl --user start test.service schaltet nun tatsächlich wifi an,
journalctl --user --unit=test --since today zeigt auch keine Fehlermeldung mehr an ...

systemctl --user enable test.service liefert jetzt allerdings Bemerkung

Code: Alles auswählen

Unit /home/jan/.config/systemd/user/test.service is added as a dependency to a non-existent unit suspend.target.

weil suspend.target ja wiederum zu System-Schublade statt User-Schublade gehört , da gibts aber wohl schon (komplexere?) Lösungsvorschläge zu,

https://unix.stackexchange.com/question ... 646#713646,

da werde ich erst mal schauen, ob ich da weiter komme, -- ein einfacher Zweizeiler (man kann ja einfach mal hoffen), der das Problem ganz elegant und einfach löst, ist natürlich jederzeit willkommen...

[jh47]

Funktioniert jetzt, super-herzlichen Dank mal wieder für die Mühe und die Tipps, die zur Lösung geführt haben:

Wie immer eine kurze Zusammenfassung für Leser mit ähnlichen Problemen:

1. Es gibt zwei Instanzen von systemd, die (erst mal, vgl. Punkt 6) nichts miteinander zu tun haben: eine systemweite und eine user-bezogene.
2. Ein Skript, das als Service einer systemweiten Instanz aufgerufen wird, kann offenbar zu Fehlern führen, obwohl es als User etwa im Terminal ausgeführt wunderbar funktioniert
(in meinem Fall das Auftreten eines einfachen nmcli radio wifi off - Befehls).
3. Mit systemd --user Befehlen steuert man die user-bezogene Systemd-Instanz, mit systemd Befehlen (ohne --user) die systemweite systemd Instanz.
4. (Bei mir zumindest) war der Knackpunkt den Service mit User-Recheten unter ~/.config/systemd/user/ abzulegen und mit systemd --user Befehlen zu arbeiten.
5. Das besondere Problem (bei mir), dass nun user-Service auf ein systemweites Target (bei mir Auftreten von Suspend) verweist, ist per se nicht zu lösen, da die Instanzen völlig getrennt voneinander sind und sich nicht "kennen".
6. Punkt 5 kriegt man aber mit dem Trick in den Griff, dass man einen systemweiten Service erstellt, der beim Eintreten eines (systemweiten) Suspend-Targets einen user-spezifischen Suspend-Target aktiviert (zentraler Trick hier: Exec=systemd --user ... => Instanzwechsel) , welcher dann im Rahmen des user-systemd letztlich den user-Service von Punkt 4 aktiviert
sehr schön und klar beschrieben unter https://garajau.com.br/2022/08/systemd- ... user-level

Herzlichen Dank noch mal an alle, hoffe es tauchen bei mir nicht noch Folgefragen auf.