On Wed, 2018-02-28 at 14:53 +0100, Takashi Iwai wrote: > On Mon, 26 Feb 2018 12:20:03 +0100, > Takashi Iwai wrote: > > > > On Mon, 26 Feb 2018 12:06:50 +0100, > > Tanu Kaskinen wrote: > > > > > > On Mon, 2018-02-26 at 10:56 +0100, Takashi Iwai wrote: > > > > On Mon, 26 Feb 2018 10:47:09 +0100, > > > > Tanu Kaskinen wrote: > > > > > > > > > > On Mon, 2018-02-26 at 10:20 +0100, Takashi Iwai wrote: > > > > > > On Mon, 26 Feb 2018 10:12:44 +0100, > > > > > > Tanu Kaskinen wrote: > > > > > > > What about fedora? I somehow would expect fedora to be eager to adopt > > > > > > > the socket activation feature in pulseaudio that has been available for > > > > > > > a long time already. > > > > > > > > > > > > > > If you're using pulseaudio under systemd, it seems weird if all user > > > > > > > services don't get terminated on logout. > > > > > > > > > > > > I guess they would hit the same issue. But maybe there can be some > > > > > > workaround. > > > > > > > > > > I don't think the same issue would affect pulseaudio if it was under > > > > > systemd control, unless the user instance of systemd keeps running for > > > > > longer than logind keeps the runtime dir around. I'd be very surprised > > > > > if that was the case. I had a look at systemd documentation, which > > > > > confirmed to me that when the user instance of systemd shuts down, it > > > > > will stop all services that haven't explicitly requested not to be > > > > > stopped. > > > > > > > > The man page of logind.conf seems wrong. The default value of > > > > KillUserProcesses is "no" in the recent versions, judging from the > > > > configure.ac; i.e. systemd doesn't behave aggressively to kill user > > > > processes at logout. > > > > > > > > Maybe this setup can be the difference between distros? > > > > > > The default value of KillUserProcesses can indeed cause differences > > > between distros, because it was changed to "yes" a couple of years ago. > > > I suppose you have an older version, since configure.ac doesn't exist > > > any more (systemd uses meson as the build system nowadays). Also, some > > > distros may have reverted the default back to "no" due to problems that > > > KillUserProcesses can cause. > > > > Yes, that's a plausible explanation of the differences. > > ... and now I double-checked the behavior on openSUSE Tumbleweed, with > the latest components. By some reason, systemd doesn't kill PA no > matter whether KillUserProcesses is set or not. This is being > tracked. Meanwhile... > > > > However, I'm not talking about KillUserProcesses in the quoted > > > paragraph. I'm talking about the situation where there is a user > > > instance of systemd running and managing pulseaudio. Pulseaudio ships > > > .service and .socket files for systemd, which suse apparently doesn't > > > use. If suse were to use those, then the user instance of systemd would > > > manage the lifecycle of the pulseaudio daemon, and when the user > > > instance of systemd shuts down on logout, it should stop all services > > > it's managing (but not anything that it isn't managing). Logind's > > > KillUserProcesses is a different thing, and it should enter the picture > > > only if there's still something from the session running after systemd > > > has shut down. > > > > Ah good point. I checked the openSUSE Tumbleweed, the latest rolling > > release, and indeed it's using already the systemd stuff for starting > > up. It means that the issue is seen only with the older versions. > > .... my statement here was incorrect. The startup of PA wasn't > changed with the latest package on openSUSE Tumbleweed, and it means > that it's either started by XDG autostart (by pacmd), or autospawn by > any program. > > And once when PA gets started by either of these, the problem > appears: PA process remains after X session logout. If PA is started > via systemd user service, it exits properly at X logout. I could > confirm the issue on XFCE, too. > > That is, the current situation doesn't look good. In the bugzilla, > systemd guys suggested the quote from pam_systemd man page: > > ENVIRONMENT > $XDG_RUNTIME_DIR > .... If a user logs in once, then logs out again, and logs > in again, the directory contents will have been lost in > between, but applications should not rely on this behavior > and must be able to deal with stale files. .... > > So in pam_systemd POV, it is expected that PA won't fail even if it's > restarted after the removal of $XDG_RUNTIME_DIR. I wouldn't interpret the man page that way. The man page seems to be saying that if pam_systemd *doesn't* remove $XDG_RUNTIME_DIR, then pulseaudio is expected to handle the situation where there is some old garbage in the runtime dir. Anyway, are you willing to switch to systemd-managed pulseaudio in suse? That seems to solve the problem. (Note that in that case you should also disable autospawning to avoid confusing situations if the user stops pulseaudio via systemd.) I wouldn't be opposed to an alternative solution either: module- console-kit, module-systemd-login and module-x11-xsmp could set exit- idle-time to 0 when the first session is detected. I think non-zero exit-idle-time is only useful when we have no means to do session tracking. -- Tanu https://liberapay.com/tanuk https://www.patreon.com/tanuk
