[pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk

[Nix]

On 16 May 2010, Tanu Kaskinen spake thusly:

> On Sat, 2010-05-15 at 22:43 +0100, Nix wrote:
>> But I'm getting this when I try to *start* the user-configured server
>> on that machine, via e.g. start-pulseaudio-x11!
>> 
>> With this in place, how are you supposed to start PA at all? (I'm not
>> even entirely clear what a 'user-configured server' is. A server that
>> the user has configured? A server meant to run under the user's
>> privileges, as opposed to a systemwide PA? Something else?)
>
> "User-configured" means that there's a server address configured either
> by setting the PULSE_SERVER environment variable, by setting the
> PULSE_SERVER X11 root window property, or by setting the default-server
> option in client.conf. The logic is that if one of those is set, then
> the server that the user wants to use is probably running on some other
> machine, or even if the configuration points to the local machine, the
> server is already running.

Wrong logic :/ I set PULSE_SERVER via machine-invariant shell script run
only by session leaders (as these either logged in directly, or sshed
in, thus lost their environment variables), to refer to, roughly, the
machine on which the X DISPLAY is running. (I can't use the X cookie
consistently because some of these sessions have no access to X but I
*do* want them to be able to generate sounds: more generally, if I do
generate a session with no access to X, I don't want to cut it off from
sound generation too: the two should be orthogonal.)

So PULSE_SERVER is set *everywhere* for me: in particular it is already
set when X starts up, to the machine on which X is being started. This
is the same sort of thing as one uses for a lot of other persistent or
semi-persistent servers. This is how ESPEAKER worked for esd. It's how
PGHOST works for PostgreSQL. It's how they *all* work. Can you imagine
what it would be like if HTTP_PROXY only worked if the proxy was on
a remote machine?

Pure consistency should dictate that PULSE_SERVER should affect only and
precisely where clients should look for the PA server, not whether
PulseAudio can start. (This was so unexpected that I didn't even figure
it out after reading the code!)

> Since the assumptions that the code is based break on your
> configuration,

And everyone's configuration I'd imagine. PULSE_SERVER seems like a
likely thing to set in e.g. /etc/environment or session-wide startup
scripts; does that mean you don't want to start a server at all? No,
it just means you want network-transparent audio to work once you
*do* start a server.

>               apparently some documentation is needed somewhere in
> order to prevent the users from shooting themselves in the foot

I don't understand why you're banning this at all.

> So, in order to figure out the place where you would have needed some
> more warnings, could you tell where and why have you set the server
> address?

It's set everywhere so that remote machines know to look to the local
machine for the sound server, and because the local machine may have
many DNS and IP aliases so it may be tricky to determine if the name
given for the PA server (perhaps itself a CNAME) equates to the local
machine.  Since, before now, setting it was harmless, that was a pile of
extra complex code for no benefit. (Also, I'd never have imagined *not*
setting it merely because the machine on which PA is running is the
local machine. As mentioned above, environment variables containing the
names of other sorts of server don't get unset merely because that
server happens to be local.)