LINUX.ORG.RU

systemd userspace cgroup

 , ,


0

2

Привет!

Пытаюсь немного упорядочить своё рабочее окружение. Распилил процессы по контрольным группам:

  └─user-1000.slice
    ├─user@1000.service
    │ ├─305 /usr/lib/systemd/systemd --user
    │ ├─306 (sd-pam)  
    │ ├─kbdd.slice
    │ │ └─run-336.service
    │ │   └─351 /usr/bin/kbdd --nodaemon
    │ ├─autocutsel.slice
    │ │ └─run-340.service
    │ │   └─348 /usr/bin/autocutsel
    │ ├─tmux.service
    │ │ ├─452 /usr/sbin/tmux new-session -d
    │ │ ├─pane_%0
    │ │ │ └─453 -zsh
    │ │ ├─pane_%1
    │ │ │ ├─ 649 -zsh
    │ │ │ ├─1543 systemd-cgls
    │ │ │ └─1544 less
    │ │ ├─pane_%2
    │ │ │ ├─749 -zsh
    │ │ │ └─992 ssh desktop
    │ │ └─pane_%3
    │ │   └─1228 -zsh

Теперь хочу ограничить группу с tmux по памяти. Делаю так:

sudo systemctl set-property user@1000.service MemoryLimit=10000M

Теперь systemd создаёт директорию /sys/fs/cgroup/memory/user.slice/user-1000.slice/user@1000.service, но принадлежит она root. Если дать на неё права пользователю, то я смогу от имени пользователя ограничивать процессы, которые входят в одну из дочерних групп.

Было бы логичным, давать права на эту директорию соответствующему пользователю (как systemd это делает для /sys/fs/cgroup/systemd/user.slice/user-1000.slice/user@1000.service).

Есть какой то способ убедить его отдать права на директорию пользователю?

Надо полагать, это by design.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=a931ad47a8623163a29d89...

For unpriviliged services (those with User= set) this ensures that
access rights to the service cgroup is granted to the user in question,
to create further subgroups. Note that this only applies to the
name=systemd hierarchy though, as access to other controllers is not
safe for unpriviliged processes.

Задал вопрос, ждём ответа.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Спасибо!

Если у этой задачи есть решение, это позволит управлять cgroups от пользователя на любой системе «из коробки»

А какая опасность для непривилегированных процессов в том, что пользователь получит доступ до остальных контроллеров? Чужие процессы он в эту группу перевести не сможет, ограничений выше, чем у родительских групп тоже поднять не удастся.

disarmer ★★★ ()
Ответ на: комментарий от intelfx

Как это организовано в арче и федоре? Или там приходится тоже юзерсофт учить в systemd руками?

funeralismatic ★★★ ()
Ответ на: комментарий от funeralismatic

systemd --user ещё толком ни для чего не используется и не документировано, т. к. не допилено. Поэтому всё руками.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

То есть, нормально ещё не функционирует. Потому этот тред и появился.

Печально это всё. Вообще, проект перспективный, но пилится как-то странно и нерасторопно. Зато всякое ненужно впиливается.

funeralismatic ★★★ ()
Ответ на: комментарий от funeralismatic

Вполне юзабельно уже, все опции/параметры аналогичны системному инстансу, только у юзерского прав меньше. Для запуска конечно надо юниты написать, но это не так уж сложно.

А по теме топика оказалось, что это ограничение для безопасности, так что скорее всего найдётся workaround

disarmer ★★★ ()
Ответ на: комментарий от disarmer

Покажи, как у тебя юниты пускаются вместе с сессией (причём не обязательно графической).

ограничение для безопасности

Ну и нафиг нужны CGROUP для юзера, если ими рулить нельзя?

funeralismatic ★★★ ()
Ответ на: комментарий от funeralismatic

Я пока не писал service файлы, у меня они создаются динамически при старте awesome. вроде такого:

function cgrun(arg, unit)
        local slice=arg:match("^([^ ]+)")
        local display=os.getenv("DISPLAY") or ":0"
        return string.format ("systemd-run --user --setenv=DISPLAY=%s --slice %s -- %s",display,slice,arg)
end

И аналогично запускается tmux при старте терминала из zshrc (использую его вместо табов терминала)

Ну и нафиг нужны CGROUP для юзера, если ими рулить нельзя?

Так можно же, но надо сначала на директорию права пользователю дать. Возможно есть некостыльное решение, которое будет делать это само. Но даже так, это много проще, чем другие способы управления cgroups

disarmer ★★★ ()

A desktop user should not need to know about CGROUPS, nor should they need to use them. BFS also does not have the feature of «lots of tunables I don't understand».

anonymous ()
Ответ на: комментарий от disarmer

http://lists.freedesktop.org/archives/systemd-devel/2015-January/026764.html

No, this is currently not available, simply because it is not safe
from the kernel side of things.

We will open up some of the properties eventually, when the kernel
folks consider them safe.

Lennart

В плане workaround-ов — ключевые слова таковы: ExecStartPre, спецификатор %c, chown, chmod.

intelfx ★★★★★ ()
Ответ на: комментарий от funeralismatic

Цгруппы нужны для группировки процессов. Ещё CFS умеет автоматически балансировать процессорное время между всеми цгруппами.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Пока ими нельзя рулить от пользователя (в идеале — в пределах тех значений, которые задали система и/или рут per-user) они пользователю не нужны. Я это хотел сказать.

funeralismatic ★★★ ()
Ответ на: комментарий от intelfx

Печально, один шаг до победы ведь. Тогда придётся завести отдельный юнит, который будет делать chown этой директории, все остальные ведь в юзерском инстансе.

Спасибо!

disarmer ★★★ ()
Ответ на: комментарий от disarmer

Нет, не совсем так.

Есть юнит user@.service, который как раз и запускает юзерский инстанс. Проще всего будет модифицировать этот юнит, добавив туда ExecStartPre=/bin/sh -c "exec /bin/chown -R %U /sys/fs/cgroup/*/%c". А если сделать отдельным юнитом, то тебе 1) придётся синхронизироваться с запуском user@.service и 2) каким-то костыльным образом узнавать путь до цгруппы user@.service (который из самого user@.service доступен через спецификатор %c).

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

О, а так даже лучше выглядит. Но user@.service выполняется уже с правами пользователя, соответственно chown там не пройдёт?

Скопировал системный user@.service в /etc, добавил «MemoryLimit=10000M» (чтобы директория %c вообще создавалась) и «ExecStartPost=-/bin/chown %U /sys/fs/cgroup/memory/%c» (пока интересно только памятью управлять). Но chown не проходит, очевидно из-за прав, ExecStart* ведь уже с правами пользователя? Может есть какой-то хак для вызова с правами root?

disarmer ★★★ ()
Ответ на: комментарий от disarmer

Ах, блин. Он же с User= запускается.

Тогда не знаю.

intelfx ★★★★★ ()
Ответ на: комментарий от disarmer

Если только так.

/etc/systemd/system/user-hack@.service:

[Unit]
Description=Set permissions for user@%i.service control groups

[Service]
Type=oneshot
ExecStart=/bin/bash -c 'chown %I /sys/fs/cgroup/*/$(systemctl show -p ControlGroup user@%i.service | cut -d= -f2)'

/etc/systemd/system/user@.service.d/hack.conf:

[Unit]
Wants=user-hack@%i.service
After=user-hack@%i.service

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Да, срабатывает, но не совсем, отдаёт пользователю директории /sys/fs/cgroup/*, видимо subshell возвращает пустую строку на момент запуска. При перезапуске user@ вручную всё ок.

Добавил задержку в виде ExecStartPre=/usr/bin/sleep 5, но не помогло.

disarmer ★★★ ()

системд как реактось - обещаний много, а ничего по факту не работает?

anonymous ()
Ответ на: комментарий от anonymous

А управлять cgroups больше то и нечем (как бы есть libcgroup, который только в aur и не ставился пару недель назад из-за сломанной зависимости). А так можно управлять прямо на свежеустановленной системе (а после небольшого допиливания и от владельца процесса без прав root)

disarmer ★★★ ()

sd просто жесть какая-то

anonymous ()
Ответ на: комментарий от anonymous

Никто не обещал готовности юзерской инстанции. Шёл бы ты отсюда вместе со своим 4.3.

intelfx ★★★★★ ()
Ответ на: комментарий от disarmer

Угу. Так и думал. На момент выполнения юнита-хака цгруппа user@.service ещё не создана...

Как насчёт суидного скрипта из ExecStartPre=?

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Не, я пока формирую юниты через systemd-run, там нет ExecStartPre.

Тогда лучше буду совсем костылём создавать директорию, потом может допишут решение:

% cat /etc/tmpfiles.d/cgroups-user.conf
d /sys/fs/cgroup/memory/user.slice/user-1000.slice/user@1000.service 0755 disarmer root -
Если сломается схема именования, ничего страшного не произойдёт, просто не сработают лимиты.

Спасибо за помощь!

disarmer ★★★ ()
Ответ на: комментарий от disarmer

мужики, а подскажите как создать новый slice с ограничением по cpuset.mems, cpuset.cpus; как потом туда юниты прикреплять, вроде, понятно...

PS: извините, что я влез, свой топик создать не могу

anonymous ()
Ответ на: комментарий от anonymous

Можно сразу запускать в нужных слайсах, они создадутся автоматически:

sudo systemd-run --slice myslice -p MemoryLimit=1M -- sleep 123

disarmer ★★★ ()
Ответ на: комментарий от disarmer

ну, это только руками команду запускать, а мне нужен статический сервис

но это все фигня, главный вопрос был о том, как задавать значения таких параметров cgroups как cpuset.mems, cpuset.cpus и т.д.

то, что есть ключевые слова CPUShares, MemoryLimit, BlockIO* и проч., я знаю, но они все мне не подходят, нужно ограничивать ядра процессора и выделение памяти на определенных нодах

anonymous ()
Ответ на: комментарий от anonymous

Тогда создавать slice-файл, вроде такого:

% cat /etc/systemd/system/xephyr.slice
[Unit]
Before=slices.target
Wants=user.slice
After=user.slice
А у сервиса в зависимость добавить этот слайс: Wants=xephyr.slice

как задавать значения таких параметров cgroups как cpuset.mems

Я не уверен что systemd прямо все параметры cgroups может менять. Если systemd не может, то через файловый интерфейс ядра: echo чтототам > /sys/fs/cgroup/cpuset/myslice.slice/чтото/там, уже после создания слайса, например в PostExec в сервис-файле.

disarmer ★★★ ()
Ответ на: комментарий от disarmer

Тогда создавать slice-файл, вроде такого:

да, примерно так и сделал

А у сервиса в зависимость добавить этот слайс: Wants=xephyr.slice

нет, тут я сделал так:

[Service]
Slice=myslice.slice

echo чтототам > /sys/fs/cgroup/cpuset/myslice.slice/чтото/там, уже после создания слайса, например в PostExec в сервис-файле.

похожая мысль была, как костыль на крайний случай, но оказалось, что 'myslice.slice' не появился в нужном мне '/sys/fs/cgroup/cpuset', а есть только в '/sys/fs/cgroup/systemd'

anonymous ()
Ответ на: комментарий от anonymous

'myslice.slice' не появился в нужном мне '/sys/fs/cgroup/cpuset'

системный слайс (/sys/fs/cgroup/cpuset/system.slice), кстати, там есть, а моего нового нету

anonymous ()
Ответ на: комментарий от anonymous

похожая мысль была, как костыль на крайний случай,

Это не костыль, это kernel api =).

но оказалось, что 'myslice.slice' не появился в нужном мне '/sys/fs/cgroup/cpuset', а есть только в '/sys/fs/cgroup/systemd'

Да, эта тема как раз была про это. Чтобы systemd создал этот слайс в контроллере cpuset нужно ограничить этот слайс, по какому нибудь параметру в этом контроллере, который умеет systemd.

В man systemd.resource-control я таких ограничений по cpuset не увидел, так что скорее всего пока не умеет. Тогда по идее можно создавать этот слайс вручную(mkdir), но тут надо экспериментировать

disarmer ★★★ ()
Ответ на: комментарий от disarmer

Это не костыль, это kernel api =).

есть задача «управлять cgroups из systemd», в ее рамках спускаться на нижний уровень kernel API — это костыль; ясно, что руками черта лысого наконфигурять можно, но ведь сделали удобную обертку внутри системы инициализации...

Да, эта тема как раз была про это. Чтобы systemd создал этот слайс в контроллере cpuset нужно ограничить этот слайс, по какому нибудь параметру в этом контроллере, который умеет systemd.

я там писал чуть выше, что системный то слайс все-таки появляется там, где нужно, однако в файле system.slice тоже никаких ограничений по этому контроллеру нет

anonymous ()
Ответ на: комментарий от anonymous

«управлять cgroups из systemd»

Не, полноценного управления в cgroups в systemd еще нет. Есть просто некоторые частоиспользуемые ограничения для сервисов

системный то слайс все-таки появляется там, где нужно

Странно, у меня нет, на двух машинах как минимум:

% echo /sys/fs/cgroup/*/system.slice
/sys/fs/cgroup/devices/system.slice /sys/fs/cgroup/memory/system.slice /sys/fs/cgroup/systemd/system.slice
Тогда можно покопать в сторону того, откуда он создаётся и сделать по аналогии

disarmer ★★★ ()
Ответ на: комментарий от disarmer

Странно, у меня нет, на двух машинах как минимум:

сравним конфиги:

[root@localhost system]# find /sys/fs/cgroup/ -name 'system.slice'
/sys/fs/cgroup/blkio/system.slice
/sys/fs/cgroup/freezer/system.slice
/sys/fs/cgroup/memory/system.slice
/sys/fs/cgroup/cpu,cpuacct/system.slice
/sys/fs/cgroup/cpuset/system.slice
/sys/fs/cgroup/systemd/system.slice
/sys/fs/cgroup/systemd/system.slice/docker-8c4674d0ac0ca79ac4fa8c8f48f4597d12a7bd1769ce8f327a7b93e186d3f4a8.scope/system.slice
/sys/fs/cgroup/systemd/system.slice/docker-dda136dada93e378d25e2c8e6bd2a569b7cfa5212df1cf629efb6665214d29d5.scope/system.slice
[root@localhost system]# rpm -q systemd
systemd-208-11.el7_0.5.x86_64
[root@localhost system]# cat /etc/centos-release 
CentOS Linux release 7.0.1406 (Core) 
[root@localhost system]# uname -r
3.10.0-123.el7.x86_64
[root@localhost system]# cat /etc/systemd/system.conf 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# See systemd-system.conf(5) for details

[Manager]
#LogLevel=info
#LogTarget=journal-or-kmsg
#LogColor=yes
#LogLocation=no
#DumpCore=yes
#CrashShell=no
#ShowStatus=yes
#CrashChVT=1
#CPUAffinity=1 2
#DefaultStandardOutput=journal
#DefaultStandardError=inherit
#JoinControllers=cpu,cpuacct net_cls,net_prio
#RuntimeWatchdogSec=0
#ShutdownWatchdogSec=10min
#CapabilityBoundingSet=
#TimerSlackNSec=
#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s
#DefaultRestartSec=100ms
#DefaultStartLimitInterval=10s
#DefaultStartLimitBurst=5
#DefaultEnvironment=
#DefaultLimitCPU=
#DefaultLimitFSIZE=
#DefaultLimitDATA=
#DefaultLimitSTACK=
#DefaultLimitCORE=
#DefaultLimitRSS=
#DefaultLimitNOFILE=
#DefaultLimitAS=
#DefaultLimitNPROC=
#DefaultLimitMEMLOCK=
#DefaultLimitLOCKS=
#DefaultLimitSIGPENDING=
#DefaultLimitMSGQUEUE=
#DefaultLimitNICE=
#DefaultLimitRTPRIO=
#DefaultLimitRTTIME=
[root@localhost system]# 

Тогда можно покопать в сторону того, откуда он создаётся и сделать по аналогии

ну да, я посмотрел вокруг юнитов *.slice и slices.target, но ничего не раскопал, есть идеи где еще копать?

anonymous ()
Ответ на: комментарий от anonymous
[disarmer@desktop❱~]% find /sys/fs/cgroup/ -name 'system.slice'
/sys/fs/cgroup/devices/system.slice
/sys/fs/cgroup/memory/system.slice
/sys/fs/cgroup/systemd/system.slice
[disarmer@desktop❱~]% pacman -Q systemd
systemd 218-1
[disarmer@desktop❱~]% uname -a
Linux desktop 3.17.6-1-ARCH #1 SMP PREEMPT Sun Dec 7 23:43:32 UTC 2014 x86_64 GNU/Linux
[disarmer@desktop❱~]% cat /etc/systemd/system.conf
# /etc/systemd/system.conf.d/*.conf.
#
# See systemd-system.conf(5) for details

[Manager]
#LogLevel=info
#LogTarget=journal-or-kmsg
#LogColor=yes
#LogLocation=no
#DumpCore=yes
#CrashShell=no
#ShowStatus=yes
#CrashChVT=1
#CPUAffinity=1 2
#JoinControllers=cpu,cpuacct net_cls,net_prio
#RuntimeWatchdogSec=0
#ShutdownWatchdogSec=10min
#CapabilityBoundingSet=
#SystemCallArchitectures=
#TimerSlackNSec=
#DefaultTimerAccuracySec=1min
#DefaultStandardOutput=journal
#DefaultStandardError=inherit
#DefaultTimeoutStartSec=90s
#DefaultTimeoutStopSec=90s
#DefaultRestartSec=100ms
#DefaultStartLimitInterval=10s
#DefaultStartLimitBurst=5
#DefaultEnvironment=
#DefaultCPUAccounting=no
#DefaultBlockIOAccounting=no
#DefaultMemoryAccounting=no
#DefaultLimitCPU=
#DefaultLimitFSIZE=
#DefaultLimitDATA=
#DefaultLimitSTACK=
#DefaultLimitCORE=
#DefaultLimitRSS=
#DefaultLimitNOFILE=
#DefaultLimitAS=
#DefaultLimitNPROC=
#DefaultLimitMEMLOCK=
#DefaultLimitLOCKS=
#DefaultLimitSIGPENDING=
#DefaultLimitMSGQUEUE=
#DefaultLimitNICE=
#DefaultLimitRTPRIO=
#DefaultLimitRTTIME=
[disarmer@desktop❱~]% /lib/systemd/systemd --version
systemd 218
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID -ELFUTILS +KMOD +IDN
[disarmer@desktop❱~]% grep -v '^#' /usr/lib/systemd/system/system.slice
[Unit]
Description=System Slice
Documentation=man:systemd.special(7)
DefaultDependencies=no
Before=slices.target
Wants=-.slice
After=-.slice
[disarmer@desktop❱~]% grep cpuset /etc/ -R 2> /dev/null
/etc/mtab:cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0

ну да, я посмотрел вокруг юнитов *.slice и slices.target, но ничего не раскопал, есть идеи где еще копать?

А слайсы/сервисы которые работают внутри system.slice есть внутри /sys/fs/cgroup/cpuset/system.slice? А то это могут они вызывать создание иерархии.

disarmer ★★★ ()
Ответ на: комментарий от disarmer

А слайсы/сервисы которые работают внутри system.slice есть внутри /sys/fs/cgroup/cpuset/system.slice?

нет, там только пара докерских скопов и настройки:

[root@localhost /]# find /sys/fs/cgroup/cpuset/system.slice -maxdepth 1
/sys/fs/cgroup/cpuset/system.slice
/sys/fs/cgroup/cpuset/system.slice/docker-8c4674d0ac0ca79ac4fa8c8f48f4597d12a7bd1769ce8f327a7b93e186d3f4a8.scope
/sys/fs/cgroup/cpuset/system.slice/docker-dda136dada93e378d25e2c8e6bd2a569b7cfa5212df1cf629efb6665214d29d5.scope
/sys/fs/cgroup/cpuset/system.slice/cpuset.memory_spread_slab
/sys/fs/cgroup/cpuset/system.slice/cpuset.memory_spread_page
/sys/fs/cgroup/cpuset/system.slice/cpuset.memory_pressure
/sys/fs/cgroup/cpuset/system.slice/cpuset.memory_migrate
/sys/fs/cgroup/cpuset/system.slice/cpuset.sched_relax_domain_level
/sys/fs/cgroup/cpuset/system.slice/cpuset.sched_load_balance
/sys/fs/cgroup/cpuset/system.slice/cpuset.mem_hardwall
/sys/fs/cgroup/cpuset/system.slice/cpuset.mem_exclusive
/sys/fs/cgroup/cpuset/system.slice/cpuset.cpu_exclusive
/sys/fs/cgroup/cpuset/system.slice/cpuset.mems
/sys/fs/cgroup/cpuset/system.slice/cpuset.cpus
/sys/fs/cgroup/cpuset/system.slice/cgroup.clone_children
/sys/fs/cgroup/cpuset/system.slice/cgroup.event_control
/sys/fs/cgroup/cpuset/system.slice/notify_on_release
/sys/fs/cgroup/cpuset/system.slice/cgroup.procs
/sys/fs/cgroup/cpuset/system.slice/tasks
[root@localhost /]# 

А то это могут они вызывать создание иерархии.

ну да, я сначала, когда только создал свой slice и стартанул его, то в systemd-cgls он не появился, пока я не прикрепил к этому слайсу реальный сервис (просто скрипт, который спит в цикле); но в контроллере cpuset этот слайс не появился даже после этого, в отличие от системного слайса:

[root@localhost /]# find /sys/fs/cgroup/ -name 'myslice.slice'
/sys/fs/cgroup/blkio/myslice.slice
/sys/fs/cgroup/cpu,cpuacct/myslice.slice
/sys/fs/cgroup/systemd/myslice.slice
[root@localhost /]# 
[root@localhost /]# find /sys/fs/cgroup/ -name 'system.slice'
/sys/fs/cgroup/blkio/system.slice
/sys/fs/cgroup/freezer/system.slice
/sys/fs/cgroup/memory/system.slice
/sys/fs/cgroup/cpu,cpuacct/system.slice
/sys/fs/cgroup/cpuset/system.slice
/sys/fs/cgroup/systemd/system.slice
/sys/fs/cgroup/systemd/system.slice/docker-8c4674d0ac0ca79ac4fa8c8f48f4597d12a7bd1769ce8f327a7b93e186d3f4a8.scope/system.slice
/sys/fs/cgroup/systemd/system.slice/docker-dda136dada93e378d25e2c8e6bd2a569b7cfa5212df1cf629efb6665214d29d5.scope/system.slice
[root@localhost /]# 

anonymous ()
Ответ на: комментарий от anonymous

в systemd-cgls он не появился, пока я не прикрепил

systemd-cgls пропускает пустые группы, показывает их с ключом --all

нет, там только пара докерских скопов

вот, значит именно они инициируют создание иерархии, которая включает системный слайс. Наверное стоит посмотреть как они создаются

disarmer ★★★ ()
Ответ на: комментарий от disarmer

systemd-cgls пропускает пустые группы, показывает их с ключом --all

точно, спасибо

вот, значит именно они инициируют создание иерархии, которая включает системный слайс. Наверное стоит посмотреть как они создаются

действительно! перезагрузил сервер, демон docker (но не сами контейнеры) уже стартовал, а в /sys/fs/cgroup/cpuset/ системного слайса еще нет; видимо, он должен появиться, когда я запущу первый же контейнер (раньше стартовал вручную командой run --cpuset=N-M);
с другой стороны, на данный момент текущая позиция демона докера в иерархии контроллера cpuset — это '/':

[root@localhost /]# cat /proc/`pgrep docker`/cgroup
10:hugetlb:/
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/system.slice/docker.service
[root@localhost /]# cat /proc/`pgrep docker`/cpuset
/
[root@localhost /]#
так что не понимаю, откуда возьмется 'system.slice' в cpuset
есть, правда, его упоминание в именованной иерархии cgroups 'systemd', которая, однако, не привязана ни к одному контроллеру; но я не понимаю, что это такое, и зачем оно нужно, нигде понятного описания не нашел; видимо, все-таки отсюда system.slice берется, больше, похоже, неоткуда:
[root@localhost /]# mount | grep systemd
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=68,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
[root@localhost /]# 

кастую intelfx

anonymous ()
Ответ на: комментарий от anonymous

стрейс докер-демона показал, что это он создает ветку иерархии system.slice в контроллере cpuset:

[pid 19742] stat("/sys/fs/cgroup/cpuset/system.slice",  <unfinished ...>
[pid 19742] <... stat resumed> 0xc2081f47e0) = -1 ENOENT (No such file or directory)
[pid 19742] stat("/sys/fs/cgroup/cpuset",  <unfinished ...>
[pid 19742] <... stat resumed> {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 19742] stat("/sys/fs/cgroup/cpuset/system.slice",  <unfinished ...>
[pid 19742] <... stat resumed> 0xc2081f4900) = -1 ENOENT (No such file or directory)
[pid 19742] stat("/sys/fs/cgroup/cpuset",  <unfinished ...>
[pid 19742] <... stat resumed> {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
[pid 19742] mkdir("/sys/fs/cgroup/cpuset/system.slice", 0755 <unfinished ...>
[pid 19742] <... mkdir resumed> )       = 0
но откуда он узнает про этот system.slice не понятно

anonymous ()
Ответ на: комментарий от anonymous

Значит это его код умеет cgroups и знает про systemd, это хорошо. Видимо systemd действительно пока не умеет cpuset, иначе это бы решалось просто в юните docker

но откуда он узнает про этот system.slice не понятно

Ну он знает в каком слайсе работает, хотя бы из вывода systemd-cgls

disarmer ★★★ ()
Ответ на: комментарий от disarmer

Ну он знает в каком слайсе работает, хотя бы из вывода systemd-cgls

это предполагает слишком тесную интеграцию докера в systemd: знать про systemd-cgls и вообще про какие-то slice'ы; для докера это, быть может, естественно, раз уж он обслуживает контейнеры, но для какого-то простого сервиса такой подход совершенно неприемлем — настройка системных свойств (ограничения ресурсов) должна быть на соответствующем уровне, в данном случае — в системе инициализации systemd; глупо же в каждом плевом сервисе реализовывать свою поддержку cgroups

anonymous ()
Ответ на: комментарий от anonymous

оказывается любой параметр раньше можно было задать прямо через конфиг:

ControlGroupAttribute=attribute value
    This option sets various control group parameters exposed by Linux cgroup controllers. Replace attribute
    with a low-level cgroup parameter you wish to modify and value with a new value for this parameter.
    Refer to Controller-Specific Kernel Documentation for more information on cgroup controllers. 
но сейчас этот параметр уже не поддерживается

вот что за свинство! :(

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.