Pulseaudio cannot be kept from starting or respawning

Bug #1899352 reported by ralphb on 2020-10-11
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pulseaudio (Ubuntu)

Bug Description

On my freshly installed system, I need to run pulseaudio in system mode. Alas, by default, pulseaudio is run in user mode, and is set to respawn, so that I cannot kill the user process and start pulseaudio in system mode.

I tried:

1. Editing /etc/pulse/client.conf, setting autospawn = no. This did nothing.
2. Removing the file /etc/pulse/client.conf.d/01-respawn-something. I cannot even begin to fathom why such a file would exist. Anyway, this did nothing.
3. I removed the file /usr/bin/start-pulseaudio. Why .... Of course, this did nothing.
4. I removed the file /etc/xdg/autostart/pulseaudio.desktop. Why on earth do you implement four different ways to annoy your users? On the other hand, this did NOTHING.

User mode is still starting, and respawning is enabled.

What the heck do I have to do to get rid of user mode pulseaudio? Could you please clean up this clusterfuck?

ralphb (dev-endlos) on 2020-10-11
summary: - Pulseaudio cannot be stopped or kept from respawning
+ Pulseaudio cannot be kept from starting or respawning
ralphb (dev-endlos) wrote :

Also, as user:

cassiopeia ~ > pulseaudio -k
N: [pulseaudio] main.c: System mode refused for non-root user. Only starting the D-Bus server lookup service.

Then, as root, with system mode running:

cassiopeia:~# ps aux | grep pulse
pulse 2334 0.0 0.0 239320 10568 ? S<l 17:26 0:00 pulseaudio -D
ralph 2344 0.0 0.0 86928 5280 ? S<s 17:27 0:00 /usr/bin/pulseaudio --daemonize=no --log-target=journal
cassiopeia:~# pulseaudio -k
E: [pulseaudio] main.c: Failed to kill daemon: No such process

This makes no sense.

Daniel van Vugt (vanvugt) wrote :

It looks like you would need to somehow edit/disable:


Also, since this is not actually a bug I am going to mark it as invalid. But you are free to keep discussing the issue here.

Changed in pulseaudio (Ubuntu):
status: New → Invalid
ralphb (dev-endlos) wrote :

Thanks, that's fair enough.

My remaining questions then are:

1. Why is /usr/bin/start-pulseaudio needed?
2. Why is /etc/pulse/client.conf ignored?
3. In light of 2, why is /etc/pulse/client.conf.d/01-respawn-something needed?
4. And in light of /lib/systemd/user/pulseaudio.service, why is /etc/xdg/autostart/pulseaudio.desktop needed?

Wouldn't one way to start pulseaudio be sufficient? Also, please don't ignore the configuration.

Finally, how can I use any of these methods to start pulseaudio in system mode? Adding -D to /lib/systemd/user/pulseaudio.service did not work (probably because I'm not root).

Daniel van Vugt (vanvugt) wrote :

1. I don't know where you got that file. I don't seem to have it in Ubuntu 20.04 or 20.10. You can find out where it's from with 'dpkg -S ...'

2. Some quick Googling suggests /etc/pulse/* is the fallback for when ~/.local/pulse/* does not exist.

3. I don't know where you got that file. I don't seem to have it in Ubuntu 20.04 or 20.10. You can find out where it's from with 'dpkg -S ...'

4. It would appear that's for distros that don't use systemd.

To make future bug reports easier to answer please use the command:

  ubuntu-bug pulseaudio

to open any future bugs. Or better yet, put future questions to the PulseAudio developers instead:


ralphb (dev-endlos) wrote :

The package "pulseaudio" contains the files:


Thus, it should be fairly obvious where I got the files from.

And /etc/pulse/client.conf is ignored, despite my user (and root) not having a ~/.local/pulse directory.

And why would we need files for non-systemd systems if Ubuntu _is_ a systemd-base system?

So I still think something is quite wrong with the pulseaudio package.

Daniel van Vugt (vanvugt) wrote :

OK those are different filenames to your first comment #3, which is why they don't exist...

Packages like pulseaudio are intended to support multiple different distros and "flavours". Sometimes those won't have systemd. So especially if the package predates systemd, there's no reason to drop files that support the alternatives. Such files are harmless, mostly unused, and occasionally useful.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers