LINUX.ORG.RU

Выпуск systemd 213

 ,


0

4

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

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

  • Новый демон «systemd-timesyncd» для синхронизации времени по сети. С целью упрощения реализованы лишь возможности SNTP-клиента, код не перегружен излишней серверной функциональностью. Демон запускается с минимумом привилегий и умеет взаимодействовать с networkd, чтобы работать только при наличии подключения к сети. Кроме того, он умеет периодически сохранять текущее время на жестком диске и при следующей загрузке сразу восстанавливает его, не дожидаясь начала очередной синхронизации. Это полезно для устройств, в которых отсутствуют часы реального времени (Raspberry Pi, встраиваемые устройства). Восстановленное при загрузке время будет не самым точным, но это лучше, чем ничего. При этом, требуется создание в системе отдельного пользователя и группы «systemd-timesync».
  • Отключена поддержка «seqnum» в libudev, поскольку, если устройства находятся в различных пространствах имён, их номера не будут последовательны.
  • Для «systemctl list-timers» и «systemctl list-sockets» добавлен ключ --recursive, отображающий юниты указанного типа для всех локальных контейнеров.
  • Служебные юниты получили новую директиву RebootArgument=, с помощью которой можно передать ядру аргументы для следующей перезагрузки, если перезагрузка осуществляется через использование StartLimitAction=.
  • Кроме того, этим же юнитам добавлена директива FailureAction=, через которую можно указать, какие операции будут выполнены в случае сбоя сервиса. Все это работает аналогично директиве StartLimitAction=, но в данном случае, указанные операции будут выполнены немедленно после первого же сбоя, а не после нескольких попыток перезапуска проблемного сервиса.
  • Утилита hostnamed теперь может работать с информацией об имени ядра, релизе и версии.
  • На графики, создаваемые утилитой bootchart, добавлены сведения cgroup.
  • Сервисы получили поддержку опции CPUQuota=, с помощью которой можно жестко ограничить в процентах потребление сервисом процессорного времени. Это значение не будет превышено, даже если процессор простаивает.
  • systemd-networkd обучен поддержке IPIP и SIT-туннелей.
  • Скриптам инициализации LSB добавлена зависимость от network-online.target, вместо network.target. За счёт этого, их поведение становится более похожим на то, каким оно было в SysV.
  • Добавлена поддержка опции ядра fsck.repair=, которая определяет, что fsck сделает при загрузке с некорректно отмонтированными файловыми системами.
  • Парсер конфигов (.ini) теперь игнорирует разделы, имена которых начинаются с «X-». Это открывает дорогу к созданию в конфигах специфичных разделов для нужд других приложений.
  • machined получил новый API для запроса IP-адресов зарегистрированных контейнеров.
  • Добавлен новый вызов call sd_uid_get_display(), позволяющий запросить информацию об основной сессии пользователя. Основная сессия выбирается из числа всех сессий. Например, графическая сессия будет предпочтена текстовой.
  • У systemd-networkd появился компаньон — крохотный демон systemd-resolved, который вносит изменения в resolv.conf, основываясь на конфигурации DNS для сетевых интерфейсов. В будущем, сюда добавят локальный кэш DNS и mDNS с поддержкой DNSSEC.
  • Включена по умолчанию утилита systemd-networkd-wait-online, которая вносит задержку в network-online.target до того момента, пока не будет настроено подключение к сети.
  • Две новых опции: StartupCPUShares= и StartupBlockIOWeight=. Они работают аналогично CPUShares= и BlockIOWeight=, но только при загрузке системы.
  • hostnamed теперь предпочитает брать имя хоста из /etc/hostname, если оно там указано, а не через DHCP. В systemd, параметры, определённые локальным администратором, традиционно имеют больший приоритет, чем любые другие.

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

anonymous

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

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

давай, попробуй

после этого покажешь, в каком месте systemd - одна большая программа, а я посмеюсь

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

ну так покажи как надо

а иначе это банальное сектантство - «у нас есть Великая Идея, но еретики извратили Её, и только мы своими молитвами защищаем Её чистоту!»

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

А почему бы все эти usb.ko, ext3.ko, i915.ko не сделать отдельными программами (пакетами)? Получилось бы вполне разумно, логично, надёжно и юниксвейно.

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

А почему бы все эти usb.ko, ext3.ko, i915.ko не сделать отдельными программами (пакетами)?

Они и сделаны отдельными программами.

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

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

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

А почему бы все эти usb.ko, ext3.ko, i915.ko не сделать отдельными программами (пакетами)?

Они и сделаны отдельными программами.

Ровно так же, как и *d, *ctl.

Не «ровно». «Все эти usb.ko, ext3.ko, i915.ko» - фактически отдельные проекты.

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

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

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

Не «ровно». «Все эти usb.ko, ext3.ko, i915.ko» - фактически отдельные проекты.

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

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

Не «ровно». «Все эти usb.ko, ext3.ko, i915.ko» - фактически отдельные проекты.

В данном контексте — неправда.

Ты просто мало знаешь.

Между драйверами и ядром точно так же нет стабильного API

Это по многим причинам совершенно неважно и даже не стоит упоминания.

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

Ты просто мало знаешь.

Что понимается под «мало» или «много»?

Это по многим причинам совершенно неважно и даже не стоит упоминания.

По каким? И что тогда вообще важно?

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

Что понимается под «мало» или «много»?

То, что для заявления «неправда, что ext3 - отдельный проект» нужно не знать историю развития ext3 (да и ext4). Ты же вроде интересуешься reiser4? Тогда тем более странно твое «неправда», потому что reiser4 - тоже отдельный проект.

Между драйверами и ядром точно так же нет стабильного API

Это по многим причинам совершенно неважно и даже не стоит упоминания.

По каким?

Во-первых, API ядра довольно стабильно (если не лезть куда не просят, как тот же Reiser4); во-вторых, нестабильность API - это некоторое осложнение и без того сложной работы, но на «отдельность» проекта не влияет; в-третьих, основная разработка происходит на некоторой выбранной версии ядра, а после достижения некоторой степени завершенности происходит интеграция d более новую версию.

И что тогда вообще важно?

Место в архитектуре и coupling: место драйверов и ФС в архитектуре ядра таково, что у них есть возможность быть отдельными проектами (не обязанность, но возможность); а вот VFS, например, я с трудом представляю в виде отдельного проекта. Сложность и размер: любая кодовая база по достижению достаточного размера и сложности становится отдельным проектом, это закон природы. Release schedule (само по себе это не очень важно, но служит свидетельством того, что разработка идет в своем темпе и результаты интегрируются в ядро по готовности) :

pci_hotplug: PCI Hot Plug PCI Core version: 0.5
pciehp: PCI Express Hot Plug Controller Driver version: 0.4
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.07
Bluetooth: Core ver 2.16
bbswitch: version 0.8

(список не претендует на полноту).

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

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