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

[Sean McNamara]

Hi,

On Sun, May 16, 2010 at 12:24 AM, Tanu Kaskinen <tanuk at iki.fi> wrote:
> 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.

But that isn't always true. I can think of valid ways to set
PULSE_SERVER in an environment where I still want to be able to start
the PulseAudio server. Or perhaps, I don't strictly _need_ to set
PULSE_SERVER in that environment, but it's just easier to modify
client.conf than to set environment variables. But if you set
client.conf's default-server, PulseAudio will never start on your
system, period. That seems a little broken to me.

You could say: don't set PULSE_SERVER in the environment of the
daemon, and don't set default-server in client.conf. These are
workarounds, but then I am forced to ask: why are we making users work
around an enhancement patch just to get PA running?

What value does this feature add? It seems like it's fixing some
obscure requirement for some users, while intentionally breaking PA
for others. Enforcing this on everyone (without so much as an option
to disable it) can only hurt the usability picture of PA --
particularly because this "feature" adds another reason for PulseAudio
to refuse to start, which leads people to seek technical support (as
you can already see from the existence of this thread, so soon after
this code has been published).

Besides, isn't it a layering violation for the server process in a
client-server architecture to care about an environment variable
that's meant to be used by the client? Most other client-server
programs have a clear separation between the data relied upon by the
client, and the data relied upon by the server, except for
well-defined interfaces (in our case, the PA native protocol). PA gets
this right most of the time! But this patch makes the server directly
care about a variable that is chiefly used by PA clients. Unless you
want to advance something like the server is a client of itself, this
seems awkward.

There are valid use cases of PA, with or without the logic of this
patch. Obviously, you found a use case for your logic, or you wouldn't
have implemented it. And others have found a use case for not having
your logic, or this thread wouldn't exist. However, this is a case
where shell scripting can make things work correctly regardless of
whether your patch is included or not.

(Ignoring the X11 root window) If your patch is included, then people
can preserve the old functionality by unsetting PULSE_SERVER before
launching the daemon, and making sure the daemon reads a client.conf
where default-server is not set. As long as these changes are local to
the actual PA daemon invocation, clients running as the same user (or
a different user) can happily set PULSE_SERVER or modify client.conf.

If your patch is not included, then users can achieve the same
functionality as your patch by wrapping PA invocations in a shell
script that checks whether PULSE_SERVER is set, or parse-- oh, yuck.
Correctly parsing client.conf in a scripting language is definitely a
tractable task, but not as simple as the workaround for when your
patch is not included. I can kind of see your motivation for making
this patch.

Still, the new functionality flunks the "Principle of Least Surprise"
test. Logic such as "I refuse to start because people who do X usually
don't really want to start me" is definitely surprising when the
refusal is thrown in the user's face. The user is trying to explicitly
start PulseAudio -- of course he really wants to start it!

Maybe we can add a --force option to ignore this check? Then we can
just add to the Wiki that if you have set default-server or
PULSE_SERVER in the context where you start the daemon, you need to
start it with --force. And a lot of people working on Linux/UNIX are
already used to searching for a --force option when things don't work,
so they might be able to resolve it themselves.

Of course, it's possible that we could avoid this whole complexity if
we can have a more in-depth discussion of why the patch was developed
in the first place, and offer a more elegant solution for that
problem. Sorry if it's already been discussed on the ML, but I haven't
been reading it very actively for a while. I would really like to
understand what your requirements were that led to the development of
this patch, so the community can decide if there is a better way to
accommodate your needs than to introduce this surprising (mis)feature.

Thanks,

Sean

>
> Maybe the log message needs to be more elaborate. Some of the above
> explanation could be used.
>
> Since the assumptions that the code is based break on your
> configuration, apparently some documentation is needed somewhere in
> order to prevent the users from shooting themselves in the foot
> (hopefully documentation is a sufficient fix).
>
> 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?
>
> --
> Tanu Kaskinen
>
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at mail.0pointer.de
> https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
>