USER@.SERVICE(5)

👑 USER@.SERVICE(5) — bestie edition 💅

okay so this is the man page for user@.service, user-runtime-dir@.service and systemd-user-runtime-dir, aka the system units that start the user manager. yes that's the whole NAME vibe, and yes we're about to get into it 🫶

---

✨ SYNOPSIS ✨

user@UID.service

user-runtime-dir@UID.service

/usr/lib/systemd/systemd-user-runtime-dir

user-UID.slice

---

🌸 DESCRIPTION 🌸

so basically the systemd(1) system manager (that's PID 1, the main character of your whole boot) starts up user manager instances as user@UID.service, and it uses the user's numerical UID as the instance identifier. these instances run the same executable as the system manager, but they're in a mode where they start a different set of units. each systemd --user instance manages its own lil hierarchy of units that's specific to that user. if you want the full discussion of units, go read systemd(1), and if you want the list of units that form the basis of the unit hierarchies for both system and user units, that's systemd.special(7). iykyk 📚

user@UID.service rolls with a buddy system unit called user-runtime-dir@UID.service, which creates the user's runtime directory /run/user/UID when it starts up, and removes it when it's stopped. it also might apply runtime quota settings on /tmp/ and/or /dev/shm/ for that user. user-runtime-dir@UID.service executes the systemd-user-runtime-dir binary to do the actual work — it's the muscle behind the operation 💪

user processes may be started by the user@.service instance, and in that case they're part of that unit in the system hierarchy. they may also be started elsewhere, like by sshd(8) or a display manager like gdm, and in that case they form a .scope unit (peep systemd.scope(5)). both user@UID.service and the scope units get collected under user-UID.slice. 🎀

and the individual user-UID.slice slices get collected under user.slice, see systemd.special(7).

---

💖 CONTROLLING RESOURCES FOR LOGGED-IN USERS 💖

🌈 the levels, explained

options that control resources available to logged-in users can be configured at a few different levels. as described in the previous section, user.slice contains processes of all users, so any resource limits on that slice apply to everybody together. the usual way to configure them would be through drop-ins, like /etc/systemd/system/user.slice.d/resources.conf. 🫶

the processes of a single user are collected under user-UID.slice. resource limits for that user can be configured through drop-ins for that unit, like /etc/systemd/system/user-1000.slice.d/resources.conf. but if the limits should apply to all users instead, they may be configured through drop-ins for the truncated unit name, user-.slice. for example, configuration in /etc/systemd/system/user-.slice.d/resources.conf is included in all user-UID.slice units — and if you want the full tea on how the drop-in mechanism works, that's in systemd.unit(5). ☕

🔐 the PAM of it all

when a user logs in and a .scope unit is created for the session (see previous section), the creation of the scope may be managed through pam_systemd(8). this PAM module communicates with systemd-logind(8) to create the session scope and provide access to hardware resources. resource limits for the scope may be configured through the PAM module configuration, see pam_systemd(8). configuring them through the normal unit configuration is also possible, but since the name of the slice unit is generally unpredictable, this is less useful. ngl, kind of chaotic of you if you try it that way 🙈

🧚 the general rule

in general any resources that apply to units may be set for user@UID.service and the slice units discussed above, see systemd.resource-control(5) for an overview. that's the whole vibe.

---

🌟 EXAMPLES 🌟

Example 1. Hierarchy of control groups with two logged in users

$ systemd-cgls
Control group /:
-.slice
├─user.slice
│ ├─user-1000.slice
│ │ ├─user@1000.service
│ │ │ ├─pulseaudio.service
│ │ │ │ └─2386 /usr/bin/pulseaudio --daemonize=no
│ │ │ └─gnome-terminal-server.service
│ │ │   └─init.scope
│ │ │     ├─ 4127 /usr/libexec/gnome-terminal-server
│ │ │     └─ 4198 zsh
│ │ ...
│ │ └─session-4.scope
│ │   ├─ 1264 gdm-session-worker [pam/gdm-password]
│ │   ├─ 2339 /usr/bin/gnome-shell
│ │   ...
│ │ ├─session-19.scope
│ │   ├─6497 sshd: zbyszek [priv]
│ │   ├─6502 sshd: zbyszek@pts/6
│ │   ├─6509 -zsh
│ │   └─6602 systemd-cgls --no-pager
│ ...
│ └─user-1001.slice
│   ├─session-20.scope
│   │ ├─6675 sshd: guest [priv]
│   │ ├─6708 sshd: guest@pts/6
│   │ └─6717 -bash
│   └─user@1001.service
│     ├─init.scope
│     │ ├─6680 /usr/lib/systemd/systemd --user
│     │ └─6688 (sd-pam)
│     └─sleep.service
│       └─6706 /usr/bin/sleep 30
...

so let's decode this masterpiece 💅 the user with UID 1000 is logged in using gdm (session-4.scope) and ssh(1) (session-19.scope), and also has a user manager instance running (user@1000.service). the user with UID 1001 is logged in using ssh (session-20.scope) and also has a user manager instance running (user@1001.service). those are all (leaf) system units, and they form part of the slice hierarchy, with user-1000.slice and user-1001.slice below user.slice. user units are visible below the user@.service instances (pulseaudio.service, gnome-terminal-server.service, init.scope, sleep.service). it's giving organized. it's giving hierarchy. ✨

Example 2. Default user resource limits

$ systemctl cat user-1000.slice
# /usr/lib/systemd/system/user-.slice.d/10-defaults.conf
# ...
[Unit]
Description=User Slice of UID %j
After=systemd-user-sessions.service

[Slice]
TasksMax=33%

the user-UID.slice units by default do not have a unit file. the resource limits are set through a drop-in, which can be easily replaced or extended following standard drop-in mechanisms discussed in the first section. no unit file, just drop-in energy 🎀

---

🦋 SEE ALSO 🦋

systemd(1), systemd.service(5), systemd.slice(5), systemd.resource-control(5), systemd.exec(5), systemd.special(7), capsule@.service(5), pam(8)

---

and that's the whole page bestie, go forth and manage your users 💜

mwah 💋 this was systemd 262.1, and you just read USER@.SERVICE(5) — stay iconic, stay collected under user.slice 👑