systemd userspace cgroup

Надо полагать, это 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.

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

Спасибо!

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

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

Может быть, denial of service какой-то. Я не знаю.

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

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

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

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

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

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

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

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

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

Я пока не писал 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

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».

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.

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

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

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

Спасибо!

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

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

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

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

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

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

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

/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

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

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

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

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

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

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

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

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

Не, я пока формирую юниты через 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 -

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

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

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

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

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

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

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

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

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

% cat /etc/systemd/system/xephyr.slice
[Unit]
Before=slices.target
Wants=user.slice
After=user.slice

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

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

Тогда создавать 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'

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

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

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

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

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

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

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

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

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

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

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

«управлять 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

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

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

[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, но ничего не раскопал, есть идеи где еще копать?

[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? А то это могут они вызывать создание иерархии.

А слайсы/сервисы которые работают внутри 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 /]# 

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

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

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

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

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 /]#

[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

стрейс докер-демона показал, что это он создает ветку иерархии 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

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

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

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

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

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

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

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. 

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