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
