[pulseaudio-discuss] Pulseaudio daemon initialization perjury

[Felipe Sateler]

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.

>
>>
>> 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.

>
> 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/


>> 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.

-- 

Saludos,
Felipe Sateler