Talk:Systemd/User

Starting services using a display manager

I had a hard time trying to use systemd --user with a display manager. I use Slim, so I just put systemd --user & in my ~/.xinitrc just before starting my WM (Awesome). Systemd started but nothing else happened. In fact I had to create a default.target file in ~/.config/systemd/user/ containing only

[Unit]
AllowIsolate=yes

and then enable services provided that each file contains

[Install]
WantedBy=default.target

Then all went well, systemd --user launch a dbus user session and all enabled service.

I think the important part is the default.target file, which is documented in Systemd/User#Using /usr/lib/systemd/systemd --user To Manage Your Session but not at all talked about in the previous sections. I'm not sure how to add this to the wiki, or even if my method is the right way to do it using a DM, So I prefer discuss this on this page. Ianux (talk) 17:57, 14 September 2013 (UTC)

Passing DBUS_SESSION_BUS_ADDRESS to session

After setting variable in /etc/systemd/system/user@.service.d/dbus.conf it is present in systemd --user (and its services) environment, as can be verified by systemctl --user show-environment, but how is it exactly passed to session processes? Pmartycz (talk) 14:20, 4 July 2015 (UTC)

It isn't, because systemd --user runs outside the user session. The default /etc/X11/xinit/xinitrc.d/30-dbus.sh starts another bus exclusively for the X session. -- Lahwaacz (talk) 14:43, 4 July 2015 (UTC)

I thought the intent of this guide was to setup a single "user" bus shared by all user sessions (X, text, remote SSH logins) and by systemd --user, wasn't it? Pmartycz (talk) 18:16, 4 July 2015 (UTC)

The first paragraph of Systemd/User#D-Bus explains the purpose. There are multiple different ways which will all "work" in certain cases. The current recommended way seems to be having multiple user buses, but in the future, as grawity indicated below, there will be only a single bus. If you want to see if the single bus aproach works for you, just export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$UID/bus from your shell startup file and make sure that /etc/X11/xinit/xinitrc.d/30-dbus.sh is not run. -- Lahwaacz (talk) 18:48, 4 July 2015 (UTC)

Somehow it wasn't clear to me. Anyway, I think the best place for setting this variable would be somewhere in PAM. Pmartycz (talk) 21:02, 4 July 2015 (UTC)

On a kdbus system, pam_systemd would set it for you. --grawity (talk) 16:06, 4 July 2015 (UTC)

Simplifying the Xorg and Systemd section

Why doesn't the Systemd/User#Xorg_and_systemd just use the startx wrapper program? I set up a service file like this and it seems to work just fine:

~/.config/systemd/user/xorg.service

[Unit]
Description=Xorg server

[Service]
Type=simple
SuccessExitStatus=0 1

ExecStart=/usr/bin/startx

This seems a lot simpler than the configuration described. Sorry if this is a dumb question! Siddharthist (talk) 02:49, 9 May 2016 (UTC)

Variable expansion implied by Service example

The example under the Service example section implies that variable expansion will work in a systemd unit, however, from my understanding and experience this is not the case and so the PATH variable would not be extended as it might seem. Flungo (talk) 19:49, 28 August 2016 (UTC)

Expansion of variables works in systemd units, see systemd.service(5) § COMMAND_LINES. It's just that $PATH in the systemd unit is not the same as $PATH in the shell, most notably the value does not propagate automatically from the shell into systemd. This is what Systemd/User#Environment_variables is all about. -- Lahwaacz (talk) 13:49, 12 September 2016 (UTC)

The referenced example implied that variable expansion worked within Environment lines. It only works within Command lines, per the linked manpage. And even then it only works as a bare word, like /bin/true $FOO bar. To use within a word it must be wrapped in curlies, like PATH=${FOO}:/bin. I updated the example to remove the variable reference. Sj26 (talk) 15:51, 11 March 2017 (UTC)

user@userid.service.d drop-ins

Since I'm researching ways to pass environment variables to systemd --user I found out you can actually create a drop-in directory for a specific userid (eg /etc/systemd/system/user@1000.service.d/. I thought about mentioning it in the page, but I am not sure it is good practice. What do you think? Farsil (talk) 22:15, 6 December 2016 (UTC)

One use case is when a user install (user) packages from some source. In that case, the drop-in ability might has the same advantages, and disadvantages, as in the system case. Regid (talk) 14:48, 9 August 2020 (UTC)

Setting up DISPLAY variable for systemd-user unit under Wayland session

On Wayland session (notably Weston), the /etc/X11/xinit/xinitrc.d/50-systemd-user.sh is not parsed, so that systemd-user units don't aware of the DISPLAY environment variable.

User need to run systemctl --user import-environment DISPLAY WAYLAND_DISPLAY so that systemd user service can make use of the variable.

Alive4ever (talk) 13:14, 13 April 2017 (UTC)

Why do you need DISPLAY in Wayland? -- Lahwaacz (talk) 09:00, 13 April 2017 (UTC)

Because most GUI applications, such as web browsers, don't have complete Wayland support and therefore needs DISPLAY environment variable to run under Xwayland.

Real use case is gpg-agent systemd user service need to know DISPLAY to invoke proper pinentry gui to ask for passphrase.

ssh-agent is also another case, where it needs to know DISPLAY to invoke ssh-askpass.

Alive4ever (talk) 13:14, 13 April 2017 (UTC)

I'd say that counts as a "non-standard way of starting X", in which case the section implies that you should run the /etc/X11/xinit/xinitrc.d/50-systemd-user.sh script manually or incorporate it into your way of starting X. -- Lahwaacz (talk) 14:13, 13 April 2017 (UTC)

User-specific environment.d files

Regarding [1], the environment.d(5) manual shows that user-specific files in ~/.config/environment.d/*.conf are parsed as well, so writing a script should not be necessary. -- Lahwaacz (talk) 17:20, 10 September 2017 (UTC)

I think generators are used for complex scripts and ~/.config/environment.d/*.conf are used for simple key=value pare. So both of them should be mentioned. --Fengchao (talk) 09:40, 14 November 2022 (UTC)

Reloading the systemctl daemon

I was having trouble creating a custom init file, I wasn't being able to start it after creating it, It is because you're supposed to reload systemctl's daemon to notify it of the new unit file[2]. I coulnd't find it on the page, nor a good place to put it. Do you think it's a good addition? Where to put it? Samosaara (talk) 13:58, 7 January 2018 (UTC)

I added a link to systemd#Writing unit files which explains the general stuff. For user units, you just add --user to systemctl. -- Lahwaacz (talk) 21:21, 7 January 2018 (UTC)

That is not what I meant, I know that, but when you edit the files you need to restart systemctl's daemon to notify it of the new unit file with

systemctl --user daemon-reload

as stated in the RHEL manual[3], section 9.6.2 part 4 Samosaara (talk) 11:34, 8 January 2018 (UTC)

The page I linked says:

For both methods, you must reload the unit afterwards to apply your changes. This can be done either by editing the unit with systemctl edit (which reloads the unit automatically) or by reloading all units with:

# systemctl daemon-reload

Add --user to that and you're good to go.

-- Lahwaacz (talk) 12:15, 8 January 2018 (UTC)

Kill user processes on logout

Unfortunately, the commands described in this section no longer work. They may have worked in the past, but past is past. Here's a StackExchange thread about that; especially the latest comments are relevant. (This is in no way specific to ArchLinux.)

On one hand, I want KillUserProcesses=yes and KillExcludeUsers= in my logind.conf, no matter what, because I don't see a reason why any leftover processes should be left alive, root or not. This applies especially to KDE-related process mess left behind after logout, which may prevent you (or even your fellow users) from starting KDE again, until and unless you manually kill the leftover processes. So, systemd's automated process killing looks like a great idea up to this point.

On the other hand, for screen and tmux, the systemd-run --scope --user ... trick just doesn't work any more; the processes are killed ~30 seconds after logout or whatever the timeout is.

So, one would be tempted to set loginctl enable-linger <user>, hoping that it would solve the problem, i.e., maybe leave user-level systemd services running and kill other leftover processes (or the like). Well, that's not how this works. What enable-linger does basically voids the process killing settings in logind.conf for that particular user, so while your screen and tmux sessions will now survive just fine (phew!), so will the messy processes left behind by a misbehaving desktop environment after logout (argh!).

In summary, I have no clue what the correct solution would be in this case. My level of frustration reached a point at which I thought I'd just rant about it a little bit. 😝

Andrej (talk) 21:34, 25 September 2020 (UTC)

Your conclusion is wrong. If you have KillUserProcesses=yes and loginctl enable-linger <user>, the process killing applies exactly the same way as without lingering: all processes in the session scope being terminated are killed. If something persists on your system, it must be running outside of the session scope. -- Lahwaacz (talk) 08:12, 26 September 2020 (UTC)