LINUX.ORG.RU

Выпуск systemd 244

 


0

0

Среди изменений:

  • новое лого;
  • сервисы теперь можно привязывать к CPU через cgroup v2, т.е. поддержка cpuset cgroups v2;
  • можно определить сигнал для рестарта сервиса (RestartKillSignal);
  • systemctl clean теперь работает и для юнитов типа socket, mount и swap;
  • systemd теперь пытается вычитывать конфигурацию из переменной EFI SystemdOptions как альтернатива изменения параметров ядра из загрузчика;
  • systemd отменяет лимиты printk, чтобы уж точно схватить все логи во время загрузки (и потом применяет свои лимиты);
  • добавлена поддержка загрузки настроек из директорий типа «{unit_type}.d/», чтобы применить настройки ко всем юнитам данного типа;
  • в systemctl добавлено 'stop --job-mode=triggering', чтобы останавливать и зависимые юниты;
  • улучшено отображение зависимостей в Unit status. Теперь показывает зависящие юниты и юниты, от которых зависит;
  • очередные улучшения для работы с PAM сессиями. Добавлено ограничение общего времени жизни сессии с принудительным разлогином;
  • новая группа для системных вызовов @pkey, сразу разрешает все memory syscalls для контейнеров;
  • для udev добавлена программа fido_id;
  • исправления в работе udev с CDROM;
  • systemd-networkd больше не создает маршрут по умолчанию для сетей 169.254.0.0/16 (диапазон для автоконфигурации);
  • systemd-networkd теперь может объявлять новые IPv6 маршруты;
  • systemd-networkd теперь сохраняет конфигурацию DHCP при рестарте;
  • добавлены новые опции в systemd DHCPv4 и DHCPv6 сервер;
  • в systemd-networkd добавлены опции для трафик шейпинга;
  • поддержка devicetree-overlay;
  • systemd-resolved поддерживает проверку имен через GnuTLS;
  • systemd-id128 теперь может генерировать UUID;
  • добавлено опциональное ограничение для юнитов, не позволяющее читать им логи ядра.

>>> Подробности

★★★★★

Проверено: Satori ()
Последнее исправление: Satori (всего исправлений: 6)
Ответ на: комментарий от Legioner

, а не как раньше на баше куча строк и фиг знает работает-нет.

Странно, у меня это всегда был просто путь до демона в одной строчке.

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

пример инит скрипта в одну строчку в студию!

#! /bin/sh
hakavlad ★★★
()
Ответ на: комментарий от Shadow

До какого демона? Покажи как ты будешь запускать java процесс, например? Со стопом, рестартом, статусом, PID-файлом. Я делал, я знаю. Там несколько десятков строк кода, которые надо каждый раз писать заново и тестировать. Это гемор. В systemd это меньше десятка строк, которые даже тестировать не надо, оно просто работает. Причём в systemd уйма фишек, которые пишутся одной строчкой и каждая из которых заменяет кучу строк в баш скрипте. Причём ладно я, мне оно надо раз в год, могу и написать. А в большом масштабе это же сотни или даже тысячи init-скриптов. systemd сделал абсолютно правильно - он сделал DSL для сервисов и вынес весь нужный функционал в некое подобие библиотеки. Причём раньше подобное делали из дерьма и палок. В том же дебиане были такие «библиотеки» из шелл-скриптов. Проблема в том, что в каждом дистрибутиве они свои. А тут один штандарт.

Я не фанат systemd в том плане, что мне не близки многие их порывы. Например параллельный запуск сервисов. Да, оно круто, моя VPS стартует по-моему за долю секунды. Но мне оно не надо, стартовала бы она за 10 секунд, я бы не расстроился. Десктопы ребутать всё равно не нужно, их нужно усыплять. Правильные серверы только в биосе жужжат минут 15, тут тоже экономия не нужна. А багов этот параллельный запуск сервисов привносит. Журналд мне тоже не нравится. Меня текстовые файлы всегда устраивали. Как оно щас работает я вообще не понимаю. У меня в Debian вроде стоит systemd а логи и в /var/log/apache2 лежат и в /var/log/mail.log пишутся и в journald тоже что-то есть. Но это всё мелочи. Суть в том, что старый init был слишком плох, а они его сделали нормальным.

При этом если бы старый init оставили как есть, а вместо init-скриптов было бы что-то вроде

#/bin/daemon
[Unit]
Description=Foo

[Service]
ExecStart=/usr/sbin/foo-daemon

Причём, что важно, во всех дистрибутивах, я был бы ещё больше рад. Юникс-вей и всё такое. Но и текущая система вполне неплоха.

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

Причём, что важно, во всех дистрибутивах, я был бы ещё больше рад. Юникс-вей и всё такое. Но и текущая система вполне неплоха.

Проблема в том, что systemd энкапсулирует ещё и безопасность всякую, что вообще не кошерно. Типа каждая фигня должна своим заниматься. А тут подстава. И всё типа подхватили. Короче – это фаталити. Не гресйсфул, бат деградэйшн. Виндоз ой-вей.

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

Покажи как ты будешь запускать java процесс, например?

Наверно, сделаю ему нормальный cli?

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

ну тоесть реализовать свою версию systemd в каждом сервисе отдельно?

нет, просто монитор процесса … а не комбайн с массой ненужных велосипедов - http-сервером, графом зависимостей, системой логов и т.д. и т.п.

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

«До какого демона? Покажи как ты будешь запускать java процесс, например? Со стопом, рестартом, статусом, PID-файлом. Я делал, я знаю. Там несколько десятков строк кода, которые надо каждый раз писать заново и тестировать» это надо сделать один раз. а дальше использовать. причем этот самый один раз надо написать на языке который не менялся уже дцать лет. и на котором (если голова дурная и руки кривые) можно отлаживаться и логироваться не мешая и остальным запущенным в системе процессам.. в отличии от systemd-хрени которая не позволяет ни нормального логирования (ибо само логирование глючит) и не имеет совместимости с синтаксисом хотя бы двухлетней давности, я уж молчу о сохранении семантики.

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