[systemd-devel] systemd lingering users, user sessions and pusleaudio+mpd (was: Re: New release - mpd has stopped working with same user)

[Colin Guthrie]

'Twas brillig, and Arun Raghavan at 20/11/12 03:07 did gyre and gimble:
>> > P.S. - using systemd's logind, if that makes a difference.
> Bluewind from the Arch side was speaking to me on IRC several hours ago,
> and let me summarise our findings.
> 
> 1. mpd is spawned as your "main" user, with XDG_RUNTIME_DIR unset. As a
> result, we use the fallback runtime dir (which is ~/.pulse if it exists,
> or ~/.config/pulse on a new install).
> 
> 2. Your "main" user logs in, XDG_RUNTIME_DIR is set to /run/..., and
> PulseAudio clients try to look for or spawn a server based on that.
> 
> The two possible solutions are for mpd to get the same XDG_RUNTIME_DIR,
> or your user session's PULSE_RUNTIME_PATH be set to the same as what mpd
> uses.
> 
> Now the semantics of XDG_RUNTIME_DIR dictate that it be completely wiped
> out when the user logs out. I am given to understand that the mpd daemon
> does not get a session proper, so your user logging out could cause
> breakage with the first solution (even though it is more correct, in
> some sense, imo).
> 
> That's as far as we got. Perhaps someone with a better understanding of
> the the session stuff can see if mpd can be spawned with its own session
> (which I hope will keep the XDG_RUNTIME_DIR around).


If you're using systemd, then the correct way to get a user session when
not really logged in is with "session lingering". Just calling "loginctl
enable-linger $USER" would work. This should ensure that the runtime dir
is created when user sessions become available
(systemd-user-sessions.service).

Of course, this doesn't actually set the XDG_RUNTIME_DIR for mpd.service
(or whatever your mpd service unit is called).

I'm not sure what the "correct" (aka long term plans) for this are. I'd
guess that it will only really come into it's own when systemd user
sessions are also used in which case I guess a user session daemon
(user@$USER.service) will be automatically started and set to a specific
target ("linger.target"??) when lingering is enabled for a given user.
If that's the case a "regular" user unit, mpd.service, can be
WantedBy=linger.target (rather than graphical.target or whatever). This
is not to be confused with the system mpd.service of course.

Anyway, I've CC'ed the systemd list on this one to get more of a view on
how session lingering is going to work long term.

In the short term, you should hack your *system* mpd.service to have a line:

Environment=XDG_RUNTIME_DIR=/run/user/500

Where 500 is the uid of your user (the path should also be shown as
RuntimePath in "loginctl show-user $USER").



I do feel the correct solution is full lingering support however and the
above is a hack at best.

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/