У меня есть служба (пакетная система HTCondor), которая запускается как служебная единица в сегментах cpu, cpuacct и памяти cgroup (CentOS 7 @ 3.10.0- *).
Служба запускает подпроцессы (~~> пакетные задания), для которых создает суб-срезы, то есть разделяя свои родительские ресурсы. Без дальнейшего вмешательства, запущенные процессы находятся в суб-срезах
wc -l /sys/fs/cgroup/cpu,cpuacct/system.slice/condor.service/tasks
19
wc -l /sys/fs/cgroup/cpu,cpuacct/system.slice/condor.service/*/tasks
29 /sys/fs/cgroup/cpu,cpuacct/system.slice/condor.service/condor_var_lib_condor_execute_slot1_2@batch0311.desy.de/tasks
22 /sys/fs/cgroup/cpu,cpuacct/system.slice/condor.service/condor_var_lib_condor_execute_slot1_3@batch0311.desy.de/tasks
22 /sys/fs/cgroup/cpu,cpuacct/system.slice/condor.service/condor_var_lib_condor_execute_slot1_4@batch0311.desy.de/tasks
...
и в качестве перекрестной проверки у процессов есть соответствующие контрольные группы также в их информации о процессе, например,
cat /proc/58683/cgroup
11:perf_event:/
10:memory:/system.slice/condor.service/condor_var_lib_condor_execute_slot1_6@batch0311.desy.de
9:devices:/system.slice
8:blkio:/system.slice/condor.service /condor_var_lib_condor_execute_slot1_6@batch0311.desy.de
7:cpuset:/
6:freezer:/system.slice/condor.service/condor_var_lib_condor_execute_slot1_6@batch0311.desy.de
5:hugetlb:/
4:cpuacct,cpu:/system.slice/condor.service/condor_var_lib_condor_execute_slot1_6@batch0311.desy.de
3:pids:/system.slice/condor.service
2:net_prio,net_cls:/
1:name=systemd:/system.slice/condor.service
AFAIS, systemd, похоже, не знает о суб-срезах, поскольку systemd-cgls показывает процессы непосредственно под cgroup родительского модуля
systemd-cgls
...
├─condor.service
│ ├─ 781 /bin/bash ...foo...
│ ├─ 1596 condor_starter -f -a slot1_4 ...baz...
Теперь при добавлении нового модуля, перезагрузке демонов systemd и запуске нового модуля все подгруппы заданий исчезают, а их процессы присоединяются к родительской контрольной группе.
wc -l /sys/fs/cgroup/cpu,cpuacct/system.slice/condor.service/tasks
337 /sys/fs/cgroup/cpu,cpuacct/system.slice/condor.service/tasks
Я предполагаю, что systemd не знает о суб-срезах (предположение из systemd-cgls), в то время как с точки зрения ядра это правильные срезы cgroup. При запуске нового модуля systemd замечает расхождение со своими ожиданиями и «убирает».
Можно ли как-то избежать такого поведения?
Проблема заключалась в том, что по умолчанию systemd предполагает, что все подгруппы / срезы обрабатываются самостоятельно и что любые единичные процессы не имеют собственного контроля.
При включении делегирования для юнита systemd не будет пытаться взять под контроль подресурсы юнита.
[Service]
...
Delegate=true
(раздел [Slice] также может быть правильным разделом, но, очевидно, правильный раздел зависит от выпуска / ядра, поэтому #YMMV)
обратите внимание, что cgroups / срезы, показываемые systemd-cgls и systemd-cgtop, по-прежнему различаются, и только systemd-cgtop показывает «правильное »Ä ядровое представление cgroups, в то время как systemd-cgls не показывает никакой подиерархии срезов даже с делегированием)
Похоже на апстрим, так как исправил это, указав Delegate= директива (зафиксировать 890186d82a - хотя указание подмножества контроллеров было бы немного более элегантным, чем просто true ПО МОЕМУ МНЕНИЮ). Если это обновление не распространяется на пакет CentOS, вы можете применить его локально с помощью следующей команды:
systemctl set-property condor.service Delegate=true