[pulseaudio-discuss] Pulseaudio daemon initialization perjury

[Felipe Sateler]

On 8 October 2015 at 11:22, Glenn Golden <gdg at zplane.com> wrote:
> Felipe Sateler <fsateler at debian.org> [2015-10-08 09:45:51 -0300]:
>> On 8 October 2015 at 06:28, Glenn Golden <gdg at zplane.com> wrote:
>> > Tanu Kaskinen <tanuk at iki.fi> [2015-10-08 11:33:48 +0300]:
>> >> On Wed, 2015-10-07 at 12:21 -0600, Glenn Golden wrote:
>> >> > The following observations were made on a setup (Arch Linux, x86_64, recently
>> >> > synched, Arch pulseaudio package 7.0-2) on which the user desires that no
>> >> > automated launch or respawning of the PA daemon should occur; the user
>> >> > wishes to start the PA daemon only manually, without any behind the scenes
>> >> > "assistance".
>> >> >
>> >> > The user's client.conf contains only the following lines:
>> >> >
>> >> >     default-server =
>> >> >     autospawn = no
>> >> >
>> >> > First, verify via ps that no PA process is running. Then, from the commandline
>> >> > as the (non-root) user:
>> >> >
>> >> >     $ export PULSE_LOG=99
>> >> >     $ pulseaudio -v -v -v -v -v --start
>> >> >     D: [pulseaudio] caps.c: Cleaning up privileges.
>> >> >     D: [pulseaudio] conf-parser.c: Parsing configuration file \
>> >> >        '/etc/pulse/daemon.conf'
>> >> >     D: [pulseaudio] conf-parser.c: Parsing configuration file \
>> >> >        '/home/XXX/.config/pulse/client.conf'
>> >> >     E: [pulseaudio] main.c: Daemon startup failed.
>> >> >
>> >> > Upon return to the shell prompt, interrogate the exit status:
>> >> >
>> >> >      $ echo $?
>> >> >      1
>> >> >
>> >> > Now observe via ps that a PA daemon process is running:
>> >> >
>> >> >      ...  S
>> >> >
>> >> > and appears to be behaving normally in all respects.
>> >> >
>> >> > At least three things in the above are worthy of head-scratching:
>> >> >
>> >> >     1. The error message states "daemon startup failed", yet a pulseaudio
>> >> >        process clearly did start, and appears to be running as a daemon process.
>> >> >
>> >> >     2. The '--daemonize=no' shown on the ps line seems wrong, since the PA
>> >> >        process -- which was reported as having failed to start -- is in fact
>> >> >        running as a daemon process.
>> >> >
>> >> >     3. The exit status from the startup command is nonzero (failure), yet the
>> >> >        daemon was evidently started successfully.
>> >>
>> >> Arch uses systemd's socket activation to start pulseaudio.
>> >>
>> >
>> > Hmm, ok, maybe I'm not appreciating the implication of what you're saying
>> > above, but it seems to me that socket-based activation is irrelevant what
>> > is being reported: There was no pulseaudio daemon running at the beginning
>> > of the sequence shown above.
>>
>> Socket activation means systemd will start pulseaudio automatically
>> when a client tries to connect to it, so it starts on demand.
>>
>
> Yes, that much I know. But I still don't see any connection to the original
> example showing the misinformation being reported during a manual start. At
> no time is any client running (that I am aware of) so why should socket
> activation come into play at all?
>
>> >
>> >>
>> >> To prevent automatic starting, I think "systemctl --user disable
>> >> pulseaudio.socket" should do the trick.
>> >>
>> >
>> > Here's the result of the above:
>> >
>> >     $ systemctl --user disable pulseaudio.socket
>> >     Failed to get D-Bus connection: No such file or directory
>>
>> That doesn't look like a simple file not found, as the dbus connection
>> is to the systemd user instance.
>>
>
> The above 'disable' was done as root, perhaps that was not intended. Doing it
> instead as non-root user yields the following:
>
>         $ systemctl --user disable pulseaudio.socket
>         Failed to execute operation: No such file or directory
>
>> >
>> > I think this is because I don't have socket activation enabled, which is
>> > as expected: The only "pulseaudio.socket" file in my filesystem is located
>> > in /usr/lib/systemd/user (i.e. as supplied by the distro). There is no
>> > pulseaudio.socket in my /etc/systemd/user directory.
>>
>> The link should be in ~/.config/systemd/user/*.wants.d/ or in
>> /usr/lib/systemd/user/*.wants.d/
>>
>
> There is no ~/.config/systemd.
>
> There is a symlink to /usr/lib/systemd/user/pulseaudio.socket located in
> /usr/lib/systemd/user/sockets.target.wants (note no ".d" suffix). But
> still not sure what this has to do with the issue I'm reporting, which
> is the misinformation barfed by the daemon when it is started manually.
>
>>
>> >> The --start option is arguably obsolete on systems that use systemd to
>> >> manage the pulseaudio daemon, but it would be good if we could make it
>> >> less confusing.
>> >>
>> >
>> > Exactly the same sequence occurs as shown in the example above even without
>> > the --start option; the only difference is lots more debug info is seen.
>> > Everything else remains just as shown in the example above.
>> >
>> > So honestly, not sure how socket activation comes into play here. Can you
>> > explain a little more please?
>>
>> Pulseaudio clients speak to the daemon via a socket. Traditionally,
>> daemons open up the socket and listen on it, and clients can connect
>> to it. Under systemd socket activation, it is systemd that opens the
>> socket and listens on it, and when it receives the first request, it
>> starts the pulseaudio daemon and passes the socket on so the server
>> can handle the request.
>>
>> Under the socket activation scheme, the autospawn scheme becomes
>> superfluous, as the daemons state is handled by a proper service
>> manager (systemd) instead of assuming that every time the daemon is
>> not running a new one should be started.
>>
>
> OK thanks, that was my understanding previously too. But again, I don't see
> the connection to what is being reported: No client comes into play (that I am
> aware of) at any time during the sequence that was described. The example
> sequence starts with no clients running, no PA daemon running, and simply
> attempts (and succeeds) to start the PA daemon manually from the commandline.
> No client program is ever executed (at least not intentionally).  The issue
> being brought up is that the PA daemon reports information that seem to be
> completely at odds with what actually occurred during the startup.

This seems a real bug. Pulseaudio should at the very least report why
it (thinks it) failed.

If you omit the --start command, then you get the following errors
(why don't they appear anywhere when using --start?):

E: [pulseaudio] socket-server.c: bind(): Address already in use
E: [pulseaudio] module.c: Failed to load module
"module-native-protocol-unix" (argument: ""): initialization failed.
E: [pulseaudio] main.c: Module load failed.
E: [pulseaudio] main.c: Failed to initialize daemon.

So pulseaudio cannot open the socket because systemd has it open.

-- 

Saludos,
Felipe Sateler