Felipe Sateler <fsateler at debian.org> [2015-10-08 19:34:08 -0300]:
> 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.
>
It _does_ report why it thinks it failed (at least, it does so when the
--start option is omitted, as I pointed out above, and as you mentioned below).
And regardless of --start, it sets $? to show that it failed.
But it didn't fail, it succeeded!
It's not the lack of reporting that is the issue here: It's the inconsistency
between what is being reported ("failed to start", $? == nonzero) and what
actually evidently occurred (daemon started successfully).
>
> If you omit the --start command, then you get the following errors
> (why don't they appear anywhere when using --start?):
>
Yes, as I reported: "...the only difference [without --start] is lots more
debug info is seen."
What I'm guessing is going on here is something of this sort:
* No PA daemon is running to begin with, nor is any audio client. But
systemd is monitoring the socket for client access.
* User starts PA daemon manually from commandline
* During the course of its normal initialization, the PA daemon started by
the user accesses the the socket.
* The socket access causes systemd to start its own PA daemon process,
thinking that the socket access was due to a new audio client.
* PA daemon process started by user from commandline cannot obtain socket
and dies, reporting "addr in use" and setting $? = 1.
Just guessing, but the above seems to account for all of the observed facts
on the ground.
