su 不会将所有内容更改为其他用户 (cgroups)
su does not change everything to other user (cgroups)
如果我运行这个命令:
su -l otheruser -c 'strace /usr/lib/systemd/systemd --user 2> /tmp/su.err'
失败:
Failed to create root cgroup hierarchy: Permission denied
Failed to allocate manager object: Permission denied
我在 strace 输出中看到以用户身份启动 systemd 失败:
mkdir("/sys/fs/cgroup/systemd/user/root/754/systemd-3893", 0755) = -1
EACCES (Permission denied)
/sys/fs/cgroup/systemd/user/root/从哪里来?
如果我 运行 通过 ssh 向本地主机执行相同的命令,它会起作用:
ssh otheruser@localhost 'strace /usr/lib/systemd/systemd --user 2> /tmp/ssh.err'
在这里,使用了正确的目录:
mkdir("/sys/fs/cgroup/systemd/user/modwork_gew_dfj/825/systemd-4272", 0755) = 0
为什么它可以通过 ssh 而不是通过 su?
版本:su (GNU coreutils) 8.17
更新
在这里你可以看到cgroup没有被我的su
版本改变:
host:~ # su -l otheruser
otheruser@host:~$ cat /proc/$PPID/cgroup
10:hugetlb:/
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/user/root/5913 <################ root
通过ssh
:
host:~ # ssh otheruser@host
otheruser@host:~$ cat /proc/$PPID/cgroup
10:hugetlb:/
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/user/otheruser/5919 <################ otheruser
更新2
我的su
版本没有改变cgroup(参见用户"ax."的回答中的link)。有没有办法改变调用 su
的 cgroup(之前或之后)?
更新3
这个版本没有这个问题:su util-linux 2.25
su
inherits its cgroup
from the originating session,不是从用户传递给 su
。因此,当您以 root 身份调用 su -l otheruser -c systemd ...
时,systemd
会尝试将 root cgroup (/sys/fs/cgroup/systemd/user/root/...
) 用作 otheruser
,但失败了。
使用 ssh otheruser@localhost ...
,用户和 cgroup 都是 otheruser
,一切正常。
正如 guettli 指出的那样,su 不再起作用了。
在 centos7.2 中作为 root 我试过这似乎适用于 uid 的 cgroup:
假设你有 uid=1000 是一个高 cpu 共享用户和 uid=1001 是一个低 cpu 共享用户,(我猜默认情况下每个新用户都会获得 1024 的份额,这将root 用户 (uid=0))
在 centos7.2 中作为 root 我试过这似乎适用于 cgroup:
systemd-run --uid=1000 --slice=user-1000.slice do_uid_1000_work_commands
systemd-run --uid=1001 --slice=user-1001.slice do_uid_1001_work_commands
以上将在 /run/systemd/system/:
下使用相应的用户切片配置创建两个临时服务
/run/systemd/system/*10345*
/run/systemd/system/run-10345.service
/run/systemd/system/run-10345.service.d:
50-Description.conf50-ExecStart.conf50-Slice.conf50-User.conf
以下是我的其余配置:
--> /etc/systemd/system/user-1000.slice.d/50-CPUShares.conf
[Slice]
CPUShares=4096
--> /etc/systemd/system/user-1001.slice.d/50-CPUShares.conf
[Slice]
CPUShares=1024
--> /usr/lib/systemd/system/user-1001.slice
[Unit]
Description=User and Session Slice for uid = 1001 (low cpu share user)
Documentation=man:systemd.special(7)
Before=slices.target
[Service]
Slice=user-1001
CPUShares=1024
--> /usr/lib/systemd/system/user-1000.slice
[Unit]
Description=User and Session Slice for uid = 1000 (high cpu share user)
Documentation=man:systemd.special(7)
Before=slices.target
[Service]
Slice=user-1000
CPUShares=4096
如果我运行这个命令:
su -l otheruser -c 'strace /usr/lib/systemd/systemd --user 2> /tmp/su.err'
失败:
Failed to create root cgroup hierarchy: Permission denied
Failed to allocate manager object: Permission denied
我在 strace 输出中看到以用户身份启动 systemd 失败:
mkdir("/sys/fs/cgroup/systemd/user/root/754/systemd-3893", 0755) = -1
EACCES (Permission denied)
/sys/fs/cgroup/systemd/user/root/从哪里来?
如果我 运行 通过 ssh 向本地主机执行相同的命令,它会起作用:
ssh otheruser@localhost 'strace /usr/lib/systemd/systemd --user 2> /tmp/ssh.err'
在这里,使用了正确的目录:
mkdir("/sys/fs/cgroup/systemd/user/modwork_gew_dfj/825/systemd-4272", 0755) = 0
为什么它可以通过 ssh 而不是通过 su?
版本:su (GNU coreutils) 8.17
更新
在这里你可以看到cgroup没有被我的su
版本改变:
host:~ # su -l otheruser
otheruser@host:~$ cat /proc/$PPID/cgroup
10:hugetlb:/
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/user/root/5913 <################ root
通过ssh
:
host:~ # ssh otheruser@host
otheruser@host:~$ cat /proc/$PPID/cgroup
10:hugetlb:/
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/user/otheruser/5919 <################ otheruser
更新2
我的su
版本没有改变cgroup(参见用户"ax."的回答中的link)。有没有办法改变调用 su
的 cgroup(之前或之后)?
更新3
这个版本没有这个问题:su util-linux 2.25
su
inherits its cgroup
from the originating session,不是从用户传递给 su
。因此,当您以 root 身份调用 su -l otheruser -c systemd ...
时,systemd
会尝试将 root cgroup (/sys/fs/cgroup/systemd/user/root/...
) 用作 otheruser
,但失败了。
使用 ssh otheruser@localhost ...
,用户和 cgroup 都是 otheruser
,一切正常。
正如 guettli 指出的那样,su 不再起作用了。 在 centos7.2 中作为 root 我试过这似乎适用于 uid 的 cgroup: 假设你有 uid=1000 是一个高 cpu 共享用户和 uid=1001 是一个低 cpu 共享用户,(我猜默认情况下每个新用户都会获得 1024 的份额,这将root 用户 (uid=0))
在 centos7.2 中作为 root 我试过这似乎适用于 cgroup:
systemd-run --uid=1000 --slice=user-1000.slice do_uid_1000_work_commands
systemd-run --uid=1001 --slice=user-1001.slice do_uid_1001_work_commands
以上将在 /run/systemd/system/:
下使用相应的用户切片配置创建两个临时服务/run/systemd/system/*10345*
/run/systemd/system/run-10345.service
/run/systemd/system/run-10345.service.d:
50-Description.conf50-ExecStart.conf50-Slice.conf50-User.conf
以下是我的其余配置: --> /etc/systemd/system/user-1000.slice.d/50-CPUShares.conf
[Slice]
CPUShares=4096
--> /etc/systemd/system/user-1001.slice.d/50-CPUShares.conf
[Slice]
CPUShares=1024
--> /usr/lib/systemd/system/user-1001.slice
[Unit]
Description=User and Session Slice for uid = 1001 (low cpu share user)
Documentation=man:systemd.special(7)
Before=slices.target
[Service]
Slice=user-1001
CPUShares=1024
--> /usr/lib/systemd/system/user-1000.slice
[Unit]
Description=User and Session Slice for uid = 1000 (high cpu share user)
Documentation=man:systemd.special(7)
Before=slices.target
[Service]
Slice=user-1000
CPUShares=4096