Bug 48226 - Move cookie file to XDG_CONFIG_HOME and sockets to XDG_RUNTIME_DIR
Move cookie file to XDG_CONFIG_HOME and sockets to XDG_RUNTIME_DIR
Status: RESOLVED FIXED
Product: PulseAudio
Classification: Unclassified
Component: core
unspecified
Other All
: medium normal
Assigned To: pulseaudio-bugs
pulseaudio-bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-02 23:19 UTC by Arun Raghavan
Modified: 2012-05-15 15:07 UTC (History)
3 users (show)

See Also:


Attachments
sockets in XDG_RUNTIME_DIR - the simple implementation (794 bytes, patch)
2012-04-11 15:15 UTC, Bill Nottingham
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Arun Raghavan 2012-04-02 23:19:08 UTC
We should use XDG_RUNTIME_DIR for our cookie files since it's the Right Way™ to do things, and allows people on things like NFS mounts for home directories to globally move all such transient data off NFS.
Comment 1 Colin Guthrie 2012-04-03 02:13:52 UTC
Why would the cookie be in the runtime dir?

The cookie is meant to be long lasting, e.g. we don't regenerate it on boot and it can be copied around.

The runtime dir should be used for sockets and such like.

If we do have a "cookie in runtime dir" approach we should copied it the first time if it doesn't exist, but that in itself may result in the same locking problems... should only happen once per boot, but then what is you update you're ~/.pulse-cookie and a client starts... should it compare timestamps etc?

I'm not sure this is correct.

But we certainly DO want to support the runtime dir generally. We have to be careful however, as on non-systemd systems, the fallback value for XDG_RUNTIME_DIR set by gnome did NOT consider NFS and actually used the XDG_CACHE_HOME which could easily reside on an NFS share. We should certainly NOT create our sockets on an NFS share.

cf http://pulseaudio.org/ticket/928 (specifically http://pulseaudio.org/ticket/928#comment:8)
Comment 2 Colin Guthrie 2012-04-03 02:18:38 UTC
/me can't form proper sentences today it seems (nothing new there!)

Random thought: we can maybe keep it in the runtime dir by default (and thus regenerate it every boot), but if a user creates a ~/.pulse-cookie we should honour it. We can probably avoid locking it in this setup which should be more friendly to NFS... just an idea.
Comment 3 Colin Guthrie 2012-04-03 02:24:47 UTC
Sorry for the spam...

I've realised my concern about updating ~/.pulse-cookie in a copying it about context is unfounded... the same issue already exists with the X11 publication (PULSE_COOKIE X11 root window property).

So I guess I'd support the following order for searching for the cookie to use: env var, x11 prop, home dir, runtime dir, and if none found, generate one in runtime dir.

It does still require a stat on $HOME, but that should be more lock friendly overall.
Comment 4 Lennart Poettering 2012-04-03 03:36:56 UTC
The cookie should stay in $HOME, but the sockets should move to XDG_RUNTIME_DIR.
Comment 5 Arun Raghavan 2012-04-03 04:02:18 UTC
Okay, I misunderstood how the cookie works, and since the original reporter found the locking issue to be portmap/lockd related, I guess this becomes irrelevant (other than moving the sockets).
Comment 6 Colin Guthrie 2012-04-03 04:14:47 UTC
(In reply to comment #5)
> Okay, I misunderstood how the cookie works, and since the original reporter
> found the locking issue to be portmap/lockd related, I guess this becomes
> irrelevant (other than moving the sockets).

Well I would still say the lock handling around .pulse-cookie could be more efficient anyway - e.g. in the vast majority of cases we just need to read it and then we're done. No need to lock in such situations really. Only when we need to overwrite it should we attempt to do any locking IMO.

So I think the decided approach outlined on the ML thread still stands.
Comment 7 Bill Nottingham 2012-04-11 15:15:49 UTC
Created attachment 59819 [details] [review]
sockets in XDG_RUNTIME_DIR - the simple implementation

(In reply to comment #4)
> The cookie should stay in $HOME, but the sockets should move to
> XDG_RUNTIME_DIR.

OK then. Note: probably missing some use case here.
Comment 8 william.jon.mccann 2012-04-30 10:58:12 UTC
The cookie should not remain in HOME. Perhaps you meant XDG_CACHE_HOME?
Comment 9 Colin Guthrie 2012-04-30 12:54:28 UTC
Hi Jon, Shouldn't the cookie go into the .config tree? Or is XDG_CACHE_DIR guarenteed to be quite long lasting (cookies should be pretty static to allow for them to be copied to other machines etc.)
Comment 10 william.jon.mccann 2012-05-03 10:03:22 UTC
(In reply to comment #9)
> Hi Jon, Shouldn't the cookie go into the .config tree? Or is XDG_CACHE_DIR
> guarenteed to be quite long lasting (cookies should be pretty static to allow
> for them to be copied to other machines etc.)

Just talked to Lennart about it and I suppose since it is persistent XDG_CONFIG_HOME/pulse is fine.
Comment 11 Lennart Poettering 2012-05-15 15:07:53 UTC
Fixed in git. Moved the runtime stuff to XDG_RUNTIME_DIR and everything else to XDG_CONFIG_HOME/pulse, including the cookie.