Re: [systemd-devel] how to prevent systemd-logind from moving process to other cgroups when executing su command
Am Dienstag, dem 25.05.2021 um 22:23 +0800 schrieb 吾为男子: > 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? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] how to prevent systemd-logind from moving process to other cgroups when executing su command
On Di, 25.05.21 22:23, 吾为男子 (csren...@qq.com) wrote: > 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-c.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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[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-c.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 9, then systemd will create directory session-9.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-9.scope, for example: We move it from /sys/fs/cgroup/systemd/user.slice/user-0.slice/session-9.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 1, then Systemd will create a new session group named session-cx.scope, for example, session-c10010.scope under /sys/fs/cgroup/systemd/user.slice/user-0.slice/ and place the new process 1 into it. For the cpu group, the new process 1 will be placed into user.slice instead of the my_test_group.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
