Description of problem: After updating from F27 to F28, pulseaudio no longer respects the "autospawn = no" parameter in /etc/pulse/client.conf. I have also tried adding it in ~/.pulse/client.conf. Running pulseaudio -k kills the process, but spawns a new one immediately: $ ps aux | grep pulse | grep -v grep gdm 5485 0.0 0.1 1461556 8504 ? Ssl 20:59 0:00 /usr/bin/pulseaudio --daemonize=no myusername 6144 8.6 0.2 2582908 19308 ? S<sl 21:50 1:16 /usr/bin/pulseaudio --daemonize=no $ pulseaudio -k $ ps aux | grep pulse | grep -v grep gdm 5485 0.0 0.1 1461556 8504 ? Ssl 20:59 0:00 /usr/bin/pulseaudio --daemonize=no myusername 6559 3.6 0.2 1910808 17144 ? S<sl 22:06 0:00 /usr/bin/pulseaudio --daemonize=no Killing the gdm-owned pulseaudio process also results in a respawn. Version-Release number of selected component (if applicable): pulseaudio-11.1-18.fc28 How reproducible: Consistent Steps to Reproduce: 1. Add "autospawn = no" to /etc/pulse/client.conf 2. Kill pulseaudio with "pulseaudio -k" Actual results: Pulseaudio automatically respawns a new process. Expected results: No new pulseaudio process is spawned Additional info:
pulseaudio in f28+ doesn't use autospawn, so that's why setting that parameter has no effect. pulseaudio now uses systemd activation, so... if you don't want that, do: systemctl disable pulseaudio
Indeed, examining the RPM reveals that Systemd unit files have been installed on my system. There are however no links to the unit files in /etc/systemd, which is why I didn't find any pulseaudio service when listing with systemctl: find /etc/systemd/ -name pulse* systemctl list-unit-files | grep pulseaudio Both return no hits. However: find /usr/lib/systemd | grep pulseaudio.service /usr/lib/systemd/user/pulseaudio.service Is this a bug? Or am I supposed to activate the systemd service manually? What links do I need to create in order to control pulseaudio with Systemd? And how is pulseaudio even started without any reference in /etc/systemd?
These user services are (should be!) enabled by default, you should not need to activate anything manually. I'm not sure of the best answer for the "/usr/lib/systemd vs /etc/systemd" issue in this context, but maybe a good question for some systemd-related mailing list.