LINUX.ORG.RU

systemd 216

 , ,


1

2

systemd — это менеджер системы и сессий для Linux. systemd совместим со скриптами инициализации SysV и LSB. Он предоставляет возможности агрессивного распараллеливания, использует для запуска сервисов сокеты и D-Bus активацию, позволяет запускать демоны по требованию, реализует транзакционную зависимостную логику управления сервисами, отслеживает процессы с использованием Linux cgroups, поддерживает создание снимков и восстановление, а также заведует монтированием и точками автомонтирования.

Это мажорный выпуск. Помимо прочих изменений, systemd-resolved теперь гармонично дополняет распознаватель заглушек кэширования DNS и LLMNR.

  • timedated больше не читает имена юнитов реализации NTP из /usr/lib/systemd/ntp-units.d/*.list. Альтернативная реализация NTP добавляет
    Conflicts=systemd-timesyncd.service
    в их юнит-файлы, заменяя собой функциональность NTP systemd по умолчанию.
  • systemd-sysusers получила новый тип строки «r» для настройки того, из каких диапазонов UID/GID выделять системных пользователей/группы. Строки типа «u» теперь могут добавлять дополнительную колонку для обозначения домашней директории создаваемого пользователя. Кроме этого, systemd-sysusers теперь может опционально считывать пользовательскую информацию из STDIN вместо файла. Это полезно вызове её из предустановочных скриптлетов RPM, которым нужно создать пользователей перед установкой первого файла RPM, так как этим файлам может требоваться владение этими пользователями. Новый макрос RPM %sysusers_create_inline представлен именно для этой задачи. systemd-sysusers теперь обновляет теневые файлы наряду с базами пользователей/групп, что улучшает совместимость с некоторыми инструментами, например, grpck.
  • Ряд шинных API PID 1 теперь опционально запрашивает у PolicyKit, предоставить ли доступ считающимся непривилегированными клиентам при определённых условиях. Имейте в виду, что интерактивная аутентификация в данный момент пока не поддерживается, но в конечном счёте ожидается добавление и её.
  • /etc/machine-info теперь обладает новыми полями для настройки среды развёртывания машины, а также месторасположения машины. hostnamectl обновлён и снабжён новой командой для обновления этих полей.
  • systemd-timesyncd обновлён до автоматического запроса информации о NTP-сервере у systemd-networkd, который можно обнаружить по DHCP.
  • systemd-resolved теперь включает распознаватель заглушек кэширования DNS и полную реализацию разрешения имён LLMNR. Добавлен новый модуль NSS «nss-resolve», позволяющий использовать собственный «nss-dns» glibc для обнаружения имён хостов через systemd-resolved. Имена хостов, адреса и произвольные RR'ы можно распознавать через D-Bus API systemd-resolved. В отличие от внутреннего распознавателя glibc, systemd-resolved умеет работать с многодомными системами и удерживает DNS-сервера и кэши отдельно и поинтерфейсно. Запросы посылаются одновременно на все интерфейсы, имеющие настроенные DNS-сервера, для корректной обработки VPN и локальных LAN, которые могут распознавать отдельные наборы доменных имён. systemd-resolved может запрашивать информацию о DNS-серверах у systemd-networkd автоматически, который, в свою очередь, может находить её по DHCP. Нововведённый инструмент «systemd-resolve-host» можно использовать для запроса логического DNS у resolved. systemd-resolved реализует IDNA и автоматически использует IDNA или кодировку UTF-8 в зависимости от того, используется ли в качестве транспорта классический DNS или LLMNR. В следующих выпусках планируется добавить в systemd-resolved реализацию DNSSEC и mDNS/DNS-SD.
  • Добавлен новый модуль NSS nss-mymachines, автоматически распознающий имена всех локально зарегистрированных контейнеров по соответствующим IP-адресам.
  • Добавлен новый клиентский инструмент для systemd-networkd — «networkctl». В настоящий момент он полностью пассивен и запрашивает сетевую конфигурацию у udev, rtnetlink и networkd, предоставляя её пользователю дружественным способом. В будущем планируется расширить его до полноценной утилиты для управления networkd.
  • .socket-юниты получили новую настройку DeferAcceptSec=, управляющую sockopt ядра TCP_DEFER_ACCEPT для TCP. Аналогично, для управления TCP Keep-Alive добавлены KeepAliveTimeSec=, KeepAliveIntervalSec= и KeepAliveProbes=. Также поддерживается отключение алгоритма Nagle для TCP (NoDelay=).
  • logind обучен новому типу сессий «web» для использования в проектах наподобие Cockpit, регистрирующих web-клиентов как PAM-сессии.
  • Юниты-таймеры с как минимум одной настройкой OnCalendar= теперь будут запускаться только после достижения timer-sync.target. Таким образом, они не будут проходить перед подстройкой системных часов локальным NTP-клиентом или чем-то подобным. Отчасти это полезно на встраиваемых системах без RTC, запускающимся со сбитыми системными часами.
  • Ключ systemd-nspawn --network-veth= теперь приводит к стабильным MAC-адресам как на внешней, так и на внутренней стороне соединения.
  • systemd-nspawn получил новый ключ --volatile= для запуска экземпляров контейнеров с незаполненными /etc или /var.
  • Клиентский код kdbus обновлён для использования новой подсистемы Linux 3.17 memfd вместо старой, kdbus-специфичной.
  • DHCP-клиент и -сервер systemd-networkd теперь поддерживают FORCENEW. Также есть новые параметры конфигурации для настройки клиентского идентификатора поставщика и режима вещания для DHCP.
  • systemd больше не будет уведомлять ядро о текущем часовом поясе, так как это в любом случае неверно и колоритно, поскольку ядру неведом DST и подобные понятия. Как следствие, временные метки FAT будут всегда считаться UTC, примерно как это уже делает Android. Помимо этого, когда RTC настроены на локальное время (отличное от UTC), systemd никогда не будет синхронизировать их обратно, так как это может смутить Windows при последующей загрузке.
  • systemd-analyze получил новую команду «verify» для оффлайн-валидации юнит-файлов.
  • systemd-networkd получил поддержку парочки дополнительных настроек для слития настроек сети. Также теперь можно настраивать метрику статично настроенных маршрутов. Для сетевых интерфейсов в случае необходимости можно настроить IP-адрес пира.
  • DHCP-сервер systemd-networkd больше не будет запрашивать вещание по умолчанию, так как это роняло некоторые сети. Для оборудования, где вещание необходимо, возможность можно включить обратно с помощью RequestBroadcast=yes.
  • systemd-networkd теперь задаёт адреса IPv4LL (если включено) даже если DHCP успешно настроен.
  • udev теперь по умолчанию отдаёт предпочтение именам сетевых устройств, предоставляемым ядром, если ядро указывает, что они предсказуемы. Это поведение можно изменить изменением NamePolicy= в соответствующем .link-файле.
  • Добавлена новая библиотека systemd-terminal, реализующая полную обработку и отображение TTY-потоков. Эту библиотеку планируется использовать в будущем для реализации подсистемы виртуальных терминалов целиком в пространстве пользователя, взамен текущей реализации в ядре.
  • Добавлен новый инструмент systemd-journald-upload для передачи данных журнала на удалённую систему с запущенным systemd-journal-remote.
  • journald больше не будет передавать все локальные данные другому запущенному syslog-демону. Это изменение сделано, поскольку rsyslog (являющийся на сегодняшний день наиболее широкоиспользуемой реализацией rsyslog) их больше не использует, и вместо этого вытягивает из журнала в свой собственный. Поскольку передача сообщений несуществующему syslog-серверу слишком затратна, было решено просто выключить её. Если у вас запущен syslog-сервер, отличный от последней версии rsyslog, эту опцию нужно снова включить (ForwardToSyslog= в journald.conf).
  • journald опционально поддерживает LZ4-компрессор для больших полей журнала. Этот компрессор работает намного лучше XZ, который использовался по умолчанию ранее.
  • machinectl теперь показывает IP-адреса локальных контейнеров, если знает их, плюс имя интерфейса контейнера.
  • Добавлен новый инструмент «systemd-escape», позволяющий легко экранировать строки для создания имён юнитов и т. п.
  • Сообщения sd_notify() теперь могут содержать новое поле ERRNO=, которое обрабатывается и сохраняется systemd, чтобы потом его можно было отобразить в выводе «systemctl status» для сервиса.
  • Добавлен новый компонент «systemd-firstboot», интерактивно запрашивающий для systemd наиболее базовую информацию (часовой пояс, имя хоста, пароль root) при первой загрузке. Ещё его можно использовать для предоставления этих вещей оффлайн в образах ФС, установленных в директории.
  • Сниппеты sysctl.d/ по умолчанию теперь выставляют net.ipv4.conf.default.promote_secondaries=1. Это позволяет не сбрасывать вторичные IP-адреса, когда первичные удалены.

>>> Источник

★☆

Проверено: fallout4all ()
Последнее исправление: JB (всего исправлений: 4)

Ответ на: комментарий от Lincor

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

Как известно, ядро существует для юзерспейса, а не наоборот.

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

POSIX - вековой стандарт. если его сломать, мир *nix падет.

Совершенно голословное утверждение. Если стандарт (POSIX) не позволяет реализовать нужную вещь, значит, такой стандарт говно и его необходимо выкинуть.

intelfx ★★★★★
()

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

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

Стандартизация говна

Некоторым, знаешь, и без заплесневелого сыра - не жись.

...и даже Linux нужно обмазать любимым вонючим продуктом.

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

и меньше ломаться..

А если ломаться, то все и сразу.

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

Никуда не торопятся, просто не используют подверсии.

MiniRoboDancer ★☆
() автор топика
Ответ на: комментарий от eugeno

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

Нормальному пользователю вообще пофиг на чем работать, хоть на винде. А мы на лоре, какие тут нормальные пользователи?

mandala ★★★★★
()

Урраа!

Свежий баттхёрт подвезли :-D

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

как я уже заметил, придется копировать Linux.

да, как на бзде с линуксулятором и kms. чтобы хоть что то она могла

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

Если я, как владелец крупного завода крепежных изделий, решу выпускать гайки с резьбой прямоугольного профиля, продавлю свои гайки на рынок, задокументирую свои гайки, то мои крепежные гайки с прямоугольным профилем станут (при наличии документации и возможности альтернативной реализации) автоматом стандартом?

И все радостно должны свои побегут изготовлять/менять с/на другой резьбой, т.к. они не подходят к новым «типа стандартным» гайкам а другие вы выдавили? Ахринеть стандартизация...

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

Что и хох, ой, дистросрачи прекратятся?! "... Жаль только - жить в эту пору прекрасную/ уж не придётся - не мне, ни тебе..."

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

иди почитай про cgroups и контейнеры

ещё про epoll, sendfile для развития

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

Вот чем оно лучше openrc? Можно подумать, что openrc исчерпал свой потенциал развития и вообще ни к чему уже не годен, но ведь это не так.

Всем лучше. Так что опенрц ещё потенциал не исчерпал - им ещё лет 10 фичи system копипастить.

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

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

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

...что у него там занимается инициализацией, а спокойно работает.

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

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

к тому что всё будет замечательно работать и меньше ломаться..

Это в перспективе. На деле пока должна быть обратная ситуация: большое количество шел лапши заменили блобами, init вырос на несколько порядков в размере и вряд ли его кто-то тестировал. Появилось большое количество демонов, а они имеют свойство утекать. Поэтому вряд ли это будет меньше ломаться.

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

например приведи аналог systemd-nspawn.

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

Оно занимается не только инициализацией, а всем подряд.

Ну и что? Тебе это как-то мешает?

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

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

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

Побегут, а куда денутся? Как будто в в нашу жизнь не вошли таким образом Torx holes, double pins и другие, ещё более экзотические виды крепежей - замучаешься биты подбирать.

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

Мне это почему-то напоминает выражение из вселенной Dead Space: «Сделай нас единым!»

We are Borg. Resistance is futile. You will be assimilated.

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

Наоборот же. Я вот часто иниты редактирую, поэтому мне systemd нравится.

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

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

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

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

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

Значит, это проблема альтернативных систем.

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


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

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

В альте.

Нутыпонел.

В дебиане.

Который ещё тестинг.

И даже иногда, хе-хе, в самой расправославной федоре.

Надеюсь, это был сарказм.

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

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

а то так можно и под одну венду писать. не, ну а чо, WinAPI удобный.

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

Давай ты лучше помогать будешь «обычных пользователей линукса» с проблемами, а не трыньдеть. А то как потрындеть все мастаки, а как у кого проблема - и нет шпециалистов...

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

Ненавидят его только те, кто непосредственно с инитами не работает.

Как можно быть таким малограмотным? systemd давно уже не инит.

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

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

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

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

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

Когда же уже код этой поделки от нововведений затрещит по швам и расползется? :)

Не затрещит и не расползется. Можешь даже не мечтать.

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

Давай ты лучше помогать будешь «обычных пользователей линукса» с проблемами

Проблемы себе создают сами пользователи. У меня нет проблем.

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

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

А ха-ха... Ты чувак точно значение слова не понимаешь :) Давай уж не позорься :)

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

А ну да. на все вопросы - УМВР это выход. А у кого не работает - обращайтесь в службу поддержки RH

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

Это закат мира GNU/Linux, как ни прискорбно осознавать.

Посмотрим, может быть, сообщество еще что-нибудь из себя выдавит. Какой-нибудь Alpine Linux https://lkml.org/lkml/2014/8/13/623

перехожу на FreeBSD

Содомиты в треде!

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

systemd давно уже не инит.

Да пусть он будет хоть целой операционной системой, что с этого? Работает — и отлично. А не работает — выкинь нафиг линукс. Или религия не позволяет?

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