Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
'Twas brillig, and Nix at 29/05/10 11:19 did gyre and gimble: Things get clearer. (Sorry for the delay: jobhunting hell.) On 17 May 2010, Tanu Kaskinen told this: That seemed strange, because the X11 properties are set automatically, and the user probably usually doesn't know anything about the existence of the X11 properties. That means that if an user sets an address for a remote server in client.conf, that won't have any effect if start-pulseaudio-x11 is used (and it is used in most cases), and the user won't have any idea why it's not working. As opposed to now, where I do in fact run start-pulseaudio-x11, and had no idea why it wasn't working until I looked at the source code :/ Yeah, clearly that is not a good situation :s 16:50 coling tanuk, but the way it works is that the PULSE_SERVER prop actually contains multiple addresses... a local socket, a tcp6 address, a tcp4 address etc. Ah, yes, I forgot about this feature. This surely makes it even *more* important that the server starts when the client asks it to, because you might be starting a server earlier on the preference list than the one you're already using. But your comments below make the rationale clearer: I just wish there was a less aggravating way to do it. Well that's a tricky situation to resolve. If I ssh to another machine, I specifically want the earlier (higher preference) servers in the list to fail so that I fall back to network and get the sound out of my local machine. The last thing I want is for PA to think Hmm, I'm connected, but not to the first server and try and spawn one. That said, local socket paths in the PULSE_SERVER var are prefixed with the dbus machine id. If the machine id == this machine, and we cannot connect to the server, it's pretty likely that we need to start a local server. I not sure under what circumstances this logic would fail - su'ing to another user while the X11 props are there and the server died will break, but it's quite a corner case. 17:30 coling i.e. the idea is that if a default server is specified in client.conf, then the daemon wont be started and the x11 modules wont load and the x11 prop wont be set. Aha, so the idea is that PULSE_SERVER should specify your local server, then every remote server it might possibly want, in preference order, More or less by by default, it is used to specify the *same* PA server, accessible via different means. e.g. local, tcp6 and tcp4. That way local apps, running locally will use a local socket and remote apps running after SSHing to a remote machine will use some tcp variant. and that it should get set after PA itself starts. How strange. How else can we know what the patch to the local socket will be without starting PA (or at lease using the client libraries)? These settings are a reflection of the running server, not a pointer to where it should be. If the server crashes, the configuration *should* die with it, but that is not always possible. The x11-publish module will remove the X11 properties when shut down cleanly, but a crash.. (Also sort of impractical if you have a server that serves several hundred desktops: what's PULSE_SERVER going to do, specify them all? The order would differ between users, so in pradtice you still need to dynamically compute it.) Not sure what you mean by a server that serves several hundred desktops. On such a scale, it's very unlikely that the desktop machine itself would be responsible for starting the daemon and thus any configuration would have to be written on top of PA, not be part of it. But perhaps I don't understand your setup? (But still, a server that won't start because an environment variable is set telling *client* programs where to look for that very server? What a horrible idea.) I don't necessarily disagree, but the same logic that applies to autospawning, (triggered by the *client*) should really apply to how the server itself is started too, so there is some logic in keeping them tied together like that. 16:26 mezcalero tanuk: the start-pulseaudio-x11 script should probably refuse to do anything if there is already a server configured by some means Agreed. I suspect the right way to detect this is to *try to connect to it*, not just to use PULSE_SERVER as an (easily erroneous) promise that the server is already running. It's sort of strange for a PA server to do this (which is normally the responsibility of the client), so perhaps what we need is a pulseaudio ping program (part of pactl probably), and have start-pulseaudio-x11 run that to see if the server is already up, rather than have pulseaudio itself check for any such thing. It takes a tiny bit longer, but who cares if startup forks one more time? It's not as if we start up every five minutes. Ohh, have you not read Lennart's systemd stuff - beware the forks!!! :p But seriously, I think the pulse server variable should be checked to see if it
Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
Things get clearer. (Sorry for the delay: jobhunting hell.) On 17 May 2010, Tanu Kaskinen told this: That seemed strange, because the X11 properties are set automatically, and the user probably usually doesn't know anything about the existence of the X11 properties. That means that if an user sets an address for a remote server in client.conf, that won't have any effect if start-pulseaudio-x11 is used (and it is used in most cases), and the user won't have any idea why it's not working. As opposed to now, where I do in fact run start-pulseaudio-x11, and had no idea why it wasn't working until I looked at the source code :/ 16:50 coling tanuk, but the way it works is that the PULSE_SERVER prop actually contains multiple addresses... a local socket, a tcp6 address, a tcp4 address etc. Ah, yes, I forgot about this feature. This surely makes it even *more* important that the server starts when the client asks it to, because you might be starting a server earlier on the preference list than the one you're already using. But your comments below make the rationale clearer: I just wish there was a less aggravating way to do it. 16:50 coling So that local seesions tend to go via local socket, but remote ones try that, fail and fall back to a networking version This feature *might* mean I can stop computing PULSE_SERVER, and just set it statically. Let's see... 17:30 coling i.e. the idea is that if a default server is specified in client.conf, then the daemon wont be started and the x11 modules wont load and the x11 prop wont be set. Aha, so the idea is that PULSE_SERVER should specify your local server, then every remote server it might possibly want, in preference order, and that it should get set after PA itself starts. How strange. (Also sort of impractical if you have a server that serves several hundred desktops: what's PULSE_SERVER going to do, specify them all? The order would differ between users, so in pradtice you still need to dynamically compute it.) (But still, a server that won't start because an environment variable is set telling *client* programs where to look for that very server? What a horrible idea.) 16:26 mezcalero tanuk: the start-pulseaudio-x11 script should probably refuse to do anything if there is already a server configured by some means Agreed. I suspect the right way to detect this is to *try to connect to it*, not just to use PULSE_SERVER as an (easily erroneous) promise that the server is already running. It's sort of strange for a PA server to do this (which is normally the responsibility of the client), so perhaps what we need is a pulseaudio ping program (part of pactl probably), and have start-pulseaudio-x11 run that to see if the server is already up, rather than have pulseaudio itself check for any such thing. It takes a tiny bit longer, but who cares if startup forks one more time? It's not as if we start up every five minutes. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
On Sun, 2010-05-16 at 22:41 +0100, Nix wrote: On 16 May 2010, Tanu Kaskinen spake thusly: 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 you have a server with display and keyboard and all that stuff, and there are basically three ways that the server is used: 1) Not as a server, but as a regular desktop machine, i.e. local X11 session. 2) Remotely through ssh, running an X11 session. 3) Remotely through ssh, not running an X11 session. Pulseaudio handles cases 1 and 2 without any extra configuration, but not case 3. So do you really have a client machine that has a sound card but no graphical display, or if it has a graphical display, it's still used to ssh to the server outside any X11 session and run programs that generate sound and the sound needs to be sent to the client's sound card? Quoting ssh's manual page: Additionally, ssh reads ~/.ssh/environment, and adds lines of the format “VARNAME=value” to the environment if the file exists and users are allowed to change their environment. For more information, see the PermitUserEnvironment option in sshd_config(5). Is dropping the PULSE_SERVER configuration at the server end, and setting PULSE_SERVER in ~/.ssh/environment at the client end a satisfactory solution? 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? AFAIK Postgresql and HTTP proxies aren't designed to be started as part of a login session, so they don't have the same problem as Pulseaudio. 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. If you set PULSE_SERVER in /etc/environment, that's going to be a static value because /etc/environment is not a script. If the value is static, that means that it can't point to per-user pulseaudio instances, and since --start is used only when starting per-user instances, there's no problem. Why would you set PULSE_SERVER to point to the local yet-to-be-started per-user instance in a session start-up script? Other than in the setup that you currently have, that is. To me your requirements seem very rare. I don't mean that we don't need to care about your requirements, just that breaking everyone's configuration doesn't seem likely. 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. Ok, I'll tell the story why I wrote this patch. I was working on the server discovery logic for D-Bus clients, and that logic will be very similar to the discovery logic for the native protocol clients. So, I was reading the native protocol's client code for inspiration, and noticed that the X11 properties override the configuration in client.conf. That seemed strange, because the X11 properties are set automatically, and the user probably usually doesn't know anything about the existence of the X11 properties. That means that if an user sets an address for a remote server in client.conf, that won't have any effect if start-pulseaudio-x11 is used (and it is used in most
Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
On Sun, 2010-05-16 at 01:45 -0400, Sean McNamara wrote: On Sun, May 16, 2010 at 12:24 AM, Tanu Kaskinen ta...@iki.fi wrote: 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. Are you aware of the fact that you can start pulseaudio without the --start option? The manual page explains --start: Start PulseAudio if it is not running yet. This is different from starting PulseAudio without --start which would fail if PA is already running. PulseAudio is guaranteed to be fully initialized when this call returns. Implies --daemon. That explanation should be expanded to cover the behavior when the user has configured an explicit server address, but my point is that I get the feeling that you think that in order to start Pulseaudio you must always use the --start option. The client configuration is not checked when starting pulseaudio without the --start option. If I got the wrong impression and you were aware of this already, then I'd like to hear about concrete situations where it does make sense to configure the server address in client.conf and still use the --start switch for launcing a per-user daemon, or using the --start switch for launcing a per-user daemon in an environment where the PULSE_SERVER variable is set. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
'Twas brillig, and Tanu Kaskinen at 16/05/10 13:11 did gyre and gimble: If I got the wrong impression and you were aware of this already, then I'd like to hear about concrete situations where it does make sense to configure the server address in client.conf and still use the --start switch for launcing a per-user daemon, or using the --start switch for launcing a per-user daemon in an environment where the PULSE_SERVER variable is set. I've not had time to think about this thread/issue fully, but one example that may be a problem is when the X11 root window properties are set and we try to restart PA. This could happen I think if PA is started via start-pulseaudio-x11 but then crashes without shutting down nicely which I *think* leaves behind the X11 properties. If I'm right, this is one situation that you definitely do want PA to autospawn itself again. I'll try and comment more fully soon and actually test things etc. :p Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
On 16 May 2010, Colin Guthrie said: 'Twas brillig, and Tanu Kaskinen at 16/05/10 13:11 did gyre and gimble: If I got the wrong impression and you were aware of this already, then I'd like to hear about concrete situations where it does make sense to configure the server address in client.conf and still use the --start switch for launcing a per-user daemon, or using the --start switch for launcing a per-user daemon in an environment where the PULSE_SERVER variable is set. I've not had time to think about this thread/issue fully, but one example that may be a problem is when the X11 root window properties are set and we try to restart PA. This is what I was doing: I'd just upgraded it. Imagine my joy to find I could kill the old instance but couldn't start a new one. ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
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.) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
[pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
Obviously I'm missing something, but this hunk of this change:
commit f1d1447e104c4f609c0e8c528b56ea6afa540b95
Author: Tanu Kaskinen ta...@iki.fi
Date: Sat Jan 9 11:55:15 2010 +0200
daemon: Don't autospawn if a server address is explicitly configured.
@@ -649,6 +672,13 @@ int main(int argc, char *argv[]) {
goto finish;
}
+if (conf-cmd == PA_CMD_START (configured_address =
check_configured_address())) {
+pa_log_notice(_(User-configured server at %s, not autospawning.),
configured_address);
+pa_xfree(configured_address);
+retval = 0;
+goto finish;
+}
+
if (conf-system_instance !conf-disallow_exit)
pa_log_warn(_(Running in system mode, but --disallow-exit not set!));
is not conditional on autospawning actually taking place: it will
trigger when the daemon is started conventionally.
Proof:
n...@mutilate 440 /home/nix% /usr/bin/pulseaudio --start
N: main.c: User-configured server at sound.srvr.nix, not autospawning.
Shouldn't this check autospawn_fd, or *something* initialized only when
autospawning? Or am I missing something? (I suspect I must be.)
___
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
On Sat, 2010-05-15 at 15:38 +0100, Nix wrote: Obviously I'm missing something, but this hunk of this change: snip is not conditional on autospawning actually taking place: it will trigger when the daemon is started conventionally. Proof: n...@mutilate 440 /home/nix% /usr/bin/pulseaudio --start N: main.c: User-configured server at sound.srvr.nix, not autospawning. Shouldn't this check autospawn_fd, or *something* initialized only when autospawning? Or am I missing something? (I suspect I must be.) I was confused when making that commit. I think the logic is correct, but the commit message and the log message are wrong. The commit message can't be fixed, but the log message should be User-configured server at %s, not starting. I'll prepare a patch for the log message tomorrow. -- Tanu Kaskinen ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
On 15 May 2010, Tanu Kaskinen uttered the following: On Sat, 2010-05-15 at 15:38 +0100, Nix wrote: Obviously I'm missing something, but this hunk of this change: snip Proof: n...@mutilate 440 /home/nix% /usr/bin/pulseaudio --start N: main.c: User-configured server at sound.srvr.nix, not autospawning. Shouldn't this check autospawn_fd, or *something* initialized only when autospawning? Or am I missing something? (I suspect I must be.) I was confused when making that commit. I think the logic is correct, but the commit message and the log message are wrong. The commit message can't be fixed, but the log message should be User-configured server at %s, not starting. 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?) ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
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. 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@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Not only autospawning, but all PA daemon startup of any kind appears impossible with PA trunk
Hi, On Sun, May 16, 2010 at 12:24 AM, Tanu Kaskinen ta...@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
