Writing a service that depends on Xorg

Question

I'm trying to write a user level service for redshift, and it needs to wait until Xorg is up and running. My current service file looks like this:

[Unit]
Description=Redshift
After=graphical.target

[Service]
Environment=DISPLAY=:0
ExecStart=/bin/redshift -l 28:-13 -t 5300:3300 -b 0.80:0.91 -m randr
Restart=always

[Install]
WantedBy=default.target

However, it seems that it attempts to start before Xorg is up, and I have to manually start the service afterwards. I guess I'm using the wrong After= target. Any hints?

score 52 · Accepted Answer · edited May 21 '20 at 15:17

I've been researching this and grawity's answer seems out of date. You can now setup user services with systemd that run with as part of the user's session. They can have DISPLAY and XAUTHORITY set (currently in Arch, Debian Stretch+ and Ubuntu).

This makes sense over the previous recommendations of using desktop autostart files, as you get process management just like you would a system level app (restart, etc).

Best docs right now is the Arch wiki; Systemd/User

TLDR version;

Create desired *.service file in ~/.config/systemd/user/
Run systemctl --user enable [service] (exclude .service suffix)
Optionally run systemctl --user start [service] to start now
Use systemctl --user status [service] to check how it's doing

A couple other useful commands.

systemctl --user list-unit-files - view all user units
systemctl --user daemon-reload - if you edit a .service file

-- Later...

I upgraded and converted most of my session daemons to systemd .service files. So I can add a couple of additional notes.

There was no default hook to run the services at login, so you must trigger it yourself. I do it from my ~/.xsession file.

systemctl --user import-environment PATH DBUS_SESSION_BUS_ADDRESS
systemctl --no-block --user start xsession.target

The first line imports some environment variables into the systemd user session and the second kicks off the target. My xsession.target file;

[Unit]
Description=Xsession running
BindsTo=graphical-session.target

My xbindkeys.service as an example.

[Unit]
Description=xbindkeys
PartOf=graphical-session.target

[Service]
ExecStart=/usr/bin/xbindkeys -n -f ${HOME}/projects/dotfiles/.xbindkeysrc
Restart=always

[Install]
WantedBy=xsession.target

score 11 · Answer 2 · edited Mar 20 '17 at 10:17

The usual hint is "don't". redshift is not a system-wide service – it would have a separate instance for each session, and it needs to know about how to connect to that specific session's Xorg.

(Xorg isn't a system service either – only the display manager is, and it also launches a separate Xorg for each session. // graphical.target will tell you when the display manager is ready, but it says nothing about when the DM actually starts the first – or all – displays.)

Just starting it on boot with DISPLAY=:0 is not enough, for there is no guarantee that there's exactly one display at any given time, nor that it is always :0 (for example, if Xorg crashes leaving a stale lockfile, the next one would run at :1 as it would think :0 is still occupied); you also need to set the path to your XAUTHORITY file as X11 requires authentication; and make sure redshift gets restarted if you ever log out & log in again.

So how to start it? Almost always, the desktop environment has several methods of starting its own session services. See an older post which already describes the two usual ones; the ~/.xprofile script and the ~/.config/autostart/*.desktop location.

If you use startx, you can use ~/.xinitrc to start such things. Standalone window managers often have their own startup/init scripts; e.g. ~/.config/openbox/autostart for Openbox.

What's common to all these methods is that the program is started from within the session – avoiding all the problems listed above.

score 5 · Answer 3 · answered Jan 05 '17 at 14:53

Here is what I just created as workaround to the not yet available graphical-session.target (On my Kubuntu 16.04 system):

Create a pseudo systemd user unit which brings the graphical-session.target up and down.

Create ~/.config/systemd/user/xsession.target with following contents:

[Unit]
Description = Xsession up and running
BindsTo=graphical-session.target

Tell systemd about this new unit:

$> systemctl --user daemon-reload

Create autostart and shutdown scripts which controls the xsession.target via the currently available mechanics of the Ubuntu 16.04 desktop.

Create ~/.config/autostart-scripts/xsession.target-login.sh with following contents:

#!/bin/bash

if ! systemctl --user is-active xsession.target &> /dev/null
then
  /bin/systemctl --user import-environment DISPLAY XAUTHORITY
  /bin/systemctl --user start xsession.target
fi

Create ~/.config/plasma-workspace/shutdown/xsession.target-logout.sh with following contents:

#!/bin/bash

if systemctl --user is-active xsession.target &> /dev/null
then
  /bin/systemctl --user stop xsession.target
fi

Make the scripts executable:

$> chmod +x ~/.config/autostart-scripts/xsession.target-login.sh
$> chmod +x ~/.config/plasma-workspace/shutdown/xsession.target-logout.sh

Note: these two files are placed where KDE will pick them up for autostart and shutdown. The files maybe placed somewhere else for other desktop environments (e.g. Gnome) - but I don't know about those environments.

Note: This workaround lacks support of multi desktop sessions. It only handles the graphical-session.target correctly as long as only one active X11 session is run on a machine (but that's the case for most of us linux users).

Create your own systemd user units which depend on graphical-session.target and have them run cleanly while being logged in on your desktop.

As example @mkaito's unit should look like this:

[Unit]
Description=Redshift
PartOf=graphical-session.target

[Service]
ExecStart=/bin/redshift -l 28:-13 -t 5300:3300 -b 0.80:0.91 -m randr
Restart=always

(Don't forget to do a daemon-reload after editing your units!)

Reboot your machine, login and verfiy your units are started as expected

$> systemctl --user status graphical-session.target
● graphical-session.target - Current graphical user session
   Loaded: loaded (/usr/lib/systemd/user/graphical-session.target; static; vendor preset: enabled)
   Active: active since Don 2017-01-05 15:08:42 CET; 47min ago
     Docs: man:systemd.special(7)
$> systemctl --user status your-unit...

At some future day (will it be Ubuntu 17.04?) my workaround become obsolete since the system will handle the graphical-session.target correctly itself. At that day just remove the autostart and shutdown script and also the xsession.target - your custom user units may stay untouched and just work.

VL-80 · Answer 4 · 2022-01-22T00:23:38.110

This solution does exactly what the author of the question asks:

it needs to wait until Xorg is up and running

While there could be better ways of doing it, as already answered by other users, this is another approach to this problem.

It is similar to systemd's systemd-networkd-wait-online.service which blocks until certain criteria are met. Other services which depend on it will be launched as soon as this service starts successfully or times out.

Per the manual (section "Files"), X server will create a UNIX socket /tmp/.X11-unix/Xn (where n is a display number).

By monitoring presence of this socket we can determine that the server for particular display has started.

confirm_x_started.sh:

#!/bin/bash
while [ 1 ]
do
Check whether or not socket exists
if [ -S /tmp/.X11-unix/X0 ]
  then
    exit 0
  fi
Adjust timeout according to your needs
if [ $SECONDS -gt 15 ]
  then
    exit 1
  fi
sleep 0.5
done

x_server_started.service:

[Unit]
Description=Monitor X server start
[Service]
Type=oneshot
ExecStart=/path/to/confirm_x_started.sh
[Install]
WantedBy=example.target

Now, enable x_server_started.service to start at the same time with the X server.

Make other services (which need X server to be started) to depend on x_server_started.service

dependent unit:

[Unit]
Description=Service that needs to have the X server started
Requires=x_server_started.service
After=x_server_started.service
[Service]
ExecStart=/path/to/binary
[Install]
WantedBy=example.target

If X server starts without a problem, the x_server_started.service will start almost immediately and systemd will proceed to start all units that are dependent on x_server_started.service.

lanoxx · Answer 5 · 2024-04-18T06:38:00.223

A lot of answers imply that some workarounds or scripts are necessary. At least on a recent GNOME session I do no longer need such workarounds.

If I add WantedBy=graphical-session.target then the necessary X11 environment variables (i.e., DISPLAY and XAUTHORITY) are available to the service and I can execute an X11 program in my user service file:

[Unit]
...
PartOf=graphical-session.target
[Service]
...
[Install]
WantedBy=graphical-session.target

As I understand it, the graphical-session.target is a passive target. Using it implies that the actual session which is being started bind to this target via BindsTo=graphical-session.target. For the gnome-session.target this seems to be the case but it might not be the case for the older or less popular desktop environments.

I found it helpful to inspect the user journal journalctl --user -b which prints which targets are reached in which order:

May 08 21:28:10 earth systemd[2481]: Reached target GNOME printer notifications target.
May 08 21:28:10 earth systemd[2481]: Reached target GNOME Session.
May 08 21:28:10 earth systemd[2481]: Reached target GNOME X11 Session (session: gnome-flashback-metacity).
May 08 21:28:10 earth systemd[2481]: Reached target Current graphical user session.

The log outputs the target's description and we can use the following command to identify the actual target names:

systemctl --user list-units --type target

See also: https://www.freedesktop.org/software/systemd/man/systemd.special.html#Special%20Passive%20User%20Units

score 1 · Answer 6 · answered Apr 22 '24 at 20:44

This may not be quite the mechanism you envisioned but it might accomplish what you need. It works on Fedora 39 (Gnome 45), and just requires a short file to be written by hand.

I wanted to disable the touchpad on my ThinkPad T470p. After determining the command I needed to run (the xinput command shown) I simply created the following file, logged out and logged in again, and it ran.

Along the way I discovered that some characters (such as >) are not accepted in this file so you may need to create a shell script even for a simple command, and run that shell script instead.

I also found that environment variable $DISPLAY is set correctly.

~myname/.config/autostart/disableTouchPad.desktop:

[Desktop Entry]
Name=DisableTouchPad
Exec=/usr/bin/xinput disable 'SynPS/2 Synaptics TouchPad'
Terminal=false
Type=Application

I'm not sure if the Terminal and Type keywords are necessary or if other keywords are also advisable, but the above works.

The file name extension must be .desktop.

Finally, if you install gnome-tweaks (with the command sudo dnf install gnome-tweak-tool), run it, and go to Startup Applications, you'll see the startup application named as Name= (in this case, DisableTouchPad).

score 0 · Answer 7 · answered Apr 12 '24 at 04:36

Since ~v1.21, Xorg calls SystemD’s sd_notify on startup. So you can now just set Type=notify in [Service] for Xorg’s service file and SystemD will properly wait for Xorg to be started before it considers the service to be started. No more extra hacks needed.

score 0 · Answer 8 · answered Apr 22 '24 at 20:39

This may accomplish your goal, but via a slightly different mechanism. It runs on Fedora 39 (Gnome 45). We just make a short file by hand.

I wanted to disable the touchpad on my ThinkPad T470p. After determining the command I needed to run (the xinput command shown) I simply created the following file, logged out and logged in again, and it ran.

Along the way I discovered that some characters (such as >) are not accepted in this file so you may need to create a shell script even for a simple command, and run that shell script instead.

I also found that environment variable $DISPLAY is set correctly.

~myname/.config/autostart/disableTouchPad.desktop:

[Desktop Entry]
Name=DisableTouchPad
Exec=/usr/bin/xinput disable 'SynPS/2 Synaptics TouchPad'
Terminal=false
Type=Application

I'm not sure if the Terminal and Type keywords are necessary or if other keywords are also advisable, but the above works.

The file name extension must be .desktop.

Finally, if you install gnome-tweaks (with the command sudo dnf install gnome-tweak-tool), run it, and go to Startup Applications, you'll see the startup application named as Name= (in this case, DisableTouchPad).

score -1 · Answer 9 · answered Apr 05 '21 at 01:14

On "/usr/lib/systemd/user" place a service that includes:

[Service]
Environment=DISPLAY=:0
Environment=XAUTHORITY=/home/<user>/.Xauthority

If that alone doesn't work, make a script that waits the window manager to be up:

waitSuccess () {
    local command="${*}"
while ! ${command} &amp;&gt; /dev/null; do
    sleep 0.5
done

}
waitSuccess "xprop -root -notype _NET_SUPPORTING_WM_CHECK | grep --silent true"

Writing a service that depends on Xorg

9 Answers9

Check whether or not socket exists

Adjust timeout according to your needs

Linked