Почему группы распределены по-разному на этих двух системах с помощью systemd

У меня есть две системы, оба из которых работают под индивидуальными вариантами OpenSuSE 12.2 (Mantis), оба работают точно так же, как и ядро. Я получаю два очень разных выхода /proc/self/cgroup или /proc/$$/cgroup на двух системах:

Система 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/serial-getty@.service/ttyS0 2:cpuset:/ 1:name=systemd:/system/serial-getty@.service/ttyS0 

Почему строки 1 разные и почему строка 3 присутствует в одном и отсутствует в другом? Я не вижу различий в конфигурации между этими двумя системами. Они запускают ту же версию systemd ( systemd-44-10.1.1.x86_64 ). Если я дублирую значения sysctl, это не влияет. Параметры загрузки одинаковы. Я сравнил все в /etc , /usr и /lib чтобы увидеть, есть ли какие-либо соответствующие различия в конфигурации. (Существуют разные установленные RPM, но ни один из них не устанавливает файлы конфигурации системы, и я думаю, что я удалил все настраиваемые RPM.)

Это больше, чем фактор любопытства, потому что в системе B мы не можем создать поток SCHED_RR , но в Системе A мы можем. Если я устанавливаю DefaultController в NULL в /etc/systemd/system.conf , он работает, а строка 3 исчезает (строки 1 остаются разными). Он также работает, если я пишу идентификатор процесса вызывающей оболочки в /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_RT_GROUP_SCHED, разрешено CONFIG_AUTOGROUP (отключение по-прежнему не работает, но оно не работает по-другому)

Это spinoff https://stackoverflow.com/questions/20412336/how-to-check-for-permissions-for-sched-setscheduler .

  • Как исправить статус выхода 127?
  • Разница между хорошим уровнем и свойством systemctl CPUShares
  • Systemd, перезапустить службу при изменении IP-адреса
  • имеющих 2 системных каталога
  • Является ли мой часовой пояс BST отстающим на час?
  • Не удалось запустить httpd и отобразить ошибку
  • Настройка параметров инициализации пакета пакета opendkim Debian при наличии сценариев init.d и systemctl
  • Включение дампов ядра для всех приложений, запущенных пользователем с помощью systemd
  • One Solution collect form web for “Почему группы распределены по-разному на этих двух системах с помощью systemd”

    Существует опция конфигурации system.conf, DefaultControllers, которая контролирует, к какой иерархии групп подключены. По умолчанию это процессор. Я установил его в null и / proc / $$$ / cgroup больше не перечисляет процесс getty в cpuacct, cpu и работает тестовая программа. Почему тот же файл конфигурации – я использовал значение по умолчанию, которое используется в обеих системах, – два разных результата, я не знаю. Я не уверен, что это лучший способ решить проблему или почему она работает. Поэтому я изменил

     #DefaultControllers=cpu 

    в

     DefaultControllers= 

    в /etc/systemd/system.conf и он работает.

    Linux и Unix - лучшая ОС в мире.