LINUX.ORG.RU

Релиз systemd 230

 


4

8

Представлен выпуск системного менеджера systemd 230. Из новшеств можно отметить включение по умолчанию DNSSEС и режима чистки процессов пользователя после завершения сеанса, поддержку унифицированной иерархии cgroup, возможность настройки прокси ARP для сетевого интерфейса, новые типы юнитов generated и transient, новую команду systemctl revert и возможность создания виртуальных прямых сетевых ссылок между контейнерами.

Основные изменения:

  • В DNS-резолвере systemd-resolved по умолчанию включен DNSSEC. DNSSEC доступен в режиме allow-downgrade (автоматический откат на режим без DNSSEC) и может быть отключен через настройку DNSSEC в resolved.conf или на этапе сборки при указании опции configure --with-default-dnssec=no. Дистрибутивам пока не рекомендуется включать DNSSEC по умолчанию, пока не будут выявлены все возможные несовместимости режима DNSSEC с DNS-серверами.
  • В systemd-resolve добавлена возможность резолвинга DNS-записей DANE (DNS-based Authentication of Named Entities) при указании опции --tlsa и OPENPGPKEY при указании опции --openpgp, а также создания дампа raw-данных записей DNS при указании опции --raw=дамп.
  • В systemd-logind по умолчанию обеспечено принудительное завершение процессов, запущенных в составе пользовательского сеанса, после выхода пользователя из системы. Управлять принудительным завершением можно через опцию KillUserProcesses в logind.conf, которая теперь выставлена в значение yes по умолчанию, что требует отдельных настроек, если необходимо сохранить работу длительно выполняемых пользовательских процессов (для работы screen и tmux требуется специальная настройка сервисов, например, включение т.н. lingering через loginctl). Для восстановления старого поведения на этапе сборки можно указать опцию --without-kill-user-processes.
  • В systemd-logind добавлены новые настройки SessionsMax и InhibitorsMax, которые по умолчанию установлены в значение 8192.
  • В systemd-logind добавлена поддержка обновления конфигурации по сигналу SIGHUP.
  • Добавлена поддержка унифицированной иерархии cgroup (в ядре с 4.5), для задействования которой в systemd при загрузке требуется указать опцию командной строки ядра systemd.unified_cgroup_hierarchy=1. Для унифицированной иерархии также добавлен контроллер cgroup io, который дополнил контроллеры memory и pids.
  • Поддержка протокола LLDP (Link Layer Discovery Protocol) расширена возможностями использования пассивного (только приём) и активного (отправка) режимов. Пассивный режим включен по умолчанию в systemd-networkd, а активный режим включен по умолчанию в изолированных контейнерах с адресацией внутренней сети. Для просмотра статистики можно использовать команду networkctl lldp.
  • Добавлена возможность настройки уникальных идентификаторов IAID и DUID, отправляемых в запросах DHCP. Идентификаторы могут быть определены как для всей системы, так и для отдельных файлов .network при помощи опций DUIDType, DUIDRawData и IAID.
  • В systemd-networkd добавлена возможность настройки прокси ARP для отдельных сетевых интерфейсов, используя опцию ProxyArp в файлах .network. Кроме того, в файлы .netdev добавлены опции MulticastQuerier и MulticastSnooping, позволяющие включить режим отправки запросов и прослушивания IGMP-трафика.
  • В файлах .network представлена новая опция PreferredLifetime, позволяющая определить время жизни IP-адреса.
  • В DHCP-сервере, встроенном в systemd-networkd, активирована по умолчанию опция EmitRouter, включающая поле DHCP Option 3 (Router).
  • Тестовая утилита systemd-activate переименована в systemd-socket-activate и перемещена в /usr/bin.
  • В systemd-journald задействован отдельный поток для сброса прокэшированных данных на диск при закрытии файлов с журналом, что решило проблемы с задержками записи в лог на медленных дисках.
  • В journalctl добавлен новый метод вывода -o short-unix, при котором к записями в логе добавляется префикс с эпохальным (UNIX) временем (число секунд с 1970 года). Также добавлена опция --no-hostname для исключения столбца с именем хоста.
  • Устройства фреймбуфера, сканеры и 3D-принтеры теперь подключаются в режиме uaccess и доступны для вошедших в систему пользователей.
  • В опции DeviceAllow теперь можно указывать спецификаторы (начинаются с символа %).
  • В systemctl show добавлена опция --value, позволяющая вывести только содержимое заданного свойства юнита без указания его имени.
  • Для автоматически сгенерированных и созданных в процессе работы через обращения к API файлов добавлены новые типы юнитов generated и transient.
  • Добавлена новая команда systemctl revert для отката к предоставляемой поставщиком версии файла юнита в случае внесения в файл юнита локальных изменений.
  • В machinectl clean добавлена возможность автоматического удаления всех или только скрытых образов контейнеров.
  • В systemd-tmpfiles добавлен новый тип записи «e», позволяющий организовать очистку директорий, если они уже существуют.
  • В systemd-nspawn добавлена поддержка автоматического исправления UID/GID и ACL для всех файлов и директорий в контейнере для их соответствия диапазону UID/GID, выбранному при запуске контейнера.
  • В systemd-nspawn добавлена новая опция --network-zone для создания виртуальных прямых линков между контейнерами.
  • Для socket-юнитов добавлены опции TriggerLimitIntervalSec и TriggerLimitBurst для настройки лимитов на возможное число активаций в заданный промежуток времени.
  • Компонент systemd-bootchart вынесен в отдельный репозиторий.
  • Из состава удалён systemd-bus-proxyd, так как kdbus вряд ли будет принят в ядро в своём текущем виде.
  • Удалены библиотеки libsystemd-daemon.so, libsystemd-journal.so, libsystemd-id128.so и libsystemd-login.so, которые ранее были объявлены устаревшими.
  • Удалена опция Capabilities, вместо которой следует использовать AmbientCapabilities и CapabilityBoundingSet.

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

★★★★

Проверено: Falcon-peregrinus ()
Последнее исправление: Klymedy (всего исправлений: 5)
Ответ на: комментарий от Deleted

А, забей, все молодые wiki это проходят сдуру, щас напишу «кому-следует», пусть анонимное добавление статей и юзеров у себя выключат и базу почистят. И запретят добавление кому-ни-попадя. Бывает, причем оооочень часто.

И да, systemd тыт не при чём :)

P.D. - И это вобще не ко мне, это не моя вики. Хуанито сотоварищи бодать надо. 8)

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

Вот о том я и говорил - это вопрос религии, а не технической стороны.

С технической стороны всё в порядке, как видишь.

Не поверишь - мне по барабану, «как оно щас».

То есть тебя не интересует развитие проекта, но при этом хватает наглости щеголять багами двухлетней давности как текущими?

да еще в век, где виртуальную машину поднять - дело пары минут...

На домашнем железе десятилетней давности? Ню-ню...

рейт лимит на сообщения kmsg

Не очень хорошее решение, debug на этом самом железе обрекает ядро на долгий чехлёж. Заметь, ядро, не systemd.

Посмеюсь молча...

Хорошо смеётся тот, кто флэшки вручную не монтирует.

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

Нет, на месте этого Кэя я бы всё-таки переименовал юзерспейсный флаг в какой-нибудь sysdebug, чтоб месиво не создавать.

border-radius
()

Флаг quiet перехватывают все, кому не лень. И ничего, как-то живём. Здесь я строго на стороне разработчиков systemd, потому что «generic terms are generic, not the first user who owns them» (KS).

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

P. S.: leave, верни ветку. Ты покромсал половину существенного обсуждения.

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

на самом деле виновато именно ядро

Кто бы сомневался ))

King_Carlo ★★★★★
()

Мне как программисту гораздо приятнее не systemd, а openrc и всякие SysV Init.

Потому что здесь модульность хорошая и независимость между модулями. Если оно следит за живучестью системы, оно только и следит. Если оно управляет процессами, оно только управляет. Можно хорошо абcтрагироваться. А у systemd тенденция пихать все в одну кучу.

Может пока это актуально сейчас, но systemd пытается быть как ядро, таким монолитным «exe-шником». Но если ядро хорошо своими модулями и на то есть веские причины не лепить микроядро. То с этой фиговиной как-то не то.

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

Ну, насчёт простыней ядра я чуть далее (третий пост перед твоим) написал, что рейтлимит на сообщения - тоже не выход. Меня смутило именно месиво из сообщений, когда systemd уже запустился, а journald ещё нет. Да, в сравнении с водопадом сообщений от ядра это ничто, но всё же. Если уж перехватывать флаг debug, то, может, тогда уж ввести какой-то уточняющий флаг, чтоб перед загрузкой можно было выбирать, чьи именно сообщения мы хотим увидеть в kmsg - systemd, ядра или обоих?

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

В общем, я Хуану написал, пока тишина.

Я думаю, как проснётся - раздаст там люлей кому следует.

Там их трое голов за всем их веб-хозяйством следить должно (а может уже и больше), кто-то из этого «змейгорыныча» и прощёлкал.

Тебе-же - отдельная благодарность от меня лично за обнаруженный баг на их сайте. 8)

P.S. Обычно такие баги так и всплывают... Или когда квота на винт переполняется. :-D

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

P. S.: leave, верни ветку. Ты покромсал половину существенного обсуждения.

Что, деньги не заплатили? ;-)

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

Комментарии не восстанавливаются, а 7.1 беспощаден.

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

Во, то, что надо. Смотрится костыльновато, но работает. Вопрос исчерпан, спасибо.

border-radius
()
Ответ на: комментарий от Olegarch

Прекращай уже через каждый коммент краcоваться, двигaть тазом и всеми силами показывать, какой ты олдфаг и умудренный опытом старец.

Со стороны выглядт просто омерзительно. По сyщеcтву говори ёпта.

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

В общем, я Хуану написал, пока тишина.

Тоже написал. Ему надо напоминать.))

Тебе-же

нам же. всё это нам же от нас же)

P.S. Очень клёвый дистр. На лоре узнал про него случайно.

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

Потому что есть openrc и upstart. Да и sysvinit никто не отменял. А ещё есть незаслуженно забытый initng.

еще есть runit ставил Void Linux на ту же машину, где до этого жила Федора. Даже не по впечатлениям Войд просто летал по загрузке в сравнении с Ф. (да и пакетный менеджер там нечто реактивное даже в сравнении с dnf)

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

Еще один «пустынник», да еще с puppy на логотипе 8) Забавно ёлки-палки. Экак внезапно все в один тред сошлись.

Еще Void'овцы есть? ;)

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

Очень клёвый дистр. На лоре узнал про него случайно.

Наглядная демонстрация unix-way, - с шелл-скриптами, распараллеленым инитом, который, - я бы не сказал, что медленнее чем systemd/redhat или systemd/debian. Про пакетный менеджер xbps тут уже звучало - прекрасная штука. Сказать кратко - добротный современный дистрибутив, построенный на классических принципах.

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

Она в драгоре еще используется

anonymous
()

Жалко, что убунта на systemd грузится дольше, чем она грузилась upstart.

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

Представь себе

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

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

то что-то в консерватории сильно не так.

systemd теперь уже и за консерватории отвечает?

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

скорость включения пк может иметь значение

пк

Представь себе, помимо ПК в мире есть и другие места применения Linux.

intelfx ★★★★★
()

Мне во всём systemd нравится только принцип unit-файлов. Они значительно проще шелл-скриптов. Писал инит-скрипты для centos6 и unit для centos7. В первом случае, пришлось плясать со всякими nohup, записываем пида в файл, и ещё чем-то (уже не помню). В случае systemd оно всё делает само, можно любой скрипт сделать демоном, будут и логи, и форкаться в фон не надо.

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

А есть кто-нибудь, кто использует journald в продакшне? Совершенно тормозная штука, грепом по 500-мегабайтному логу пройтись НАМНОГО быстрее, чем сделать journalctl --since ...

А ещё, когда сервер более-менее нагружен, баш-автокомплит к systemctl зависает.

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

Они значительно проще шелл-скриптов

Ерунда. Добавление лишней сущности усложняет а не упрощает систему. И скрипты бывают разные.

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

те многие кто хотят пишут говнокод?

Те многие как хотят не могут договориться о том что именно хотят. А Кей Сиверс, да, пишет код-удобрение, за что получал не раз по носсу ссаной тряпкой от Линуса.

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

А есть кто-нибудь, кто использует journald в продакшне? Совершенно тормозная штука, грепом по 500-мегабайтному логу пройтись НАМНОГО быстрее, чем сделать journalctl --since

Есть. Чтобы перенаправлять в rsyslog и складывать в базу на отдельной машине.

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

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

А вообще, надоел уже этот срач из-за того, что вкуснее: яблоко или груша. Кто что хочет - пусть тот то и ест, но верните уже юникс-вей - свободу выбора. Почему можно выбрать гном, кеды, крысу и тд, но при этом, из всего многообразия систем инициализации надо всем навязывать одну единственную? Почему все должно прибиваться гвоздями к системд? Давайте все гвоздями к нано прибьем или к влц плееру? Почему нельзя сделать минимум необходимых зависимостей и дать свободу выбора - никсы ж не должны превращаться в оффтопик

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

Ну, мы так и делаем. Толку от этого journald никакого.

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

Обращу на него внимание.

я на локалхосте на него уверенно и без особых сожалений слез с дебиана на котором с 2008 года просидел. пробовал все (за исключением «модульных»). до дебиана использовал фрю.

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

Убогое говно. Он нормально работает только с демонами. Недавно делал инитскрипт для unoconv (скрипт на python), так там start-stop-daemon проще вообще не использовать.

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

он по-разному реализован в разных дистрибутивах.
не понятно - какие именно проблемы у тебя были?
+ это не является оправданием крутости конфиг файлов вместо скриптов

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

какие именно проблемы у тебя были?

google://start-stop-daemon+background

он по-разному реализован в разных дистрибутивах

Сорта говна.

это не является оправданием крутости конфиг файлов вместо скриптов

Это какое-то расстройство речи, или мышления?

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

виновато именно ядро

Это значит что ядро linux не достаточно хорошее для systemd?

Да и с инициализацией у systemd не все так гладко. Например в некторых случаях это просто прослойка для init скриптов, что замедляет работу. Это не касается стандартных систем. Но в случае когда в скрипте используется дополнительная логика, демон все равно приходится запускать черех скрипт, а не средствами systemd.

Еще интересно зачем реализовали систему запрета ручного запуска службы? В данный момент от нее никакого толка.

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

некомпетентность и тд, intelfx похоже у тебя в голове что то , ну это, не то...

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

Что такое «by design killer фича»?

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

вы не понимаете что вы защищаете, проверка на null в процессе с пидом 1 - да вы там совсем на своих плюсиках или чем там еще записались, процесс изза которого может встать вся система написан без проверок на возвращение указателя на null - это вы не компетенты, если не понимаете что обращение к null или там к 0x14 какому нить вызывает что? Segmentation fault, обращение к несуществующему в адресном пр-ве процесса адресу, или это модно, стильно молодежно ? Писать кривизну, защищать кривизну, при этом быть некомпетентными разработчиками? Вообщем ваше мнение уже как минимум некомпетентно ага.

Например, к тому, что systemd предоставляет множество удобных абстракций и готовых функций, которые помогают (в том числе) DE-писателям.

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

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

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

Дальше в твоём сообщении конспирологический бред, и я не хочу его комментировать.

Извини мой юных друх, но комментировать твои некомпетентные, пропагандосские (а там много удобного API!) и прочие бред, а тем более далее их комментировать нет желания и времени.

Кстати, конспирологического в моих словах как раз таки 0, а пропагандоса в твоих слова что то близится к 100%. systemd фанбои они все такие.

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

А Кей Сиверс, да, пишет код-удобрение, за что получал не раз по носсу ссаной тряпкой от Линуса.

Где?

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

Это значит что ядро linux не достаточно хорошее для systemd?

Это значит, что в ядре есть баг и его нужно исправить, или же убрать интерфейс kmsg из юзерспейса вообще.

Перевирать прекращаем.

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

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

А я не поддерживаю «выканье» по умолчанию (по возрасту, по уважаемости, etc.).

вы не понимаете что вы защищаете, проверка на null в процессе с пидом 1 - да вы там совсем на своих плюсиках или чем там еще записались, процесс изза которого может встать вся система написан без проверок на возвращение указателя на null - это вы не компетенты, если не понимаете что обращение к null или там к 0x14 какому нить вызывает что? Segmentation fault, обращение к несуществующему в адресном пр-ве процесса адресу, или это модно, стильно молодежно ? Писать кривизну, защищать кривизну, при этом быть некомпетентными разработчиками? Вообщем ваше мнение уже как минимум некомпетентно ага.

Нет, это ты не умеешь разборчиво изъясняться. Я ещё раз спрашиваю: что понимается под фразой «проверка на null в коде pid 1»? Ты имеешь в виду, что во всём коде systemd есть ровно одна проверка на нулевой указатель? Или что её там нет? Или что там вообще нет проверок указателей? Или что? Каков бы ни был ответ, он принимается вместе со ссылкой на код.

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

http://blog.davidedmundson.co.uk/blog/systemd-and-plasma

Это пример. А вообще можно посоветовать почитать документацию к logind. Имеющий глаза да увидит, чем эти вызовы могут быть полезны.

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

Выше.

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

Пипец, чел, как тебя к технике вообще подпускают. Чем дальше читаю твой поток сознания, тем страшнее становится.

ждал два часа

Сразу заняться диагностикой тебе кто не давал, интересно?

снимать белый воротничок

Не-а, надевай воротничок, иди обратно на кассу и не лезь туда, где ни рожна не рубишь.

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

Ах, ну да, я твою аватару не разглядел, вот и принял за чистую монету лол. Подумалось еще: надо же, первый в моей жизни человек, который сказал inetd и не блеванул сразу.

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

Это значит что ядро linux не достаточно хорошее для systemd?

Если ядро падает от шторма сообщений в kmesg - ядро нужно чинить. И не важно какая софтина эту проблему выявит.
Баг нашли, баг исправили. Это хорошо.

kir2yar
()
Ответ на: комментарий от border-radius

Хорошо смеётся тот, кто флэшки вручную не монтирует.

Ништяк =) Возьму на вооружение.

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

Например, к тому, что systemd предоставляет множество удобных абстракций и готовых функций, которые помогают (в том числе) DE-писателям.

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

Я выше приводил пример с loginctl. Это реально удобный и необходимый инструмент при организации терминального сервера под линуксами.

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