Pourquoi les cgroups sont-ils mappés différemment sur ces deux systèmes par systemd

J'ai deux systèmes, tous deux exécutant des variantes personnalisées d'OpenSuSE 12.2 (Mantis), les deux fonctionnant exactement le même kernel. J'obtiens deux sorties très différentes de /proc/self/cgroup ou /proc/$$/cgroup sur les deux systèmes:

Système A (ou un stock 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 

Système 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 

Pourquoi les lignes 1 sont-elles différentes et pourquoi la ligne 3 est-elle présente en une et absente de l'autre? Je ne trouve aucune différence de configuration entre les deux systèmes. Ils exécutent la même version de systemd ( systemd-44-10.1.1.x86_64 ). Si je duplique les valeurs de sysctl, cela n'a aucun effet. Les options de démarrage sont les mêmes. J'ai tout comparé dans /etc , /usr , et /lib pour voir s'il y a des différences de configuration pertinentes. (Il y a différents RPM installés mais aucun qui fixe les files de configuration du système, et je pense avoir supprimé tous les RPM personnalisés.)

Ceci est plus qu'un facteur de curiosité parce que sur le système B, nous ne pouvons pas créer un thread SCHED_RR , mais sur le système A, nous le pouvons. Si je configure DefaultController sur NULL dans /etc/systemd/system.conf , cela fonctionne et la ligne 3 disparaît (les lignes 1 restnt différentes). Cela fonctionne aussi si j'écris l'ID de process du shell invoquant dans /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 

Je ne sais pas pourquoi cela fonctionne. Mes collègues ne sont pas convaincus que le problème est compris, car il ne devrait pas exiger ce changement de configuration.

Le kernel est 3.4.47, CONFIG_RT_GROUP_SCHED est activé, CONFIG_AUTOGROUP est activé (la désactivation ne fonctionne toujours pas mais échoue différemment)

Ceci est une retombée de https://stackoverflow.com/questions/20412336/how-to-check-for-permissions-for-sched-setscheduler .

Il existe une option de configuration system.conf, DefaultControllers, qui contrôle les hiérarchies cgroup attachées. Par défaut, c'est CPU. Je l'ai mis à null et / proc / $$$ / cgroup ne répertorie plus le process getty sous cpuacct, cpu, et le programme de test fonctionne. Pourquoi le même file de configuration – j'utilisais le défaut qui est utilisé sur les deux systèmes – a produit deux résultats différents, je ne sais pas. Je ne suis pas sûr que c'est la meilleure façon de résoudre le problème ou pourquoi cela fonctionne. Alors j'ai changé

 #DefaultControllers=cpu 

à

 DefaultControllers= 

dans /etc/systemd/system.conf et cela fonctionne.