systemd

редактировать
Для использования в других целях, см Система D (значения).

systemd
Systemd-logo.svg
Systemd-on-fedora.png запуск systemd в Fedora 17
Оригинальный автор (ы) Леннарт Поеттеринг
Разработчики) Red Hat (Леннарт Поеттеринг, Кей Сиверс, Харальд Хойер, Дэниел Мак, Том Гундерсен, Дэвид Херрманн) 345 разных авторов в 2018 году и всего 1317 разных авторов
Первый выпуск 30 марта 2010 г. ; 11 лет назад ( 2010-03-30)
Стабильный выпуск 249 (7 июля 2021 г. ; 3 месяца назад) [±]  ( 2021-07-07)
Репозиторий
Написано в C
Операционная система Linux
Тип Системное программное обеспечение Руководитель процесса
Лицензия LGPLv2.1 +
Веб-сайт systemd.io

systemd - это программный пакет, который предоставляет набор системных компонентов для операционных систем Linux. Его основная цель - унифицировать конфигурацию и поведение служб в разных дистрибутивах Linux ; Основным компонентом systemd является «менеджер системы и служб» - система инициализации, используемая для начальной загрузки пользовательского пространства и управления пользовательскими процессами. Он также обеспечивает замену различных демонов и утилит, включая управление устройствами, управление входом в систему, управление сетевым подключением и ведение журнала событий. Имя systemd соответствует соглашению Unix об именовании демонов, добавляя букву d. Он также использует термин « Система D », который относится к способности человека быстро адаптироваться и импровизировать для решения проблем.

С 2015 года большинство дистрибутивов Linux приняли systemd, заменив другие системы, такие как UNIX System V и системы инициализации BSD. Systemd столкнулся с неоднозначным приемом со стороны пользователей Linux, с аргументами о том, что systemd страдает от расплывчатости и раздувания миссии, а также с критикой программного обеспечения (такого как рабочий стол GNOME ), добавляющего зависимости от systemd, что усложняет совместимость с другими Unix-подобными операционными системами и делает трудно отойти от systemd. Также высказывались опасения по поводу того, что Red Hat и ее материнская компания IBM контролируют сцену систем инициализации в Linux. Что еще более важно, сложность systemd приводит к значительному увеличению поверхности атаки, что снижает общую безопасность платформы.

СОДЕРЖАНИЕ

  • 1 История
  • 2 Дизайн
    • 2.1 Основные компоненты и библиотеки
    • 2.2 Вспомогательные компоненты
    • 2.3 Конфигурация systemd
      • 2.3.1 Иерархия файлов конфигурации
  • 3 Принятие
    • 3.1 Интеграция с другим ПО
  • 4 Прием
  • 5 Форки и альтернативные реализации
    • 5.1 Вилка компонентов
      • 5.1.1 eudev
      • 5.1.2 elogind
      • 5.1.3 consolekit2
      • 5.1.4 LoginKit
      • 5.1.5 systembsd
      • 5.1.6 notsystemd
    • 5.2 Форк, включая систему инициализации
      • 5.2.1 бесполезно
      • 5.2.2 s6
      • 5.2.3 InitWare
  • 6 См. Также
  • 7 Примечания
  • 8 ссылки
  • 9 Внешние ссылки

История

Поттеринг и Кей Сиверс, что разработчики программного обеспечения, работающие на Red Hat, которые изначально разработанные Systemd, начали проект для разработки Systemd в 2010 году они стремились превзойти эффективность инициализации демона несколько способов. Они хотели улучшить структуру программного обеспечения для выражения зависимостей, чтобы больше обработки должна быть сделана одновременно или параллельно во время системной загрузки и уменьшить вычислительную нагрузку от оболочки.

В мае 2011 года Fedora стала первым крупным дистрибутивом Linux, в котором по умолчанию включен systemd. В период с октября 2013 г. по февраль 2014 г. в списке рассылки Debian прошли длительные дебаты между Техническим комитетом Debian, в ходе которых обсуждалась система инициализации, которую следует использовать по умолчанию в Debian 8 «jessie», и завершились решением в пользу systemd. Дебаты получили широкую огласку, и после принятия решения они продолжаются в списке рассылки Debian. В феврале 2014 года, после принятия решения Debian, Марк Шаттлворт объявил в своем блоге, что Ubuntu последует за внедрением systemd.

В ноябре 2014 года разработчик Debian Джои Хесс, члены Технического комитета Debian Расс Олбери и Ян Джексон, а также сопровождающий пакетов systemd Толлеф Фог Хин покинули свои должности. Все четверо обосновали свое решение в общедоступном списке рассылки Debian и в личных блогах тем, что подвергались чрезвычайному стрессу, связанному с продолжающимися спорами об интеграции systemd в сообществе Debian и FOSS, что делало регулярное обслуживание практически невозможным.

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

В сентябре 2016 года была обнаружена ошибка безопасности, которая позволяла любому непривилегированному пользователю выполнить атаку отказа в обслуживании против systemd. Рич Фелкер, разработчик musl, заявил, что эта ошибка выявляет серьезный «недостаток проектирования системы». В 2017 году в systemd была обнаружена еще одна ошибка безопасности, CVE - 2017-9445, которая «допускает прерывание обслуживания» «вредоносным DNS-сервером». Позже в 2017 году Pwnie Awards присудила автору Леннарту Поеттерингу награду « самый неудачный ответ поставщика» за то, что он справился с уязвимостями.

Дизайн

Архитектура systemd в том виде, в котором она используется Tizen. Несколько Systemd целей, в том числе telephony, bootmode, dlog, и tizen serviceвзяты из Tizen и не являются компонентами Systemd. Унифицированная-иерархические контрольные группы будут доступны исключительно Systemd сквознымsystemd-nspawn

Поэттеринг описывает разработку systemd как «никогда не завершенную, никогда не завершенную, но отслеживающую прогресс технологий». В мае 2014 года Поеттеринг далее описал systemd как объединяющий «бессмысленные различия между дистрибутивами», предоставляя следующие три общие функции:

  • Системный и сервисный менеджер (управляет как системой, применяя различные конфигурации, так и ее сервисами)
  • Программная платформа (служит в качестве основы для разработки другого программного обеспечения)
  • Связующее звено между приложениями и ядром (предоставляет различные интерфейсы, которые раскрывают функции, предоставляемые ядром)

Systemd включает в себя такие функции, как запуск демонов по требованию, поддержку моментальных снимков, отслеживание процессов и блокировки-ингибиторы. Это не только имя демона инициализации, но также относится ко всему пакету программного обеспечения вокруг него, который, помимо демона инициализации systemd, включает демоны journald, logind и networkd, а также многие другие низкоуровневые компоненты. В январе 2013 года Поеттеринг описал systemd не как одну программу, а как большой программный пакет, включающий 69 отдельных двоичных файлов. В качестве интегрированного программного пакета systemd заменяет последовательности запуска и уровни запуска, контролируемые традиционным демоном инициализации, вместе со сценариями оболочки, выполняемыми под его управлением. systemd также объединяет многие другие службы, которые являются общими для систем Linux, обрабатывая логины пользователей, системную консоль, горячее подключение устройств (см. udev ), выполнение по расписанию (заменяющее cron ), ведение журнала, имена хостов и локали.

Как и демон init, systemd - это демон, который управляет другими демонами, которые, включая сам systemd, являются фоновыми процессами. systemd - это первый демон, который запускается во время загрузки, и последний демон, который завершает свою работу во время завершения работы. Systemd демон служит корень пользовательского пространства в дереве процессов ; первый процесс ( PID 1) играет особую роль в системах Unix, поскольку он заменяет родительский процесс, когда исходный родительский процесс завершается. Следовательно, первый процесс особенно хорошо подходит для мониторинга демонов.

systemd выполняет элементы своей последовательности запуска параллельно, что теоретически быстрее, чем традиционный подход к последовательности запуска. Для межпроцессного взаимодействия (IPC) systemd делает сокеты домена Unix и D-Bus доступными для работающих демонов. Состояние самого systemd также может быть сохранено в моментальном снимке для использования в будущем.

Основные компоненты и библиотеки

Следуя своему интегрированному подходу, systemd также предоставляет замену для различных демонов и утилит, включая сценарии оболочки запуска, pm-utils, inetd, acpid, syslog, watchdog, cron и atd. Основные компоненты systemd включают следующее:

  • systemd - это системный и сервисный менеджер для операционных систем Linux.
  • systemctl - это команда для самоанализа и контроля состояния системы systemd и диспетчера служб. Не путать с sysctl.
  • systemd-analysis может использоваться для определения статистики производительности загрузки системы и получения другой информации о состоянии и трассировке из системы и диспетчера служб.

systemd отслеживает процессы, используя подсистему cgroups ядра Linux вместо использования идентификаторов процессов (PID); таким образом, демоны не могут «сбежать» из systemd даже путем двойного ветвления. Systemd не только использует контрольные группы, но и увеличивает их Systemd-nspawn и machinectl, два вспомогательных программ, которые облегчают создание и управление контейнерами Linux. Начиная с версии 205, systemd также предлагает ControlGroupInterface, который представляет собой API для контрольных групп ядра Linux. Контрольные группы ядра Linux адаптированы для поддержки kernfs и модифицируются для поддержки единой иерархии.

Вспомогательные компоненты

Помимо своей основной цели предоставления системы инициализации Linux, пакет systemd может предоставлять дополнительные функции, включая следующие компоненты:

Скриншот systemd-boot Скриншот timedatectl
журнал
systemd-journald - это демон, отвечающий за регистрацию событий, с двоичными файлами, предназначенными только для добавления, которые служат его файлами журнала. Системный администратор может выбрать, будет ли регистрироваться системные события с Systemd-journald, Syslog-нг или Rsyslog. Возможность повреждения двоичного формата вызвала жаркие споры.
либудев
libudev - это стандартная библиотека для использования udev, которая позволяет сторонним приложениям запрашивать ресурсы udev.
местный
logind
systemd-logind - это демон, который различными способами управляет логинами и рабочими местами пользователей. Это интегрированный менеджер входа в систему, который предлагает улучшения для работы с несколькими сеансами и заменяет ConsoleKit, который больше не поддерживается. Для диспетчеров дисплеев X11 переключение на logind требует минимального портирования. Он был интегрирован в systemd версии 30.
сеть
networkd - это демон для обработки конфигурации сетевых интерфейсов; в версии 209, когда он был впервые интегрирован, поддержка была ограничена статически назначенными адресами и базовой поддержкой конфигурации моста. В июле 2014 года была выпущена systemd версии 215, в которой были добавлены новые функции, такие как DHCP- сервер для хостов IPv4 и поддержка VXLAN. networkctlможет использоваться для просмотра состояния сетевых ссылок с точки зрения systemd-networkd. Конфигурация новых интерфейсов должна быть добавлена ​​в / lib / systemd / network / в виде нового файла с расширением.network.
решено
systemd-boot
systemd-boot - это менеджер загрузки, ранее известный как gummiboot. Кей Сиверс объединил его в systemd с версией 220.
приуроченный
systemd-timedated - это демон, который можно использовать для управления настройками времени, такими как системное время, системный часовой пояс или выбор между UTC и системными часами местного часового пояса. Это доступно через D-Bus. Он был интегрирован в systemd версии 30.
timesyncd
tmpfiles
systemd-tmpfiles - это утилита, которая заботится о создании и очистке временных файлов и каталогов. Обычно он запускается один раз при запуске, а затем через определенные промежутки времени.
udevd
udev - это диспетчер устройств для ядра Linux, который обрабатывает каталог / dev и все действия в пользовательском пространстве при добавлении / удалении устройств, включая загрузку прошивки. В апреле 2012 года дерево исходных кодов для udev было объединено с деревом исходных текстов systemd.
29 мая 2014 года поддержка загрузки прошивки через udev была прекращена из systemd, так как было решено, что ядро ​​должно отвечать за загрузку прошивки.

Конфигурация systemd

systemd-manager, инструмент для настройки systemd

Systemd настроен исключительно через равнину - текстовые файлы.

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

Типы модульных файлов включают:

  • .услуга
  • .разъем
  • .device (автоматически инициируется systemd)
  • .устанавливать
  • .automount
  • .поменять местами
  • .цель
  • .дорожка
  • .timer (который может быть использован в качестве хрон -like планировщика заданий )
  • .snapshot
  • .slice (используется для группировки и управления процессами и ресурсами)
  • .scope (используется для группировки рабочих процессов, не предназначен для настройки через файлы модулей)

Иерархия файлов конфигурации

man systemd.unit объясняет иерархию файлов конфигурации. Их пути определяются во время компиляции. По умолчанию (пример не полный):

UNIT LOAD PATH Unit files are loaded from a set of paths determined during compilation, described in the two tables below. Unit files found in directories listed earlier override files with the same name in directories lower in the list. Table 1. Load path when running in system mode (--system). ┌────────────────────────┬─────────────────────────────┐ │Path     │ Description     │ ├────────────────────────┼─────────────────────────────┤ │/etc/systemd/system  │ Local configuration   │ ├────────────────────────┼─────────────────────────────┤ │/run/systemd/system  │ Runtime units    │ ├────────────────────────┼─────────────────────────────┤ │/usr/lib/systemd/system │ Units of installed packages │ └────────────────────────┴─────────────────────────────┘

Принятие

Дистрибутив Linux Дата добавления в репозиторий программного обеспечения Включено по умолчанию? Дата выпуска по умолчанию Работает без?
Alpine Linux N / A (нет в репозитории) Нет N / A да
Android N / A (нет в репозитории) Нет N / A да
Arch Linux Январь 2012 г. да Октябрь 2012 г. Нет
antiX Linux N / A (нет в репозитории) Нет N / A да
Artix Linux N / A (нет в репозитории) Нет N / A да
CentOS Июль 2014 г. да Июль 2014 г. (v7.0) Нет
CoreOS Июль 2013 да Октябрь 2013 г. (v94.0.0) Нет
Debian Апрель 2012 г. да Апрель 2015 г. (v8.0) да
Девуан N / A (нет в репозитории) Нет N / A да
Fedora Ноябрь 2010 г. (v14) да Май 2011 (v15) Нет
Gentoo Linux Июль 2011 г. Нет N / A да
Knoppix N / A Нет N / A да
Linux Mint Июнь 2016 г. (v18.0) да N / A да
Mageia Январь 2011 г. (v1.0) да Май 2012 г. (v2.0) Нет
Manjaro Linux Ноябрь 2013 да Ноябрь 2013 Нет
openSUSE Март 2011 г. (v11.4) да Сентябрь 2012 г. (v12.2) Нет
Парабола GNU / Linux-libre Январь 2012 г. По желанию N / A да
Red Hat Enterprise Linux Июнь 2014 г. (v7.0) да Июнь 2014 г. (v7.0) Нет
Slackware N / A (нет в репозитории) Нет N / A да
Solus N / A да N / A Нет
Источник Маг Июнь 2011 г. Нет N / A да
SUSE Linux Enterprise Server Октябрь 2014 г. (v12) да Октябрь 2014 г. (v12) Нет
Ubuntu Апрель 2013 г. (v13.04) да Апрель 2015 г. (v15.04) Опция выскочки удалена в Якеттах (16.10)
Пустота Linux Июнь 2011 г., удален июнь 2015 г. Нет N / A да

Хотя многие дистрибутивы загружают systemd по умолчанию, некоторые позволяют использовать другие системы инициализации; в этом случае переключение системы инициализации возможно путем установки соответствующих пакетов. Вилки из Debian называется Devuan был разработан, чтобы избежать Systemd и достиг версии 3.1 для стабильного использования. В декабре 2019 года проект Debian проголосовал за сохранение systemd в качестве системы инициализации по умолчанию для дистрибутива, но с поддержкой «изучения альтернатив».

Интеграция с другим ПО

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

В ноябре 2012 года проект GNOME пришел к выводу, что базовая функциональность GNOME не должна зависеть от systemd. Однако GNOME 3.8 представил выбор во время компиляции между logind и ConsoleKit API, первый в то время предоставлялся только systemd. Ubuntu предоставил отдельный двоичный файл logind, но systemd стал де-факто зависимостью от GNOME для большинства дистрибутивов Linux, в частности, потому что ConsoleKit больше не поддерживается активно, а апстрим рекомендует вместо этого использовать systemd-logind. Разработчики Gentoo Linux также пытались адаптировать эти изменения в OpenRC, но реализация содержала слишком много ошибок, из-за чего дистрибутив отмечал systemd как зависимость от GNOME.

GNOME дополнительно интегрировал logind. Начиная с Mutter версии 3.13.2, logind является зависимостью для сессий Wayland.

Прием

Дизайн systemd вызвал споры в сообществе свободного программного обеспечения. Критики считают systemd чрезмерно сложной и страдающей от постоянного расползания функций, утверждая, что ее архитектура нарушает философию Unix. Также есть опасения, что он формирует систему взаимосвязанных зависимостей, тем самым предоставляя разработчикам дистрибутива небольшой выбор, кроме как принять systemd, поскольку все больше программного обеспечения в пользовательском пространстве становится зависимым от его компонентов, что похоже на проблемы, созданные PulseAudio, другим проектом, который был также разработан Леннартом Поеттерингом.

В интервью 2012 года руководитель Slackware Патрик Фолькердинг выразил сомнения по поводу архитектуры systemd, заявив, что его конструкция противоречит философии Unix взаимосвязанных утилит с узко определенными функциями. По состоянию на август 2018 года Slackware не поддерживает и не использует systemd, но Фолькердинг не исключил возможность перехода на него.

В январе 2013 года Леннарт Поеттеринг попытался снять озабоченность по поводу systemd в своем блоге под названием « Самые большие мифы».

В феврале 2014 года Рич Фелкер из musl высказал мнение, что PID 1 слишком особенный, чтобы на него возлагались дополнительные обязанности. PID 1 должен отвечать только за запуск остальной части системы инициализации и получение зомби-процессов. Дополнительные функции, добавленные systemd, могут быть предоставлены в другом месте и без необходимости увеличивают сложность и поверхность атаки PID 1.

В марте 2014 года Эрик С. Реймонд высказал мнение, что цели проектирования systemd были подвержены замедлению миссии и раздуванию программного обеспечения. В апреле 2014 года Линус Торвальдс выразил сомнения по поводу отношения Кея Сиверса, ключевого разработчика systemd, к пользователям и сообщениям об ошибках в отношении модификаций ядра Linux, представленных Сиверсом. В конце апреля 2014 года была запущена кампания бойкота systemd, на сайте которой были перечислены различные причины против ее принятия.

В августовской статье 2014 года, опубликованной в InfoWorld, Пол Венеция написал о споре относительно systemd и приписал споры нарушению философии Unix и «огромному эго, твердо убежденному в том, что они не могут сделать ничего плохого». В статье также описывается архитектура systemd как аналогичная svchost.exe, критически важному системному компоненту Microsoft Windows с широкими функциональными возможностями.

В интервью ZDNet в сентябре 2014 года известный разработчик ядра Linux Теодор Ц'о выразил мнение, что спор о философии централизованного проектирования systemd, а не технические проблемы, указывает на опасную общую тенденцию к унификации экосистемы Linux, отчуждению и маргинализации частей открытого -source сообщества, оставляя мало места для альтернативных проектов. Он привел сходство с отношением, которое он обнаружил в проекте GNOME к нестандартным конфигурациям. В социальных сетях Ц'о также позже сравнил отношение Сиверса и его соавтора, Леннарта Поеттеринга, с отношением разработчиков GNOME.

Вилки и альтернативные реализации

Форки systemd тесно связаны с критическими отзывами о нем, изложенными в предыдущем разделе. Форки обычно пытаются улучшить по крайней мере одно из следующих аспектов: переносимость (на другие библиотеки libcs ​​и Unix-подобные системы), модульность или размер. Несколько форков сотрудничали под баннером FreeInit.

Вилка компонентов

Евдев

В 2012 году проект Gentoo Linux создал форк udev, чтобы избежать зависимости от архитектуры systemd. Результирующий форк называется eudev, и он делает функциональность udev доступной без systemd. Заявленная цель проекта - сделать eudev независимым от любого дистрибутива Linux или системы инициализации.

elogind

Elogind - это "logind" проекта systemd, извлеченный как автономный демон. Он интегрируется с PAM, чтобы знать набор пользователей, которые вошли в систему, и независимо от того, вошли ли они в систему графически, на консоли или удаленно. Elogind предоставляет эту информацию через стандартный интерфейс D-Bus org.freedesktop.login1, а также через файловую систему с использованием стандартной компоновки systemd / run / systemd. Elogind также предоставляет "libelogind", который является подмножеством возможностей, предлагаемых "libsystemd". Также существует файл pkg-config "libelogind.pc".

consolekit2

ConsoleKit был разветвлен в октябре 2014 года разработчиками Xfce, которые хотели, чтобы его функции по-прежнему поддерживались и были доступны в операционных системах, отличных от Linux. Не исключая возможности возрождения исходного репозитория в долгосрочной перспективе, главный разработчик считает ConsoleKit2 временной необходимостью до тех пор, пока systembsd не станет зрелым. Разработка прекратилась в декабре 2017 года, и проект может прекратить свое существование.

LoginKit

LoginKit была попытка реализовать logind (Systemd-logind) прокладку, которая позволила бы пакеты, которые зависят от Systemd-logind работать без зависимости от системы конкретных инициализации. Проект не существует с февраля 2015 года.

systembsd

В 2014 году был запущен проект Google Summer of Code под названием «systembsd», чтобы предоставить альтернативные реализации этих API для OpenBSD. Первоначальный разработчик проекта начал это, чтобы облегчить свой переход с Linux на OpenBSD. Разработка проекта остановлена ​​в июле 2016 года.

Проект systembsd не обеспечивают замену инициализации, но направлен на обеспечение OpenBSD с совместимыми демонами для hostnamed, timedated, localed и logind. Проект не создавал новых функций, подобных systemd, и должен был действовать только как оболочка над собственной системой OpenBSD. Разработчик стремился установить systembsd как часть коллекции портов, а не как часть базовой системы, заявив, что «systemd и * BSD фундаментально различаются с точки зрения философии и практики разработки».

notsystemd

Notsystemd намеревается реализовать все функции systemd, работающие в любой системе инициализации. Он был разветвлен разработчиками Parabola GNU / Linux-libre для сборки пакетов с их инструментами разработки без необходимости установки systemd для запуска systemd-nspawn.

Вилка, включая систему инициализации

бесполезный

В 2014 году uselessd был создан как облегченный форк systemd. Проект стремился удалить функции и программы, которые считались ненужными для системы инициализации, а также устранить другие предполагаемые ошибки. Разработка проекта остановлена ​​в январе 2015 года.

uselessd поддерживает библиотеки musl и µClibc, поэтому его можно было использовать во встроенных системах, тогда как systemd поддерживает только glibc. Бесполезный проект планировал дальнейшие улучшения кросс-платформенной совместимости, а также архитектурные перестройки и рефакторинг для сборки Linux в будущем.

s6

s6 - это небольшой набор программ для UNIX, предназначенный для обеспечения наблюдения за процессами (он же надзор за службами) в линейке daemontools и runit, а также для различных операций над процессами и демонами. Он задуман как набор инструментов для низкоуровневого администрирования процессов и сервисов, предоставляющий различные наборы независимых инструментов, которые можно использовать как внутри, так и вне фреймворка, и которые могут быть собраны вместе для достижения мощной функциональности с очень небольшим объемом кода.

InitWare

InitWare - это модульный рефакторинг systemd, переносящий систему на платформы BSD без системных вызовов glibc или Linux. Известно, что он работает на DragonFly BSD, FreeBSD, NetBSD и GNU / Linux. Компоненты, которые считаются ненужными, отбрасываются.

Смотрите также

Примечания

использованная литература

внешние ссылки

Последняя правка сделана 2023-04-13 03:50:37
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте