[systemd-devel] how to prevent systemd-logind from moving process to other cgroups when executing su command

[吾为男子]

Systemd provides pam_systemd.so for PAM module and for many commands, such as su command, pam_systemd.so will be called and the process will be moved to the cgroup that systemd managed.




Generally, if we move the bash process from its related session cgroup created by systemd under /sys/fs/cgroup/systemd/user.slice to some other cgroup, then systemd will move the new bash process into a new group named as session-cxxxx.scope under /sys/fs/cgroup/systemd/user.slice after executing su command.




We would like to manage the cgroups for a set of processes created by ourselves, how to prevent systemd to do such routines, without disabling pam_systemd in PAM module.




For example




the default cgroup root path is /sys/fs/cgroup.




When manually created 'bash' process with pid 12345 and session id 99999, then systemd will create directory session-99999.scope under /sys/fs/cgroup/systemd/user.slice/user-0.slice/ and place the process 12345 into it.




For other cgroups such as cpu or memory, the process 12345 will be placed into eache user.slice directory under these cgroups bounded with subsystems




If we move the process with pid 12345 into other cgroup from session-99999.scope, for example:




We move it from /sys/fs/cgroup/systemd/user.slice/user-0.slice/session-99999.scope to /sys/fs/cgroup/systemd/.




For cpu group, we move it form /sys/fs/cgroup/cpu/user.slice to /sys/fs/cgroup/my_test_group.




Then we execute 'su xxx' command, created a new bash with pid 13333, then




Systemd will create a new session group named session-cxxxxx.scope, for example, session-c10010.scope under /sys/fs/cgroup/systemd/user.slice/user-0.slice/ and place the new process 13333 into it.




For the cpu group, the new process 13333 will be placed into user.slice instead of the my_test_group.

[Lennart Poettering]

Post by 吾为男子
Systemd provides pam_systemd.so for PAM module and for many
commands, such as su command, pam_systemd.so will be called and the
process will be moved to the cgroup that systemd managed.
Generally, if we move the bash process from its related session
cgroup created by systemd under /sys/fs/cgroup/systemd/user.slice to
some other cgroup, then systemd will move the new bash process into
a new group named as session-cxxxx.scope under
/sys/fs/cgroup/systemd/user.slice after executing su command.
We would like to manage the cgroups for a set of processes created
by ourselves, how to prevent systemd to do such routines, without
disabling pam_systemd in PAM module.

This is simply not supported by systemd. If you use systemd then it is
systemd that manages the cgroup tree for you. You may request a
delegated subtree you can manage your own stuff in, but the top-level
of the tree is always owned and controlled by systemd and if you
interfere with it, you get to keep the pieces.

This is explained here:

https://systemd.io/CGROUP_DELEGATION

Sorry if this is disappointing,

Lennart

--
Lennart Poettering, Berlin

[Silvio Knizek]

Post by 吾为男子
Systemd provides pam_systemd.so for PAM module and for many commands,
such as su command, pam_systemd.so will be called and the process
will be moved to the cgroup that systemd managed.

Regardless your problem, `su` is never the solution.
What actual problem do you want to solve? Have you checked out
`systemd-run`? Do you want to run some `init` scripts from $vendor
stuck in 2002?