[pulseaudio-discuss] Remaining PA process after X logout

[Takashi Iwai]

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.


thanks,

Takashi