[pulseaudio-discuss] --check option seems not to work from su(1)

[Glenn Golden]

Tanu Kaskinen <tanu.kaskinen at linux.intel.com> [2014-09-28 11:38:51 +0300]:
> On Sat, 2014-09-27 at 10:00 -0600, Glenn Golden wrote:
> >
> >   * PULSE_AUDIO envar unset
> >   * PULSE_AUDIO X11 property unset
> 
> I guess you mean PULSE_SERVER, not PULSE_AUDIO?
> 

Yes, sorry for the confusion.

> 
> >  Why is it _creating_ a new runtime dir /tmp/pulse-XXXX (and associated
> >  symlink in ~/.config/pulse) when it seems like what it ought to be doing
> >  in this situation is simply looking for an extant runtime dir (given
> >  that autospawn is disabled)?
> 
> The function for getting the runtime dir also creates it if it doesn't
> exist. I don't think that's a good idea, but that's how Lennart did it
> in the beginning of time and nobody has bothered to changed it.
> 

OK.  Should I file a ticket on that, just for completeness sake?  I mean, just
as a reminder of something to look into at some future time when scraping out
or refactoring the code. Creatin the dir seems like wacky behavior in the
context of what is trying to be accomplished.


> > Why does it name the symlink in ~/.config/pulse as HOST-runtime, rather
> > than MID-runtime (since on my system /etc/machine-id is available)?
> 
> Most likely because you built pulseaudio from source and sysconfdir
> points to /usr/local/etc,
>

Ah, ok.  Actually, it points to /path/to/my/build/directory/etc (which of
course also doesn't exist) so what I did was just symlink that path to the
real /etc. Once that was done, then it does indeed see the machine-id file
and creates the symlink named as MID-runtime instead of HOST-runtime, as
expected. Thanks.

> 
> > What information participates in the hashing that generates the XXXX?
> > (The reason for this question is that it seems to generate identical XXXX
> > every time, if one starts with the initial conditions described above.)
> 
> It's not a hash, it's a pseudo-random string. It seems that the seed
> isn't set by libpulse, it's only set by the daemon, so if a client
> creates the "random" directory, it will always be the same, because the
> seed will always be 1 (we use rand() for randomness).
> 

Ok.  But this begs the question: If the seed is fixed, then what advantage
derives from naming the dir based on the k-th iterate of rand(), rather than
simply the value k itself (chosen from some suitably zero-padded sequence,
e.g. pulse-00001, pulse-00002, etc)?  The latter would even have the
(admittedly minor) advantage of informing the user (and maintainer/debugger)
as to time ordering of the runtime directory creations.

Actually, now that I think about it... the use of a fixed initial seed per
PA daemon brings up another even more interesting question: Since multiple
(distinct) users can run independent PA daemons (as long as each daemon talks
to disjoint subsets of the available audio hardware) then how do runtime
directories named like /tmp/pulse-XXXX get forcibly orthogonalized from user
to user, given that each daemon begins with rand() seed = 1?  

This question probably misses something glaringly obvious...


> 
> > In the constructed server_list, it seems curious that it contains the
> > dereferenced symlink (i.e. the target directory /tmp/pulse-XXXX/native)
> > rather than the symlink itself (~/.config/pulse/HOST-runtime).  (This is
> > a minor point; just asking because seems to me that the symlink is the
> > more useful piece of info to be reported when debug logging is enabled,
> > since in effect, that's the runtime dir of interest.)
> 
> prepend_per_user() in context.c calls pa_runtime_path(), which will
> return a string containing the runtime directory concatenated with
> another path, in this case "native". pa_runtime_path() in turn calls
> get_path() in core-util.c, and get_path() resolves the symlink, because
> we had an issue on some systems with the non-resolved path being too
> long (over 108 characters). The resolved path is likely to be shorter
> than the non-resolved path.
> 

Ouch. Ok. I'm not sure whether to laugh or cry at this, so I'll just shut up,
lol...

Thanks again for your time on this, Tanu. 

Glenn