User Manager

[Trevor]

systemd is the system manager.  What exactly is the
user manager?

[Sunnykumar1]

@Trevor 

The user manager (systemd --user) controls user-level services that run in the context of a specific user.

It manages user units such as services, timers, sockets, and mounts.

It runs without root privileges.

Unit files are located in:

~/.config/systemd/user/

/etc/systemd/user/

/usr/lib/systemd/user/

[Trevor]

Thanks for that response Sunny.

Got another query: 

I know that the kernel runs systemd, as PID 1.
What is responsible for running systemd --user?
What PID gets assigned when systemd --user?

[Travis]

@Trevor -

PIDs are more random. The only guaranteed PID is the first one. Each process when started will have a unique PID, and if the process gets restarted, it will get a new PID. 

As for what makes systemd --user work ... that is a little more complex.

Obviously SystemD does a lot of the work, but specifcally you need to have a few other pieces in the background working. pam_systemd, systemd-logind and the actual user@whatever.service.

What makes this work though is you need to use loginctl enable-linger <username> to make the service active and. enable things to start at boot. This eliminates the need for <username> to be logged in and will start the service like a regular SystemD service at boot time. This is why we taught how to make containerized services and showed loginctl with enable-linger in the older RHCSA course.

[Chetan_Tiwary_]

@Trevor you have a fast n furious start to 2026 ! 

As @Travis mentioned clearly, PIDs are random.

Let me rewind a bit, besides the main system wide instance of systemd, a separate user instance starts up every time a person logs into the system. This allows you to create and run your own services with almost all the same features as system wide units, but with a few specific rules.

First, your user session starts automatically the moment you log in. It stays active as long as you have at least one session open like a terminal or a desktop window and shuts down as soon as your last session closes.

Second, these units run with your specific accont permissions. This means you cannot use them to run tasks as a different user or perform root kind of  actions. Finally, because these services are tied to your account, your ability to limit hardware resources (like CPU or RAM) might be more restricted than what the system administrator can do. It is a great way to manage personal tools without needing "sudo" access for everything.

Think of the user manager as your own personal version of systemd. While the main system manager (PID 1) handles the whole computer, it also spawns a specific instance just for you whenever you log in. This instance runs as a service called user@UID.service, using your unique ID number to keep things organized.

Even though it uses the same core software as the system manager, it operates in a special "user mode" Instead of managing hardware or system wide tasks, it handles a set of units and services that belong strictly to your account.

To make this work, systemd also starts a helper service called user-runtime-dir@UID.service. This service has two main jobs:

The Workspace: It creates a temporary folder at /run/user/UID where your personal programs can store data while you are logged in.

The Cleanup: When you log out, it wipes that folder clean and can even manage limits on how much memory or temporary space you are allowed to use.

https://www.freedesktop.org/software/systemd/man/latest/user@.service.html 

[Chetan_Tiwary_]

@Trevor one more thing - adding to what @Travis already mentioned , 

Normally, the user manager only starts up when you log in whether you are using a console, SSH, or a GUI. The moment you log out, that manager shuts down along with any services it was running.

If you need your personal services to stay running in the background even when you arenot logged in, you can turn on a feature called lingering.

You do this with a quick command: loginctl enable-linger <username>

Once you enable this, your user manager starts as soon as the system boots up and stays active until the computer is turned off. It is perfect for running small home servers or automation scripts that need to be "always on" without keeping a terminal window open.

[Trevor]

Chetan,

Let's focus on this piece that you mentioned in your last
response, "...a separate user instance starts up every time
a person logs into the system."   What exactly is responsible
for starting this separate user instance each time a user logs
into the system?  Tell me that, and I've got my answer.

Can't believe that I asked that question in the manner that I
did, regarding the assignment of the PID to systemd --user.
I'm going to give myself a get-out-of-jail-free card, and claim
temporary insanity.  Ouch!!!

[Trevor]

Travis, 

Are you saying pieces like pam_systemd, systemd-logind and the actual user@whatever.service, are examples of what can/will
kickoff systemd --user?   I'm trying to nail down something as
specific as the kernel kicking off systemd.

I shouldn't have asked 'What PID gets assigned when
systemd --user is run".  That's the equivalent of asking for the
PID that will be assigned to a process in advance of the process
being kicked off - we'd all stand a better chance of guessing the
winning lottery numbers each week for the remainder of 2026!!!  

Thanks for your previous response!!!

[Travis]

@Trevor -

Yes. Those pieces all work together. I guess technically the systemd-logind would be what would actually kick it off if you had to pick one, but if the other items aren't there and setup correctly it won't work.

The loginctl enable-linger will cause the system to set the user as "there" and will kick off the user services that are set on boot. If LINGER isn't set, the services won't start until that user logs into the system and when the user logs out the system will stop. So it is just like SystemD with all "system-level" services. SystemD starts at boot with the system and all system-level services start. A user service starts when a USER logs in, however, loginctl enable-linger will be equivalent to systemctl --enable for a system service so a user doesn't need to be interactively logged in and SystemD will also kick off the user services. But again, multiple components are needed to be there to work together.