Glenn Golden <gdg at zplane.com> [2015-10-09 06:28:58 -0600]:
> 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.
A few quick experiments suggest that the above does seem to be what's
happening: Manually starting a PA process while pulseaudio socket activation
is enabled causes systemd to think that the manually-starting PA process is a
sound client (probably when it attempts (and fails) to bind() the PA socket).
In response to this socket activity, systemd starts his own independent PA
daemon. The manually started PA daemon thus correctly reports EADDRINUSE, then
dies off with $? = 1. The PA daemon that is observed to be running after the
entire brouhaha settles down is the one started by systemd.
Let me know if anyone thinks it's worth filing a ticket on this or not. I'm
inclined to do so, but not strongly. The suggested fix would be that (if
possible) PA attempt to determine whether the PA socket is in use in a more
clandestine fashion that does not cause systemd to react and launch a
conflicting PA instance. If this is possible, then the manually started PA
process will still report EADDRINUSE and exit with $? = 1 (as now) but the
difference will be that if no PA process was running before the attempt to
manually start, there will still be no PA process running afterwards.