Bug 48226

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)

/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.

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.

The cookie should stay in $HOME, but the sockets should move to XDG_RUNTIME_DIR.

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).

(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.

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.

The cookie should not remain in HOME. Perhaps you meant XDG_CACHE_HOME?

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.)

(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.

Fixed in git. Moved the runtime stuff to XDG_RUNTIME_DIR and everything else to XDG_CONFIG_HOME/pulse, including the cookie.