[BlueOnyx:25934] Re: Question about user@ Services?
Michael Stauber
mstauber at blueonyx.it
Tue Jan 17 09:34:45 -05 2023
Hi Dirk,
> I see on Blueonyx (5210R) machines that there are some user@ services
> for siteadmins.
>
> However, these are set to failed:
>
> Examples:
>
> ● user at 1005.service <mailto:user at 1005.service> loaded
> failed failed User Manager for UID 1005
>
> ● user at 1013.service <mailto:user at 1013.service> loaded
> failed failed User Manager for UID 1013
>
> This users are site admins:
>
> userone_admin:x:1005:1004:Some User one
> Admin:/home/.sites/site1/./home/users/userone_admin:/bin/bash
>
> usertwo_admin:x:1013:1007: Some User two
> Admin:/home/.sites/site4/./home/users/usertwo_admin:/bin/bash
>
> What are these services that are set to "loaded failed"? What do you
> need them for?
This is something that's built into Systemd and we don't touch that in
BlueOnyx. Basically it's like this: If a user has some form of shell
access and logs in for the first time, then Systemd automatically
creates a Systemd Unit File to handle the current (and future) shell
accesses of that user. Semantically this is not entirely correct, as
they all use the same Unit-File:
/usr/lib/systemd/system/user at .service
It's just aliased internally by Systemd to match all users that have
shell access and have used it at least once.
In the example below we see a 5210R that has actually four users with
shell access, but only user "root" and a user with the UID 1002 have
ever logged in by SSH. So only these two got their Systemd Unit file so far:
[root at 5210r ~]# systemctl |grep user@
user at 0.service
loaded active running User Manager for UID 0
user at 1002.service
loaded active running User Manager for UID 1002
Let us take a look what happens when user 1002 has logged in:
----------------------------------------------------------------------------
[root at 5210r ~]# systemctl status user at 1002.service
● user at 1002.service - User Manager for UID 1002
Loaded: loaded (/usr/lib/systemd/system/user at .service; static)
Active: active (running) since Tue 2023-01-17 09:05:01 -05; 5min ago
Docs: man:user at .service(5)
Main PID: 3066916 (systemd)
Status: "Ready."
Tasks: 2
Memory: 4.1M
CPU: 335ms
CGroup: /user.slice/user-1002.slice/user at 1002.service
└─init.scope
├─3066916 /usr/lib/systemd/systemd --user
└─3066917 "(sd-pam)"
Jan 17 09:05:01 5211r systemd[3066916]: Starting Create User's Volatile
Files and Directories...
Jan 17 09:05:01 5211r systemd[3066916]: Listening on D-Bus User Message
Bus Socket.
Jan 17 09:05:01 5211r systemd[3066916]: Reached target Sockets.
Jan 17 09:05:01 5211r systemd[3066916]: Finished Create User's Volatile
Files and Directories.
Jan 17 09:05:01 5211r systemd[3066916]: Reached target Basic System.
Jan 17 09:05:01 5211r systemd[3066916]: Reached target Main User Target.
Jan 17 09:05:01 5211r systemd[3066916]: Startup finished in 552ms.
Jan 17 09:05:01 5211r systemd[1]: Started User Manager for UID 1002.
Jan 17 09:07:36 5211r systemd[3066916]: Starting Mark boot as successful...
Jan 17 09:07:36 5211r systemd[3066916]: Finished Mark boot as successful.
----------------------------------------------------------------------------
Shortly after the user has logged out it will switch to this state:
----------------------------------------------------------------------------
[root at 5210r ~]# systemctl status user at 1002.service
○ user at 1002.service - User Manager for UID 1002
Loaded: loaded (/usr/lib/systemd/system/user at .service; static)
Active: inactive (dead)
Docs: man:user at .service(5)
Jan 17 09:11:22 5211r systemd[3066916]: Stopped Mark boot as successful
after the user session has run 2 minutes.
Jan 17 09:11:22 5211r systemd[3066916]: Stopped Daily Cleanup of User's
Temporary Directories.
Jan 17 09:11:22 5211r systemd[3066916]: Closed D-Bus User Message Bus
Socket.
Jan 17 09:11:22 5211r systemd[3066916]: Stopped Create User's Volatile
Files and Directories.
Jan 17 09:11:22 5211r systemd[3066916]: Removed slice User Application
Slice.
Jan 17 09:11:22 5211r systemd[3066916]: Reached target Shutdown.
Jan 17 09:11:22 5211r systemd[3066916]: Finished Exit the Session.
Jan 17 09:11:22 5211r systemd[3066916]: Reached target Exit the Session.
Jan 17 09:11:22 5211r systemd[1]: user at 1002.service: Deactivated
successfully.
Jan 17 09:11:22 5211r systemd[1]: Stopped User Manager for UID 1002.
----------------------------------------------------------------------------
So let us take a look at the Systemd Unit file in question:
----------------------------------------------------------------------------
/usr/lib/systemd/system/user at .service
# SPDX-License-Identifier: LGPL-2.1-or-later
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=User Manager for UID %i
Documentation=man:user at .service(5)
After=systemd-user-sessions.service user-runtime-dir@%i.service dbus.service
Requires=user-runtime-dir@%i.service
IgnoreOnIsolate=yes
[Service]
User=%i
PAMName=systemd-user
Type=notify
ExecStart=/usr/lib/systemd/systemd --user
Slice=user-%i.slice
KillMode=mixed
Delegate=pids memory
TasksMax=infinity
TimeoutStopSec=120s
KeyringMode=inherit
OOMScoreAdjust=100
----------------------------------------------------------------------------
Recall that back in the days of InitV and Upstart a regular user could
launch a process, shoot it into the background and it would keep running
even after the user logged out?
This is no longer possible the way Systemd handles stuff. At least not
out of the box. Systemd uses CGroup slices for everything related to
specific UIDs and once a user's sessions ends? Once the time set in
"TimeoutStopSec" runs out all processes that were initiated by this user
will end as well. The whole "slice" he's worked within will be taken
down - including all processes within it unless they were started "the
correct way" by using Systemd Unit-Files to launch them.
The mandatory killing of processes can optionally be prevented by
granting the user the privilege to have processes "linger" after logout:
#> loginctl enable-linger <username>
It is also possible to use this mechanism to define certain limits and
extra provisions to deal with users in general or to limit (or expand)
their abilities:
https://man7.org/linux/man-pages/man5/user@.service.5.html
And here is another link with some examples. These are for ArchLinux and
not RedHat, but some parallels exist and are applicable to RHEL clones
as well:
https://wiki.archlinux.org/title/Systemd/User
Like said: This mechanism is straight from the OS and we leave it all at
the default values, as we haven't yet found usage cases where
modifications of it would be useful for us.
--
With best regards
Michael Stauber
More information about the Blueonyx
mailing list