As I'm kind of confused what the idea behind systemd's system and user units or services is, I'd like to ask for an explanation.

Specifically I had thought system units are for units that are part of the vendor's operating system, while user units are for customer's local add-ons.

But it seems user units are handled differently by systemd (e.g. systemctl daemon-reload does not affect any user units, while the manual page claims: "Reload the systemd manager configuration. This will rerun all generators (see systemd.generator(7)), reload all unit files, and recreate the entire dependency tree."), so it's not just some organizational structure, but a truly semantic one.

1 Answer 1


systemd runs a service manager for the system and a service manager for logged in users. System units can only be started/stopped by UID 0 and system services are run as UID 0 (except if you set User=), the user units can be started/stopped by the respective user and user services are run as the respective user.

To talk to the service manager of the user, use systemctl --user. In your example, you would have to call systemctl --user daemon-reload in order to reload the user units.

Note that user units cannot depend on system units and vice versa.

  • So these are two independent mechanisms (user and system), accidentally implemented by the same program (systemd)? If so, only the "system" part is a replacement for "good old" init, while the "user" part is a new mechanism that didn't exist before? -- Maybe @segfault can add some more clarifying words on that...
    – U. Windl
    May 6, 2019 at 7:36
  • "...*cannot depend on systemd units*..." should read "...*cannot depend on system units*...", I guess. Unfortunately such small edits are not allowed for me.
    – U. Windl
    Nov 11, 2021 at 12:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.