web-dev-qa-db-ja.com

systemdによってこれら2つのシステムでcgroupが異なる方法でマッピングされるのはなぜですか

私は2つのシステムを持っており、どちらもOpenSuSE 12.2（Mantis）のカスタマイズされたバリアントを実行しており、どちらもまったく同じカーネルを実行しています。 2つのシステムで/proc/self/cgroupまたは/proc/$$/cgroupの2つの非常に異なる出力を取得します。

システムA（または標準のOpenSuSE 12.1）：

cat /proc/self/cgroup 
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/user/root/6

システムB：

root@msx:/sys/fs/cgroup> cat /proc/self/cgroup 
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/system/[email protected]/ttyS0
2:cpuset:/
1:name=systemd:/system/[email protected]/ttyS0

行1が異なるのはなぜですか？また、行3が一方に存在し、もう一方には存在しないのはなぜですか？ 2つのシステムの間に構成の違いは見つかりません。それらは同じバージョンのsystemd（systemd-44-10.1.1.x86_64）を実行します。 sysctl値を複製しても、効果はありません。起動オプションは同じです。 /etc、/usr、および/libのすべてを比較して、関連する構成の違いがあるかどうかを確認しました。 （インストールされているRPMはさまざまですが、システム構成ファイルを配置するものはありません。すべてのカスタムRPMを削除したと思います。）

システムBではSCHED_RRスレッドを作成できないため、これは好奇心の要因以上のものですが、システムAでは作成できます。 /etc/systemd/system.confでDefaultControllerをNULLに設定すると、機能し、3行目が消えます（1行目は異なります）。呼び出し元のシェルのプロセスIDを/sys/fs/cgroup/cpu,cpuacctに書き込んでも機能します。

root@msx:/root> ./a.out
Creation of real-time thread FAILED - Operation not permitted
root@msx:/root> cat /proc/$$/cgroup
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/system/sshd.service
2:cpuset:/
1:name=systemd:/system/sshd.service
root@msx:/root> echo $$ > /sys/fs/cgroup/cpu,cpuacct/tasks
root@msx:/root> ./a.out
root@msx:/root> cat /proc/$$/cgroup
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/system/sshd.service

これが機能する理由がわかりません。私の同僚は、この構成の変更を必要としないはずなので、問題が理解されていることに満足していません。

カーネルは3.4.47で、CONFIG_RT_GROUP_SCHEDが有効になり、CONFIG_AUTOGROUPが有効になります（無効化はまだ機能しませんが、失敗は異なります）

これは https://stackoverflow.com/questions/20412336/how-to-check-for-permissions-for-sched-setscheduler のスピンオフです。

linux-kernelsystemdcgroups
7
eewanco

どのcgroup階層に接続するかを制御するsystem.conf構成オプションDefaultControllersがあります。デフォルトではCPUです。 nullに設定すると、/ proc/$$$/cgroupはcpuacct、cpuの下のgettyプロセスをリストしなくなり、テストプログラムは機能します。同じ構成ファイル（両方のシステムで使用されているデフォルトを使用していた）が2つの異なる結果を生成した理由はわかりません。これが問題を解決するための最良の方法であるか、なぜそれが機能するのかわかりません。だから私は変わった

#DefaultControllers=cpu

に

DefaultControllers=

/etc/systemd/system.confそしてそれは動作します。

1
eewanco