systemd/User

The user instance of systemd does not inherit any of the environment variables set in places like .bashrc etc. There are several ways to set environment variables for the systemd user instance:

• For users with a directory, create a .conf file in the directory with lines of the form . Affects only that user's user unit. See for more information.
• Use the option in file. Affects all user units.
• Add a drop-in configuration file in . Affects all user units; see #Service example
• At any time, use systemctl --user set-environment or . Affects all user units started after setting the environment variables, but not the units that were already running.
• Using the command provided by dbus. Has the same effect as , but also affects the D-Bus session. You can add this to the end of your shell initialization file.
• For "global" environment variables for the user environment you can use the directories which are parsed by some generators. See and systemd.generator(7) for more information.
• You can also write a script which can produce environment variables that vary from user to user, this is probably the best way if you need per-user environments (this is the case for , , etc).

One variable you may want to set is .

After configuration, the command can be used to verify that the values are correct.

Create the drop-in directory and inside create a file that has the extension .conf (e.g. ):

/etc/systemd/system/user@.service.d/local.conf

[Service]
Environment="PATH=/usr/lib/ccache/bin:/usr/local/bin:/usr/bin:/bin"
Environment="EDITOR=nano -c"
Environment="BROWSER=firefox"
Environment="NO_AT_BRIDGE=1"

is used by any X application to know which display to use and  to provide a path to the user's  file and thus the cookie needed to access the X server. If you plan on launching X applications from systemd units, these variables need to be set. Systemd provides a script in  to import those variables into the systemd user session on X launch.  So unless you start X in a nonstandard way, user services should be aware of the  and .

If you customize your and plan on launching applications that make use of it from systemd units, you should make sure the modified is set on the systemd environment. Assuming you set your in , the best way to make systemd aware of your modified is by adding the following to after the variable is set:

~/.bash_profile

systemctl --user import-environment PATH

Environment variables can be made available through use of the module. See Environment variables#Using pam_env for configuration details.

The systemd user instance is started after the first login of a user and killed after the last session of the user is closed. Sometimes it may be useful to start it right after boot, and keep the systemd user instance running after the last session closes, for instance to have some user process running without any open session. Lingering is used to that effect. Use the following command to enable lingering for specific user:

# loginctl enable-linger username

The following is an example of a user version of the mpd service:

~/.config/systemd/user/mpd.service

[Unit]
Description=Music Player Daemon

[Service]
ExecStart=/usr/bin/mpd --no-daemon

[Install]
WantedBy=default.target

The following is a user service used by , which takes into account variable home directories where Folding@home can find certain files:

As detailed in , the variable is replaced by the home directory of the user running the service. There are other variables that can be taken into account in the systemd manpages.

The journal for the user can be read using the analogous command:

$ journalctl --user

To specify a unit, one can use

$ journalctl --user-unit myunit.service

Or, equivalently:

$ journalctl --user -u myunit.service

This option will launch a system unit that will start a user session with an xorg server and then run the usual to launch the window manager, etc. You need to have installed. Set up your xinitrc as specified in the Xinit#xinitrc section.

The session will use its own dbus daemon, but various systemd utilities will automatically connect to the instance. Finally, enable the xlogin@username service for automatic login at boot. The user session lives entirely inside a systemd scope and everything in the user session should work just fine.

Alternatively, xorg can be run from within a systemd user service. This is nice since other X-related units can be made to depend on xorg, etc, but on the other hand, it has some drawbacks explained below.

provides integration with systemd in two ways:

• Can be run unprivileged, delegating device management to logind (see Hans de Goede commits around this commit).
• Can be made into a socket activated service (see this commit). This removes the need for .

Unfortunately, to be able to run xorg in unprivileged mode, it needs to run inside a session. So, right now the handicap of running xorg as user service is that it must be run with root privileges (like before 1.16), and cannot take advantage of the unprivileged mode introduced in 1.16.

This is how to launch xorg from a user service:

1. Make xorg run with root privileges for any user, by editing

2. Add the following units to

where ${XDG_VTNR} is the virtual terminal where xorg will be launched, either hard-coded in the service unit, or set in the systemd environment with

$ systemctl --user set-environment XDG_VTNR=1

3. Make sure to configure the environment variable as explained above.

4. Then, to enable socket activation for xorg on display 0 and tty 2 one would do:

$ systemctl --user set-environment XDG_VTNR=2     # So that xorg@.service knows which vt use
$ systemctl --user start xorg@0.socket            # Start listening on the socket for display 0

Now running any X application will launch xorg on virtual terminal 2 automatically.

The environment variable can be set in the systemd environment from , and then one could start any X application, including a window manager, as a systemd unit that depends on .

With an adapted version of sx, one can easily have all the X clients running as a user service while leaving Xorg, the server, running in a session unprivileged.

First, put a copy of under . The copy can be named e.g. so that the original can remain accessible.

Then, replace

trap 'DISPLAY=:$tty exec "${@:-$cfgdir/sxrc}" & wait "$!"' USR1

with

trap 'systemd-run --user -u sx-client-$tty -E DISPLAY=:$tty -E XAUTHORITY="$XAUTHORITY" \
      "${@:-$cfgdir/sxrc}" & wait "$pid"' USR1

and replace

(trap '' USR1 && exec Xorg :"$tty" -keeptty vt"$tty" -noreset -auth "$XAUTHORITY") & pid=$!

with

(trap '' USR1 && exec Xorg :"$tty" -keeptty vt"$tty" -terminate -auth "$XAUTHORITY") & pid=$!

The caveat of this approach is that, if for some reason not a single X client succeeded in reaching the server, the server will need to be killed from another tty manually. Also, if e.g. needs to be run in , it will now need to be run with the option -retain. See and for details.

One of the use cases and/or advantages of this approach is that the X clients will now be running under the user manager () and snippet (i.e. ) applied to it (e.g. ) will also be applied to the programs running in the graphical environment (including but not limited to the command-line shells running in an terminal emulator).

To run a window manager as a systemd service, you first need to run #Xorg as a systemd user service. In the following we will use awesome as an example:

You may wish your user session to default to running a terminal multiplexer, such as GNU Screen or Tmux, in the background rather than logging you into a window manager session. Separating login from X login is most likely only useful for those who boot to a TTY instead of to a display manager (in which case you can simply bundle everything you start in with ).

To create this type of user session, procede as above, but instead of creating , create multiplexer.target:

, like above, should start anything you think should run before tmux or screen starts (or which you want started at boot regardless of timing), such as a GnuPG daemon session.

You then need to create a service for your multiplexer session. Here is a sample service, using tmux as an example and sourcing a gpg-agent session which wrote its information to . This sample session, when you start X, will also be able to run X programs, since DISPLAY is set.

Once this is done, enable , multiplexer.target and any services you created to be run by and you should be set to go! Start user@.service as usual. Congratulations! You have a running terminal multiplexer and some other useful programs ready to start at boot!

systemd[1867]: pam_systemd(systemd-user:session): Runtime directory '/run/user/1000' is not owned by UID 1000, as it should.
systemd[1867]: Trying to run as user instance, but $XDG_RUNTIME_DIR is not set

If you see errors such as this and your login session is broken, it is possible that another system (non-user) service on your system is creating this folder. This can happen for example if you use a docker container that has a bind mount to . To fix this, you can either fix the container by removing the mount, or disable/delay the docker service.