3

I'm on Ubuntu 16.04, and I've just developed this piece of software which automates PulseAudio hotplug events.

I'm currently using the following udev rule:

/etc/udev/rules.d/90-autopulse.rules:

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0d8c", ATTRS{idProduct}=="1066", ENV{SYSTEMD_WANTS}="autopulse@naftuli.service"

I'm using this as my systemd unit:

/etc/systemd/system/autopulse@.service:

[Unit]
Description=PulseAudio Hotplug Service

[Service]
Type=oneshot

Environment=DISPLAY=:0
User=%i
ExecStart=/usr/local/bin/autopulse switch
StandardOutput=journal

I unfortunately need to manually set DISPLAY=:0, though there's no guarantee that I'll be that given X session.

Is there a way to configure udev or systemd to pull the DISPLAY variable for a given user and use that in the environment? Or am I stuck hardcoding it?

I suppose I could do an ExecStartPre or something to discover it, or perhaps adjust my script. What are my options purely in udev and systemd?

  • According to systemd.device, there is a SYSTEMD_USER_WANTS, but documentation is sorely lacking. Also, it should be possible within my program to use /usr/bin/w to find the X display for a given user, but it doesn't count as being part of systemd. – Naftuli Kay Jan 17 '17 at 6:37
  • How's your program supposed to work on systems with several seats? Or system without a monitor (headless)? Maybe it's better to split the program into a backend started by systemd, and a frontend that can be started by (each) user on logon? – dirkt Jan 17 '17 at 8:54
  • @dirkt It's not meant for multiseat, it's meant for multiple user desktop sessions. I have no guarantee that my user will be at display :0 as opposed to :1, etc. Most distros maintain different X sessions per logged in user. – Naftuli Kay Jan 17 '17 at 18:27
  • My point was that it's not a good idea to rely on a single system service when there's no guarantee that there's actually an X session active, or when there can be many sessions active. If you need something that's guaranteed to have a valid DISPLAY, start it when the X session is started (from the display manager, .xsession, or whatever), and not from systemd. Systemd (or at least the init system that it's supposed to replace) is for system-wide services. – dirkt Jan 17 '17 at 18:36
0

systemd also provides user services that are started when a user login (compared to the system ones that are enabled at boot), you should probably look at that.

But I'm not sure that you can start them them using udev rules, your software should maybe start as a user daemon and listen to the udev events and act accordingly?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.