4

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}="[email protected]"

I'm using this as my systemd unit:

/etc/systemd/system/[email protected]:

[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?

Improve this question
4
  • 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. Commented Jan 17, 2017 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? Commented Jan 17, 2017 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. Commented Jan 17, 2017 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. Commented Jan 17, 2017 at 18:36

1 Answer 1

Reset to default
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?

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.