[pulseaudio-discuss] Pulseaudio daemon initialization perjury

[Glenn Golden]

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.