6

I've setup a systemd service file to perform some pactl operations at system startup for a test process. While the commands work fine when performed from a terminal I always get "pa_context_connect() failed connection refused" when running the same script from the systemd service by starting the service. I'm also using the 'User=' directive in the service file to ensure that the auto-login user matches the user used to run the service commands.

I've read that this is somehow related to the pulseaudio session not being valid in the environmentless context of the systemd service but I haven't been able to figure that out further.

Chris Morgan
  • 1,277
  • 1
  • 13
  • 33

1 Answers1

9

Although it might be a bit late for whatever project you might have been be working on, here's what I found out.

The regular systemctl, the PID 1, indeed cannot access the environement variables of the current user when launching a service. Since pactl relies on those variables to find what instance of pulseaudio it needs to connect to, it is unable to do so when launched though a service. I'm sure there's a fairly dirty workaround for this, but I found something better.

Most systems have a second instance of systemd running in userspace (accessible through systemctl --user while not connected as root). This instance indeed can access all the userspace environment variables and I found that pactl doesn't return any errors when being called either directly or through a script.

All you need to do is put your services in either /usr/lib/systemd/user/, /etc/systemd/user/, or ~/.config/systemd/user/, remove the User= directive from your service file and run systemctl --user daemon-reload as a regular user to make sure they've been detected.

Santo Guevarra
  • 385
  • 4
  • 8
  • what does this mean `put your services in either`? which files exactly need to be moved there to achieve this? – Bassie Dec 06 '21 at 11:00
  • @Bassie that would be the `.service` file that contains your service definition. You also need to make sure that when you're enabling/starting your service that you don't use `sudo systemctl`, instead use `systemctl --user`, e.g. `systemctl --user enable myservice.service` – Mike Goatly Apr 04 '22 at 21:12