Warum werden cgroups auf diesen beiden Systemen von systemd unterschiedlich zugeordnet?

Ich habe zwei Systeme, auf denen beide angepasste Varianten von OpenSuSE 12.2 (Mantis) ausgeführt werden und auf denen genau derselbe Kernel ausgeführt wird. Ich bekomme zwei sehr unterschiedliche Ausgänge von /proc/self/cgroupoder /proc/$$/cgroupauf den beiden Systemen:

System A (oder eine OpenSuSE 12.1-Aktie):

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

System 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/serial-getty@.service/ttyS0
2:cpuset:/
1:name=systemd:/system/serial-getty@.service/ttyS0

Warum unterscheiden sich die Zeilen 1 und warum ist die Zeile 3 in der einen vorhanden und in der anderen nicht vorhanden? Ich kann keine Konfigurationsunterschiede zwischen den beiden Systemen feststellen. Sie führen dieselbe Version von systemd ( systemd-44-10.1.1.x86_64) aus. Wenn ich die sysctl-Werte dupliziere, hat dies keine Auswirkung. Die Startoptionen sind gleich. Ich habe alles in /etc, verglichen /usrund /libfestgestellt, ob es relevante Konfigurationsunterschiede gibt. (Es gibt verschiedene installierte RPMs, aber keine, die Systemkonfigurationsdateien ablegen, und ich glaube, ich habe alle benutzerdefinierten RPMs entfernt.)

Dies ist mehr als ein Kuriositätsfaktor, da wir auf System B keinen SCHED_RRThread erstellen können, auf System A jedoch. Wenn ich festgelegt , DefaultControllerum NULLin /etc/systemd/system.conf, es funktioniert, und Linie 3 verschwindet (Linien 1 bleiben unterschiedlich). Es funktioniert auch, wenn ich die Prozess-ID der aufrufenden Shell in Folgendes schreibe /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

Ich bin mir nicht sicher, warum das funktioniert. Meine Kollegen sind nicht zufrieden, dass das Problem verstanden wird, da diese Konfigurationsänderung nicht erforderlich sein sollte.

Kernel ist 3.4.47, CONFIG_RT_GROUP_SCHEDist aktiviert, CONFIG_AUTOGROUPist aktiviert (das Deaktivieren funktioniert immer noch nicht, aber es schlägt anders fehl)

Dies ist eine Ausgründung von /programming/20412336/how-to-check-for-permissions-for-sched-setscheduler .

linux-kernel systemd cgroups

— eewanco
quelle

Wie melden Sie sich an?

— Hauke Laging

@Hauke - Das Anmelden funktioniert einwandfrei. Normalerweise melde ich mich wie in diesem Beispiel über die serielle Konsole an, aber ssh funktioniert auch (und hat das gleiche Verhalten).

— Eewanco

@Hauke - ok ich sehe eine Anomalie im letzten Beispiel; Ich muss versehentlich aus zwei verschiedenen Läufen ausgeschnitten und eingefügt haben. Ich habe nur einen Lauf durchgeführt und das Beispiel neu geschrieben, damit die Anmeldemethode vor und nach dem Test konsistent ist!

— Eewanco

Was ist die Ausgabe mount | grep cgroupauf jedem System?

— Gogators

cat / proc / cgroups

— c4f4t0r

Es gibt die Konfigurationsoption system.conf, DefaultControllers, die steuert, an welche Gruppenhierarchien angehängt wird. Standardmäßig ist es CPU. Ich habe es auf null gesetzt und / proc / $$$ / cgroup listet den getty-Prozess nicht mehr unter cpuacct, cpu auf und das Testprogramm funktioniert. Warum dieselbe Konfigurationsdatei - ich habe die auf beiden Systemen verwendete Standardeinstellung verwendet - zwei unterschiedliche Ergebnisse erzielt hat, weiß ich nicht. Ich bin mir nicht sicher, ob dies der beste Weg ist, um das Problem zu lösen oder warum es funktioniert. Also habe ich mich verändert

#DefaultControllers=cpu

DefaultControllers=

in /etc/systemd/system.confund es funktioniert.

— eewanco
quelle