| View previous topic :: View next topic |
| Author |
Message |
Erdie
Advocate
Joined: 20 May 2004
Posts: 2656
Location: Heidelberg - Germany
|
 Posted: Tue May 23, 2023 7:00 pm Post subject: Migration auf Pipewire: Audio stumm nach relogin |
 |
|
Ich habe, wie im vorherigen Thread erläutert, von pulse auf pipewire migriert.
Ich nutze Autologin über sddm, nach dem Reboot funktioniert alles. Log ich mich allerdings aus und dann wieder ein, verschwinden alle Sounddevices.
Da ich sddm habe, habe ich laut Anleitung in ~/.xprofile folgendes eingetragen:
| Code: |
gentoo-pipewire-launcher &
|
Wenn nach dem relogin der Sound weg ist, sagt mir das oben erwähnte Skript, dass es angeblich schon aktiv ist.
Ein Workaround funktioniert:
Wenn ich nach dem manuellen Login "gentoo-pipewire-launcher restart &" ausführe, bekomme ich den Sound wieder zurück. Allerdings wäre es gut wenn man diesen Workaround nicht braucht. Ich habe jetzt den "restart" Befehl in das ~/.xprofile eingetragen statt dem normalen Startbefehl wie im der Anleitung beschrieben. Damit funktioniert es aber das erscheint mir etwas schmutzig. Was können falsch sein an meiner Konfiguration?
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
 |
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Tue May 23, 2023 7:18 pm Post subject: |
|
|
Was für einen WM/DE Nutzt du denn? Und nutzt du OpenRC oder was anderes?
Denn die .xprofile sache wird benötigt wenn man OpenRC nutzt und auch noch ein DE/WM nutzt, welche autostart files nicht respektiert.
Aus der News:
| Quote: | OpenRC users using a minimal desktop which does not respect autostart
files will need to run `gentoo-pipewire-launcher &` in e.g.
`~/.xprofile`. |
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2656
Location: Heidelberg - Germany
|
| Posted: Tue May 23, 2023 7:29 pm Post subject: |
|
|
Ich nutze KDE Plasma mit SDDM und Openrc. Im Zusammenhang mit SDDM steht da ja, dass man das xprofile pflegen muß. Habe ich das falsch verstanden?
Allerdings habe ich den Eintrag erst später gepflegt, d. h. das beschriebene Problem tritt ebenso auf wenn die ~/.xprofile nicht gepflegt ist!
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Last edited by Erdie on Tue May 23, 2023 7:43 pm; edited 1 time in total |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Tue May 23, 2023 7:41 pm Post subject: |
|
|
| Erdie wrote: | Ich nutze KDE Plasma mit SDDM. Im Zusammenhang mit SDDM steht da ja, dass man das xprofile pflegen muß. Habe ich das falsch verstanden?
|
Öhm wo steht das mit SDDM und xprofile? Und auf die andere Frage ob du OpenRC nutzt oder was anders, bist du nicht eingegangen
In der news steht es definitiv nicht.
Ich verwende auch SDDM und KDE Plasma und habe gerade eben den switch gemacht nach folgender Anleitung aus der News (Nur die Parts welche ich ausgeführt habe):
| Quote: | 1. To use PipeWire for sound, users should enable USE=sound-server for PipeWire:
Place the following entries in /etc/portage/package.use:
```
media-video/pipewire sound-server
media-sound/pulseaudio -daemon
```
First, sync:
# emerge --sync
Deselect media-sound/pulseaudio-daemon:
# emerge --deselect media-sound/pulseaudio-daemon
Then perform a world upgrade with PipeWire on the command line to add
it to the world file:
# emerge --ask --update --changed-use --deep @world media-video/pipewire
Then depclean:
# emerge --ask --depclean |
Und da ich systemd statt openrc nutze dann noch folgender Teil:
| Quote: |
systemd users will also need to run the following commands:
$ systemctl --user --now disable pulseaudio.service pulseaudio.socket
$ systemctl --user --now enable pipewire.socket pipewire-pulse.socket
$ systemctl --user --now disable pipewire-media-session.service
$ systemctl --user --force enable wireplumber.service
Root user may replace --user with --global to change system default
configuration for all of the above commands.
|
Wobei ich die systemctl sachen nur für meinen user gemacht habe und nicht global
Und nach einem logout login geht der sound weiterhin
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2656
Location: Heidelberg - Germany
|
| Posted: Tue May 23, 2023 7:49 pm Post subject: |
|
|
Ich nutze Openrc, das hatte ich vergessen und jetzt oben korrigiert.
Die Anleitung aus deinem ersten Quote habe ich genau so befolgt. Den 2 Teil aufgrund von openrc nicht.
In der Pipewire Anleitung: https://wiki.gentoo.org/wiki/PipeWire
steht folgendes
| Quote: |
Display manager environments (SDDM, LightDM, GDM, etc)
Gentoo's PipeWire package installs the /etc/xdg/autostart/pipewire.desktop autostart file. However, not all display managers make use of autostart files. SDDM in particular does not make use of autostart files.
In such environments, start PipeWire via the ~/.xprofile file (creating it if necessary), by adding:
/.xprofile
gentoo-pipewire-launcher &
|
Von daher hatte ich versucht, das dort einzutragen (aber erst nachdem es ohne nicht funktioniert hatte)
Wenn ich den Eintrag auf der ~/.xprofile lösche, ist es so wie ich initital beschrieben habe. Wenn ich dort "gentoo-pipewire-lauchner restart &" eintrage, ist auch Sound nach dem logout/login da. Der pipewire Prozess wird auch tatsächlich erst terminiert bevor er dann gestartet wird. Das kann man sehen wenn man das manuell macht. Es scheint, als ob sich pipewire nach dem logout/login irgendwie aufhängt und dann erst neu gestartet werden muß.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Wed May 24, 2023 5:03 am Post subject: |
|
|
| Erdie wrote: |
Wenn ich den Eintrag auf der ~/.xprofile lösche, ist es so wie ich initital beschrieben habe. Wenn ich dort "gentoo-pipewire-lauchner restart &" eintrage, ist auch Sound nach dem logout/login da. Der pipewire Prozess wird auch tatsächlich erst terminiert bevor er dann gestartet wird. Das kann man sehen wenn man das manuell macht. Es scheint, als ob sich pipewire nach dem logout/login irgendwie aufhängt und dann erst neu gestartet werden muß. |
Ja das war auch meine Vermutung, dass beim einem logout nicht alle pipewire relevanten processe (die via gentoo-pipewire-lauchner gestartet werden) beendet werden.
Die Frage ist betrifft das alle Prozesse (pipewire, wireplumber und pipewire-pulse) oder nur einige.
Kannst du mal folgendes testen.
Nach dem login wenn audio funktioniert einmal die ausgabe von
merken.
Dann ein logout machen und dann in ein andere virtuelle terminals wechseln (z.b. via strg+alt+F2) dort als root anmelden und den obigen befehl nochmal ausführen
Dann sehen wir hoffentlich was hängen bleibt.
Gut möglich, dass die Verwendung .xprofile im zusammenspiel mit kde plasma + sddm nicht so gut funktioniert wie gedacht.
Der Workaround hilft natürlich, weil durch den restart die hängen gebliebenen prozesse vorher beendet werden bevor sie neu gestartet werden.
Um die Vermutung zu prüfen dass .xprofile in deiner situation nicht passt, könntest du folgendes bitte testen?
Den aufruf des launchers aus dem .xprofile entfernen.
Logout/Login
den launcher in einem terminal emulator wie folgt starten und das terminal offen lassen:
| Code: | | gentoo-pipewire-launcher restart & |
Logout und über die verwendung eines virtuellen terminals als root prüfen ob die prozesse noch da sind oder nicht.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2656
Location: Heidelberg - Germany
|
| Posted: Wed May 24, 2023 6:43 am Post subject: |
|
|
Ich habe den Workaround erstmal komplett weggelassen d. h. die xprofile ist leer. Dann kommt folgendes heraus:
After reboot / initial autologin (in diesem Zustand funktioniert der Sound):
| Code: |
martin 4159 0.0 0.0 328164 18448 ? S<l 08:13 0:00 /usr/bin/wireplumber
martin 4165 0.0 0.0 50564 12056 ? S<l 08:13 0:00 /usr/bin/pipewire
martin 4166 0.0 0.0 24196 8440 ? S<l 08:13 0:00 /usr/bin/pipewire -c pipewire-pulse.conf
root 4554 0.0 0.0 6996 2368 tty1 S+ 08:14 0:00 grep --colour=auto wire
|
After logout:
| Code: |
martin 4159 0.0 0.0 326348 17028 ? S<l 08:13 0:00 /usr/bin/wireplumber
martin 4165 0.0 0.0 48600 10456 ? S<l 08:13 0:00 /usr/bin/pipewire
martin 4166 0.0 0.0 24196 8440 ? S<l 08:13 0:00 /usr/bin/pipewire -c pipewire-pulse.conf
root 4686 0.0 0.0 6996 2232 tty1 S+ 08:14 0:00 grep --colour=auto wire
|
After logout / login - restart pipewire ausführen (So ist der Sound wieder da):
| Code: |
martin@kellerkind ~ $ gentoo-pipewire-launcher restart &
[1] 5746
martin@kellerkind ~ $ Terminating PipeWire processes ...
PipeWire terminated.
M 08:20:38.570646 wp-device ../wireplumber-0.4.14/lib/wp/device.c:619:wp_spa_device_new_from_spa_factory: SPA handle 'api.libcamera.enum.manager' could not be loaded; is it installed?
M 08:20:38.570668 script/libcamera libcamera.lua:173:chunk: PipeWire's libcamera SPA missing or broken. libcamera not supported.
W 08:20:38.862449 m-portal-permissio ../wireplumber-0.4.14/modules/module-portal-permissionstore.c:63:wp_portal_permissionstore_plugin_lookup: <WpPortalPermissionStorePlugin:0x563c8ae03540> Failed to call Lookup: GDBus.Error:org.freedesktop.portal.Error.NotFound: No entry for camera
|
After logout "ps aux | grep wire" in root terminal:
| Code: |
martin 5746 0.0 0.0 326348 17080 ? S<l 08:20 0:00 /usr/bin/wireplumber
martin 5750 0.0 0.0 49644 11528 ? S<l 08:20 0:00 /usr/bin/pipewire
martin 5751 0.0 0.0 26612 10720 ? S<l 08:20 0:00 /usr/bin/pipewire -c pipewire-pulse.conf
root 6140 0.0 0.0 7128 2212 tty1 S+ 08:29 0:00 grep --colour=auto wire
|
Wenn ich den xprofile Eintrag dringelassen hätte, würden ja prozesse neu gestartet und man kann nicht mehr erkennen, ob es noch dieselben waren oder nicht. Trägt man das ein, was in der doku steht "gentoo-pipewire-launcher &", beendet sich das Skript und sagt, dass pipewire schon laufen würde. Von daher habe ich alles leer gelassen. Wenn Du es trotzdem sehen willst wenn dort "gentoo-pipewire-launcher restart &" drin stehtl lass es mich wissen. Ich mach das dann nochmal.
Für mich sieht das oben so aus, als ob die Prozesse nach dem logout neu gestartet werden, obwohl gar keine x Session läuft. Das finde ich etwas merkwürdig.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Wed May 24, 2023 7:02 am Post subject: |
|
|
| Erdie wrote: |
After reboot / initial autologin (in diesem Zustand funktioniert der Sound):
| Code: |
martin 4159 0.0 0.0 328164 18448 ? S<l 08:13 0:00 /usr/bin/wireplumber
martin 4165 0.0 0.0 50564 12056 ? S<l 08:13 0:00 /usr/bin/pipewire
martin 4166 0.0 0.0 24196 8440 ? S<l 08:13 0:00 /usr/bin/pipewire -c pipewire-pulse.conf
root 4554 0.0 0.0 6996 2368 tty1 S+ 08:14 0:00 grep --colour=auto wire
|
After logout:
| Code: |
martin 4159 0.0 0.0 326348 17028 ? S<l 08:13 0:00 /usr/bin/wireplumber
martin 4165 0.0 0.0 48600 10456 ? S<l 08:13 0:00 /usr/bin/pipewire
martin 4166 0.0 0.0 24196 8440 ? S<l 08:13 0:00 /usr/bin/pipewire -c pipewire-pulse.conf
root 4686 0.0 0.0 6996 2232 tty1 S+ 08:14 0:00 grep --colour=auto wire
|
Für mich sieht das oben so aus, als ob die Prozesse nach dem logout neu gestartet werden, obwohl gar keine x Session läuft. Das finde ich etwas merkwürdig. |
Nein sie werden nicht neu gestartet sondern sie bleiben beim logout weiter bestehen.
Das sieht man dass die process id (die 2. spalte nach dem usernamen) vor und nach dem logout identisch sind für die 3 prozesse wireplumber, pipewire und pipewire -c pipewire-pulse.conf
pipewire braucht eine dbus session zum funktionieren, vermutlich weil die pulseaudio client api über dbus mit dem deamon kommuniziert.
Durch den logout wird die user dbus session beendet. Wodurch die bestehenden prozesse von pipewire nicht mehr via dbus erreichbar sind.
Nur ein restart der prozesse hilft hier.
Das Problem scheint zu sein, das bei dir kein sauberes management der client/user session läuft, wodurch prozesse leider bei einem logout hängen bleiben obwohl sie terminiert werden müssten. So wie es mit logind unter systemd gemanaged wird.
Nach meinem Verständnis hast du 2 Möglichkeiten (Da du vermutlich nicht auf systemd wechseln möchtest)
1. verwende den workaround mit gentoo-pipewire-launcher restart
2. Verwende elogind als logind ersatz ohne systemd. Zu mindestens laut diesem hinweis https://www.reddit.com/r/Gentoo/comments/12do4m4/comment/jf78cvs/ soll es dann funktionieren
Kompletter reddit thread: https://www.reddit.com/r/Gentoo/comments/12do4m4/gentoopipewirelauncher_with_dwm/
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2656
Location: Heidelberg - Germany
|
| Posted: Wed May 24, 2023 7:48 am Post subject: |
|
|
Danke, ich schau mir diei beiden Alternativen an!
EDIT: Jetzt habe ich mir die elogind Lösung angeschaut und festgestellt, dass bei mir elogind installiert ist und auch über den default runlevel gestartet wird. Theoretisch sollte es demnach funktionieren. Dann muß ich wohl bei dem Workaround bleiben.
Was mir positiv aufgefallen ist, dass pipwire bei der Verwendung von Jack automatisch auf die 2. normalerweise brachliegende Soundkarte zurückgreift sobald jack gestartet wird. Das ist wirklich ein Killer. Da beide Soundkarten über einen Analogmischer auf meine Monitoranalge geroutet werden, funktionieren alle Anwendungen ganz normal weiter als ob nichts wäre. Parallel dazu arbeitet jack mit Ardour ganz wie gewohnt. Bei Pulse war dieser Wechsel auf den alternative Karte nicht automatisch.
Könnte man nicht alternativ dafür sorgen, dass die Prozesse einfach getötet werden während es Logouts? Das wäre doch evtl eine sauberere Lösung.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
Josef.95
Advocate
Joined: 03 Sep 2007
Posts: 4693
Location: Germany
|
| Posted: Wed May 24, 2023 4:40 pm Post subject: |
|
|
| Erdie wrote: | | Könnte man nicht alternativ dafür sorgen, dass die Prozesse einfach getötet werden während es Logouts? Das wäre doch evtl eine sauberere Lösung. |
Ja, bei systemd (mit logind) kann man das zb in der /etc/systemd/logind.conf konfigurieren.
Ungetestet: Schau mal ob das mit elogind auch geht - das müsste dann vermutlich sowas wie
/etc/elogind/elogind.conf sein,
und dort dann mal | Code: | | KillOnlyUsers=martin |
testen.
Damit werden beim Logout dann alle Prozesse des Users martin gekillt.
/edit: Denke dran, vermutlich ist nach dem editieren der elogind.conf ein elogind restart (oder reboot) erforderlich) |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Wed May 24, 2023 5:20 pm Post subject: |
|
|
| Erdie wrote: | Danke, ich schau mir diei beiden Alternativen an!
EDIT: Jetzt habe ich mir die elogind Lösung angeschaut und festgestellt, dass bei mir elogind installiert ist und auch über den default runlevel gestartet wird. Theoretisch sollte es demnach funktionieren. Dann muß ich wohl bei dem Workaround bleiben.
|
Dass es nicht funktioniert könnte daran liegen, dass du eventuell das useflag "elogind" nicht global gesetzt hast?
Dadurch nutzt unter anderem sddm elogind nicht um die user session zu starten.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Wed May 24, 2023 5:23 pm Post subject: |
|
|
| Josef.95 wrote: | | Erdie wrote: | | Könnte man nicht alternativ dafür sorgen, dass die Prozesse einfach getötet werden während es Logouts? Das wäre doch evtl eine sauberere Lösung. |
Ja, bei systemd (mit logind) kann man das zb in der /etc/systemd/logind.conf konfigurieren.
Ungetestet: Schau mal ob das mit elogind auch geht - das müsste dann vermutlich sowas wie
/etc/elogind/elogind.conf sein,
und dort dann mal | Code: | | KillOnlyUsers=martin |
testen.
Damit werden beim Logout dann alle Prozesse des Users martin gekillt.
/edit: Denke dran, vermutlich ist nach dem editieren der elogind.conf ein elogind restart (oder reboot) erforderlich) |
Sollte nicht notwendig sein, da AFAIK logind/elogind das automatisch macht wenn die session terminiert wird.
Wobei dadurch tools wie screen/tmux kaputt gehen da die dann auch terminiert werden wenn sie im kontext der usersession gestartet wurden.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Thu May 25, 2023 3:56 am Post subject: |
|
|
| Erdie wrote: | | EDIT: Jetzt habe ich mir die elogind Lösung angeschaut und festgestellt, dass bei mir elogind installiert ist und auch über den default runlevel gestartet wird. Theoretisch sollte es demnach funktionieren. |
Moment du startest den elogind service im default runlevel?
Laut dem reddit thread, dessen link ich gepostet habe ist das scheinbar falsch.
Laut dem soll nur dbus systemweide im default gestartet werden und der elogind process wird dann via dbus gestartet
| Quote: | | I had the elogind service in boot and didn't have the dbus service anywhere. I disabled elogind and put dbus in default and it seems to be working now. |
Wobei laut der gentoo doku ist die aktivierung des elogind services im boot runlevel besser, wenn es zu problemen kommen sollte, dass die poweroff/reboot befehle des verwendenden DEs nicht funktioniere.
https://wiki.gentoo.org/wiki/Elogind
Aber bei beiden ist es notwendig, dass das elogind useflag zu mindestens für dbus oder besser global gesetzt ist. Denn auch plasma-meta hat das useflag und sorgt dafür dass Abhängigkeiten dann auch mit aktiven elogind support installiert sind.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2656
Location: Heidelberg - Germany
|
| Posted: Thu May 25, 2023 6:19 am Post subject: |
|
|
Der elogind wird im boot runlevel gestartet (sorry meine erste Angabe war nicht korrekt) und das USE=elogind ist global gesetzt.
Aber wenn man das in den Konfiguration von elogind erledigen kann, wäre das schon ein Pluspunkt.. Das werde ich mal probieren.
EDIT:
/etc/elogind/logind.conf:
| Code: |
...
KillOnlyUsers=martin
...
|
hat es gebracht. Danke, das finde ich so viel besser!
Das mit screen/tmux sehe ich nicht so kritisch. Wenn ich die verwende, dann ohnehin nur in einer remote - ssh session und die würden dann ja (hoffentlich) nicht gekillt. Da wäre jetzt noch die interessante Frage warum das nicht automatisch funktioniert, wie du (firefly) es erwähnt hast.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2656
Location: Heidelberg - Germany
|
| Posted: Mon May 29, 2023 6:52 am Post subject: |
|
|
Also ich muß sagen, es läuft wunderbar mit pipewire und ich bin bis jetzt auch sehr zufrieden. Im Prizip ist es genauso wie pulse, allerdings habe ich das Gefühl, dass es eher die Zukunft ist (Gentoo Desktop Strategie bzw. pulseeffects/easyeffects). Ich habe immer die Angewohnheit in "never change a running system" Kategorien zu denken. Manchmal ist es allerdings gut, sich einen Ruck zu geben und was neues auszuprobieren. Wie einfach man mit mehreren Soundkarten umgehen kann ist eine Freude 
Diese Schlusswort wolle ich noch dranhängen und eine frohes Pfingstfest wünschen für den Rest des Tages.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W |
|
| Back to top |
|
|
firefly
Watchman
Joined: 31 Oct 2002
Posts: 5329
|
| Posted: Mon May 29, 2023 7:19 am Post subject: |
|
|
| Erdie wrote: | | Das mit screen/tmux sehe ich nicht so kritisch. Wenn ich die verwende, dann ohnehin nur in einer remote - ssh session und die würden dann ja (hoffentlich) nicht gekillt. Da wäre jetzt noch die interessante Frage warum das nicht automatisch funktioniert, wie du (firefly) es erwähnt hast. |
Möglich das ich da was falsches behauptet habe, dass es generell so ist, dass alle prozesse, welche in einer (e)logind session gestartet werden, beim beenden der session auch terminiert werden.
Ich hab in der docu von logind.conf mal nachgeschaut. Laut dieser ist die Option "KillUserProcesses" bei default "false" und daher nicht aktiv.
Wodurch keine Prozesse automatisch gekillt werden, wenn die login session selbst terminiert wird (z.b. durch ein logout)
Meine Erwartungshaltung ist eher, dass sich die pipewire processe automatisch beenden sollten, wenn die login session (via logind/elogind) beendet wird oder wenn die dbus user sessions beendet wird.
Scheinbar ist der non systemd pfad nicht so gut umgesetzt. Denn unter systemd werden die pipewire processe via systemd user session unit files gestartet/verwaltet welche dann bei einem logout dann auch beendet werden.
Oder es gibt hier ein konfigurationsproblem. Aber das ganze ist pure spekulation.
Hauptsache es funktioniert für dich Erdie.
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn. |
|
| Back to top |
|
|
Josef.95
Advocate
Joined: 03 Sep 2007
Posts: 4693
Location: Germany
|
| Posted: Wed Jun 07, 2023 7:40 pm Post subject: |
|
|
| Nur kurz zur Info - mit der Anpassung aus https://bugs.gentoo.org/907966 sollte es nun wohl auch nach einem relogin funktionieren. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German)
