LINUX.ORG.RU

systemd 220

 


2

4

21 мая был представлен очередной релиз системного менеджера systemd, совмещающего в себе функции системы инициализации, ведения журнала, управления сессиями пользователей и работы с контейнерами. systemd основан на модели зависимостей (в противовес событийной модели), производит отслеживание процессов запущенных сервисов при помощи механизма cgroups ядра Linux, поддерживает механизмы сокет- и dbus-активации сервисов и предоставляет удобный декларативный синтаксис для описания демонов и других сущностей. Это позволяет производить агрессивную параллелизацию при запуске и остановке сервисов.

В рамках проекта также разрабатывается ряд легковесных приложений и демонов, выполняющих второстепенные, но распространённые вспомогательные задачи (т. н. plumbing layer) — от настройки подсистемы VT (systemd-vconsole-setup) и первичного конфигурирования системы (systemd-firstboot) до управления сетью (systemd-networkd) и профилирования загрузки (systemd-bootchart). А теперь ещё и легковесный загрузчик для UEFI (бывший gummiboot).

В этот релиз вошли по большей части различные исправления и усовершенствования внутренней логики, а также расширения уже существующей функциональности. В частности, были существенно стабилизированы новые «контейнерные» фичи из systemd 219.

Изменения в ядре systemd

  • systemd больше не поддерживает обновление без перезагрузки («daemon-reexec») с версий, предшествующих systemd 44. Это не должно создать никаких реальных проблем, поскольку во всех актуальных на данный момент версиях распространённых дистрибутивов используются более новые версии systemd.
  • При генерации юнитов из sysvinit-скриптов соответствие между уровнями запуска sysvinit и стандартными целями systemd теперь жёстко задано:
    • уровням запуска 2, 3 и 4 соответствует multi-user.target;
    • уровню запуска 5 соответствует graphical.target.

    Раньше это соответствие можно было изменить, делая вспомогательные юниты runlevel[2-5].target симлинками на ту или иную цель. Оказалось, что устоявшаяся семантика алиасов юнитов в systemd приводит к неразрешимым проблемам при таком подходе.

  • Из состава systemd был исключён вспомогательный демон systemd-shutdownd, предназначавшийся для отложенного завершения работы в стиле shutdown(8). Теперь эта функциональность реализуется в systemd-logind. Интерфейс остался тем же — команда shutdown.(Если в вашей конфигурации systemd-logind не используется, отложенное завершение работы можно устроить с помощью systemd-run и таймерных юнитов — прим. пер.)
  • При использовании сокет-активации в режиме Accept=true (когда на каждое соединение запускается отдельный инстанс демона) systemd теперь устанавливает для каждой запускаемой копии демона переменные $REMOTE_ADDR и $REMOTE_PORT.
  • В секции [Automount] unit-файлов добавлена директива TimeoutIdleSec=, позволяющая указать таймаут автомонтирования — время, по истечении которого с момента последнего обращения к автоматической точке монтирования она будет отключена.

    Таймаут также можно установить из /etc/fstab, указав для соответствующего устройства параметр x-systemd.idle-timeout= (наряду с x-systemd.automount).

  • Помимо вышеуказанной x-systemd.idle-timeout=, обработчик /etc/fstab (systemd-fstab-generator) теперь поддерживает опции x-systemd.requires= и x-systemd.requires-mounts-for=. С их помощью можно задать дополнительные зависимости для соответствующего .mount-юнита.

    Это может пригодиться, например, при хранении журнала ФС на отдельном устройстве (-o logdev= в случае XFS), или при использовании оверлейных ФС, объединяющих несколько точек монтирования (-o lowerdir=<path1>,upperdir=<path2>). В каждом из этих случаев список зависимостей .mount-юнита требуется дополнять вручную.

  • Раздел ESP (EFI System Partition), автоматически монтируемый systemd-efi-boot-generator на /boot, теперь автомонтируется с таймаутом в 2 минуты. Это сделано ради того, чтобы уменьшить риск повреждения раздела при аварийном отключении системы — драйвер VFAT в ядре Linux по-прежнему ни на что не годен.
  • Суммарный расход процессорного времени всеми процессами юнита (атрибут cpuacct.usage соответствующей контрольной группы) теперь экспортируется как свойство CPUUsageNSec= объекта юнита на шине и отображается в выводе команды systemctl status.(Разумеется, это требует задействования контроллера cpuacct, т. е. CONFIG_CGROUP_CPUACCT=y в конфигурации ядра и DefaultCPUAccounting=yes в /etc/systemd/system.conf. Что, в частности, несовместимо с планировщиком задач BFS, поэтому примера не будет. – Прим. пер.)
  • Команды systemctl enable, systemctl disable и systemctl mask теперь поддерживают параметр --now, позволяющий вдобавок ко включению, отключению или маскировке юнитов также немедленно запустить или остановить их. Другими словами, команда systemctl enable --now эквивалентна последовательному выполнению systemctl enable и systemctl start (аналогично для disable и mask).
  • Команда systemctl reboot теперь поддерживает параметр --firmware-setup, позволяющий после перезагрузки войти в режим настройки прошивки (то, что называют Setup). Разумеется, это требует поддержки со стороны самой прошивки и применимо только к UEFI.

    Соответствующий вызов был добавлен в шинное API systemd-logind, так что DE также могут предоставлять графический интерфейс для этого.

  • Многие методы в шинных API systemd, systemd-logind и systemd-machined теперь поддерживают асинхронную авторизацию через polkit и могут использоваться непривилегированными процессами. Действия над своей сессией также по умолчанию разрешены и не требуют дополнительных привилегий (например, loginctl lock-session или loginctl kill-session теперь можно делать от имени пользователя).
  • В файле /etc/crypttab (за его обработку отвечает systemd-cryptsetup-generator) добавлена поддержка параметров offset= и skip= (как в Debian). Эти параметры позволяют указать расположение зашифрованных данных внутри блочного устройства.
  • В спецификацию формата файла /etc/os-release добавлены новые поля VARIANT= и VARIANT_ID=, позволяющие создателям дистрибутива указать «разновидность» дистрибутива (в человекочитаемом и машиночитаемом виде соответственно) — такую, как «Workstation», «Server» и так далее.
  • systemd-fsck теперь умеет передавать информацию о текущем состоянии fsck в сокет /run/systemd/fsck.progress. Это может пригодиться при реализации загрузочных сплеш-скринов.

Изменения во вспомогательных компонентах

  • В состав проекта systemd под именем systemd-boot был влит исходный код UEFI-загрузчика gummiboot. Соответствующая утилита командной строки называется bootctl.

    Вместе с ним в проект был добавлен примитивный EFI-«контейнер», предназначенный для объединения файла ядра, initcpio и других вспомогательных файлов в один самозагружающийся образ. Это позволяет, к примеру, подписать совокупность ядра, initcpio и строки параметров в соответствии со стандартами Secure Boot (и при необходимости обойтись без использования загрузчика-прослойки).

    Загрузчик systemd-boot был соответственно доработан для того, чтобы извлекать из таких контейнеров метаданные (название, версию, …) и отображать их при выборе варианта загрузки.

  • В systemd-tmpfiles добавлены действия h и H — установка атрибутов файлов аналогично chattr(1).

Изменения в journald

  • systemd-journald больше не пытается самостоятельно устанавливать флаг FS_NOCOW на файлах журнала. Вместо этого используется вновь добавленное действие h в systemd-tmpfiles. Это позволяет администратору системы переопределить поведение, замаскировав файл journal-nocow.conf в конфигурации tmpfiles.d.
  • systemd-journald при обработке сообщений audit-подсистемы ядра теперь декодирует типы сообщений и записывает в лог текстовые идентификаторы.

Изменения в udev

  • Библиотека gudev (биндинги udev к GObject) была выделена в отдельный репозиторий; теперь её поддержка ведётся в рамках проекта GNOME. Копия исходного кода gudev ещё некоторое время будет оставаться в дереве systemd, но в ближайшее время оттуда исчезнет.

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

  • udev не будет создавать симлинки (/dev/disk/by-foo/bar) для неизвестных типов блочных устройств (чёрный список в соответствующем udev-правиле был заменён на белый).(Это не должно никого затронуть, но если у вас феерически странная конфигурация устройств хранения данных и вдруг исчезли эти самые симлинки — теперь вы знаете, куда копать. — Прим. пер.)
  • Начата работа над новым API sd-device, которое является модернизацией традиционного API libudev и в итоге его заменит. (Ещё не скоро: новый API не стабилизирован и извне systemd на данный момент не доступен.)
  • База данных аппаратного обеспечения (hwdb) udev’а теперь содержит базу данных Trackpoint-подобных устройств. На данный момент она состоит из информации об их чувствительности и требуемом ускорении курсора. Опять же, предполагается, что это будет использоваться в libinput.

Изменения в networkd

systemd-networkd теперь поддерживает:

  • отключение интерфейсов при потере аплинка а-ля Uplink Failure Detection (директива BindCarrier= секции [Network] network-файлов);
  • установку идентификатора DHCP-клиента (директива ClientIdentifier= секции [DHCP] network-файлов);
  • явное включение или отключение использования NTP-серверов, полученных через DHCP на конкретном интерфейсе (директива UseNTP= секции [DHCP] network-файлов);
  • создание IPv6-over-IPSec туннелей (директива Kind=vti6 секции [NetDev] netdev-файлов);
  • множество новых настроек для VXLAN- и bond-интерфейсов (секции [VXLAN] и [BOND] netdev-файлов).

Также в systemd-networkd было исправлено управление IP forwarding. Начиная с данного релиза, не требуется вручную включать глобальный форвардинг с помощью sysctl-переменных net.ipv[46].ip_forward. Вместо этого предлагается использовать директиву IPForward= секции [Network] network-файлов (что эквивалентно включению форвардинга для конкретного интерфейса).

Изменения, связанные с поддержкой контейнеров

  • systemd-nspawn теперь поддерживает:
    • параметр --property — установка произвольных свойств для scope-юнита контейнера (в частности, ограничений ресурсов);
    • параметр --private-users=<нулевой UID>,<количество UID> — переход в изолированное пространство имён пользователей;
    • параметр --overlay=<lower>:<higher>:...:<точка монтирования> — монтирование директорий из хоста в контейнер с использованием оверлейной ФС (по аналогии с --bind);
    • параметр --kill-signal — явное указание сигнала, передаваемого PID 1 контейнера при его остановке;
    • запуск в составе конвейера, в каковом случае псевдо-TTY не создаётся, а файловые дескрипторы стандартного ввода и вывода напрямую передаются запускаемому процессу.
  • systemd-importd теперь способен импортировать контейнеры из локальных tar-архивов, побайтовых (.img, .raw) и .qcow2-образов, а также записывать их в tar-архивы и побайтовые образы. Ещё он научился импортировать Docker-образы через его Docker Registry HTTP API v2 (раньше умел только v1 — прим. пер.).
  • systemd-importd теперь поддерживает верификацию загруженных образов с помощью gpg2 (опять же, раньше умел только gpg1 — прим. пер.).
  • Многие (почти все) операции с контейнерами (в частности, импортирование) поддерживаются только для файловой системы btrfs, поскольку основаны на присутствующей в этой ФС функциональности снапшотов. Если используется другая ФС, при первой операции с контейнерами автоматически создаётся файл /var/lib/machines.raw, на котором создаётся btrfs, и этот файл монтируется на /var/lib/machines.

    Файл-образ (и файловая система на нём) автоматически расширяется при необходимости.

    (Почему они не сделали всё то же самое через overlayfs — загадка природы. — прим. пер.)
  • Наконец, была добавлена команда machinectl set-limit, позволяющая устанавливать ограничение на дисковое пространство для каждого контейнера. Эта функциональность реализована, опять же, через механизм квот btrfs.

>>> Объявление о релизе

★★★★★

Проверено: fallout4all ()
Последнее исправление: JB (всего исправлений: 7)
Ответ на: комментарий от FilosofeM

Транзакции в смысле запуска юнитов? Никогда: checkpoint/restore в масштабах всей системы невозможен.

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

Ну если только так.

Да и то — внешний мир не виртуализируешь (впрочем, хотелось бы), и тогда всё равно не очень понятно, как достичь изоляции.

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

Годно! Каждый релиз systemd - целое событие.

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

Надо составить публичный список хейтеров для каста. И меня в их число ибо всё же systemd слишком жырно для init.

mittorn ★★★★★
()

Собственно маленький вопрос:)

Планируется ли в systemd добавление возможности настройки ротации логов?

Поясню. Сейчас все пишется в /var/log/journal/<machine_id>/{system,user}*.journal.

То есть, если есть какая-нибудь маленькая програмулина prog1, то логи будут оседать в /var/log/journal/<machine_id>/user.journal. Мне было бы удобно указать в конфигурации где-нибудь писать в /var/log/journal/<machine_id>/prog1.journal. Ну а потом открывать скажем journalctl --file /var/log/journal/<machine_id>/prog1.journal.

В rsyslog это можно сделать до сих пор, почему в systemd этого до сих пор нету? Зачем скопом складывать логи в один файл, а потом заставлять юзера это все фильтровать?

vitalikp
()

Если какую-либо проблему упорно отрицать вместо поиска решения, за неё возьмётся Поттеринг и создаст ещё одну.

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

Настраиваемая ротация вроде как не планируется.

В треде про похожую проблему было объяснение того, почему это сложнее, чем кажется:

To allow per-service retention times would mean we'd either have to split up the journal files per-service from the beginning (which would suck perfomance-wise while viewing), or we'd have to «repack» the files during rotate/vacuuming (which would suck perfomance-wise while roating/vacuuming).

Если это действительно критично — юзай rsyslog, журнал далеко не панацея.

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

В треде про похожую проблему было объяснение того, почему это сложнее, чем кажется:

Да ладно. Ну никто же не говорит все процессы и программы дробить. Если пользователь задаст 3-4 патерна на запись в разные файлы ничего с производительностью не случится. Зато потом что-то найти шансов намного больше. И кстати реализация может просто банальной как это сделано в том же rsyslog. Да производительность где-то просядет, но если пользователь не против почему нет? Как по мне это лучше, чем потом парсить большой файл из ненужной информации(на что тоже кстати надо время и производительность!). Как минимум должен быть выбор.

Если это действительно критично — юзай rsyslog, журнал далеко не панацея.

это критично для серверов.

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

Как по мне это лучше, чем потом парсить большой файл из ненужной информации(на что тоже кстати надо время и производительность!)

Скипать ненужные записи при чтении из одного файла — куда быстрее, чем мерджить записи из нескольких файлов. Особенно в том случае, когда требуется навигация по общему потоку данных.

Если пользователь задаст 3-4 патерна на запись в разные файлы ничего с производительностью не случится.

А может задать 100, и наивная реализация задумается на пару часов.

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

intelfx ★★★★★
() автор топика

В состав проекта systemd под именем systemd-boot был влит исходный код UEFI-загрузчика gummiboot.

systemd-importd теперь способен импортировать контейнеры из локальных tar-архивов, побайтовых (.img, .raw) и .qcow2-образов, а также записывать их в tar-архивы и побайтовые образы.

Даже мне стало страшновато.

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

А что не так-то? Предлагаешь (исключительно ради душевного спокойствия сторонних наблюдателей) разнести по разным репозиториям и вследствие этого мучаться с опакечиванием в десять раз больше? Писать-то всё равно будут одни и те же люди.

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

В общем-то, у меня всё работает и каких-то проблем именно с системд не было.
А то, что не юниксвей и комбайн, это да.

GblGbl ★★★★★
()

В ядре, Карл!

Изменения в ядре systemd

У systemd появилось собственное ядро! Ядро, Карл!

Camel ★★★★★
()

А теперь ещё и легковесный загрузчик для UEFI (бывший gummiboot)

Но зачем? Я надеюсь, мой EFISTUB без всяких загрузчиков от этого не сломается?

fludardes ★★
()

Каждый раз когда читаю новость на лоре про системд, вызывает рвоту вот такая вот пафосная преамбула как тут есть. Вы пытаетесь убедить себя/всех что он настолько хорош???? Не стОит, он ведь хорош, все знают про это, ведь он же хорош? Ведь правда же хорош? Да? Точно?

Jetty ★★★★★
()

Раздел ESP (EFI System Partition), автоматически монтируемый systemd-efi-boot-generator на /boot, теперь автомонтируется с таймаутом в 2 минуты. Это сделано ради того, чтобы уменьшить риск повреждения раздела при аварийном отключении системы — драйвер VFAT в ядре Linux по-прежнему ни на что не годен.

XD а автомонтирования в смысле «по обращению» не хватало?..

t184256 ★★★★★
()

молодец, как всегда хорошо оформил!

жаль, ты другие новости не пишешь

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

И далее

Ну и круто же! Будет у GNU/Linux два ядра, до поры до времени.

Когда ждать появления в systemd собственного загрузчика...WAIT! OH SHI~

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

мне больше интересно когда systemd своё ядро получит,

Да оно уже у них есть. Линукс называется.

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

Особенно прекрасно ждать двухминутный тайм-аут размонтирования CIFS-шары по Wi-Fi при завершении работы. Этой проблеме не меньше двух лет, если судить по жалобам в интернетах, но всем насрать. Хотя причина, возможно, в драйвере CIFS, а не в systemd.

anonymous
()

таймаут автомонтирования — время, по истечении которого с момента последнего обращения к автоматической точке монтирования она будет отключена.

А что считается обращением? Если я сделаю cd в этот каталог и усну, он отмонтируется/попытается?

disarmer ★★★
()

«Раньше это соответствие можно было изменить, делая вспомогательные юниты runlevel[2-5].target симлинками на ту или иную цель. Оказалось, что устоявшаяся семантика алиасов юнитов в systemd приводит к неразрешимым проблемам при таком подходе.» тоесть наконец признали что совместимость не осилили. ай молодца..

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

«Из состава systemd был исключён вспомогательный демон systemd-shutdownd, предназначавшийся для отложенного завершения работы в стиле shutdown(8). Теперь эта функциональность реализуется в systemd-logind. Интерфейс остался тем же — команда shutdown.(Если в вашей конфигурации systemd-logind не используется, отложенное завершение работы можно устроить с помощью systemd-run и таймерных юнитов — прим. пер.)» оффигеть. теперь даже отход от logind карается принудительным использованием бубна?

anonymous
()

Хм, а «systemd» так и пишется с маленькой буквы, или с большой? Раздражает очень, когда название с маленькой.

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

У code monkeys все так, ибо сначала нашкодят, потом репу чесать начинают, когда что-то пошло не так.

anonymous
()

А еще, в journald так и не появился демон, который отправляет данные журнала в удалённый журнал? Какое то время назад отправляли через curl

disarmer ★★★
()

видел тред на первой странице!

timdorohin ★★★★
()

Команды systemctl enable, systemctl disable и systemctl mask теперь поддерживают параметр --now

Я джва года ждал.

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

Почему? Закопали systemd-shutdownd, предложили две альтернативы, если ты им пользуешься

disarmer ★★★
()

Оказалось, что устоявшаяся семантика алиасов юнитов в systemd приводит к неразрешимым проблемам при таком подходе.

Интересно, что еще окажется в будущем.

в systemd-networkd было исправлено управление IP forwarding

Сломано. Сломано, Карл.

не требуется вручную включать глобальный форвардинг с помощью sysctl-переменных net.ipv[46].ip_forward (более того, эта настройка не подействует на интерфейсы, управляемые systemd-networkd)

Всё для людей, мля.

Многие методы в шинных API systemd, systemd-logind и systemd-machined теперь поддерживают асинхронную авторизацию через polkit и могут использоваться непривилегированными процессами.

Но ведь polkit устарел и ненужен!!111

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.