запуск 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 приводит к значительному увеличению поверхности атаки, что снижает общую безопасность платформы.
Поттеринг и Кей Сиверс, что разработчики программного обеспечения, работающие на 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 присудила автору Леннарту Поеттерингу награду « самый неудачный ответ поставщика» за то, что он справился с уязвимостями.
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 отслеживает процессы, используя подсистему cgroups ядра Linux вместо использования идентификаторов процессов (PID); таким образом, демоны не могут «сбежать» из systemd даже путем двойного ветвления. Systemd не только использует контрольные группы, но и увеличивает их Systemd-nspawn и machinectl, два вспомогательных программ, которые облегчают создание и управление контейнерами Linux. Начиная с версии 205, systemd также предлагает ControlGroupInterface, который представляет собой API для контрольных групп ядра Linux. Контрольные группы ядра Linux адаптированы для поддержки kernfs и модифицируются для поддержки единой иерархии.
Помимо своей основной цели предоставления системы инициализации Linux, пакет systemd может предоставлять дополнительные функции, включая следующие компоненты:
Скриншот systemd-boot Скриншот timedatectlnetworkctl
может использоваться для просмотра состояния сетевых ссылок с точки зрения systemd-networkd. Конфигурация новых интерфейсов должна быть добавлена в / lib / systemd / network / в виде нового файла с расширением.network.Systemd настроен исключительно через равнину - текстовые файлы.
systemd записывает инструкции по инициализации для каждого демона в файл конфигурации (называемый «модульным файлом»), который использует декларативный язык, заменяя традиционно используемые сценарии оболочки запуска для каждого демона. Синтаксис языка основан на .ini
файлах.
Типы модульных файлов включают:
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 - это "logind" проекта systemd, извлеченный как автономный демон. Он интегрируется с PAM, чтобы знать набор пользователей, которые вошли в систему, и независимо от того, вошли ли они в систему графически, на консоли или удаленно. Elogind предоставляет эту информацию через стандартный интерфейс D-Bus org.freedesktop.login1, а также через файловую систему с использованием стандартной компоновки systemd / run / systemd. Elogind также предоставляет "libelogind", который является подмножеством возможностей, предлагаемых "libsystemd". Также существует файл pkg-config "libelogind.pc".
ConsoleKit был разветвлен в октябре 2014 года разработчиками Xfce, которые хотели, чтобы его функции по-прежнему поддерживались и были доступны в операционных системах, отличных от Linux. Не исключая возможности возрождения исходного репозитория в долгосрочной перспективе, главный разработчик считает ConsoleKit2 временной необходимостью до тех пор, пока systembsd не станет зрелым. Разработка прекратилась в декабре 2017 года, и проект может прекратить свое существование.
LoginKit была попытка реализовать logind (Systemd-logind) прокладку, которая позволила бы пакеты, которые зависят от Systemd-logind работать без зависимости от системы конкретных инициализации. Проект не существует с февраля 2015 года.
В 2014 году был запущен проект Google Summer of Code под названием «systembsd», чтобы предоставить альтернативные реализации этих API для OpenBSD. Первоначальный разработчик проекта начал это, чтобы облегчить свой переход с Linux на OpenBSD. Разработка проекта остановлена в июле 2016 года.
Проект systembsd не обеспечивают замену инициализации, но направлен на обеспечение OpenBSD с совместимыми демонами для hostnamed, timedated, localed и logind. Проект не создавал новых функций, подобных systemd, и должен был действовать только как оболочка над собственной системой OpenBSD. Разработчик стремился установить systembsd как часть коллекции портов, а не как часть базовой системы, заявив, что «systemd и * BSD фундаментально различаются с точки зрения философии и практики разработки».
Notsystemd намеревается реализовать все функции systemd, работающие в любой системе инициализации. Он был разветвлен разработчиками Parabola GNU / Linux-libre для сборки пакетов с их инструментами разработки без необходимости установки systemd для запуска systemd-nspawn.
В 2014 году uselessd был создан как облегченный форк systemd. Проект стремился удалить функции и программы, которые считались ненужными для системы инициализации, а также устранить другие предполагаемые ошибки. Разработка проекта остановлена в январе 2015 года.
uselessd поддерживает библиотеки musl и µClibc, поэтому его можно было использовать во встроенных системах, тогда как systemd поддерживает только glibc. Бесполезный проект планировал дальнейшие улучшения кросс-платформенной совместимости, а также архитектурные перестройки и рефакторинг для сборки Linux в будущем.
s6 - это небольшой набор программ для UNIX, предназначенный для обеспечения наблюдения за процессами (он же надзор за службами) в линейке daemontools и runit, а также для различных операций над процессами и демонами. Он задуман как набор инструментов для низкоуровневого администрирования процессов и сервисов, предоставляющий различные наборы независимых инструментов, которые можно использовать как внутри, так и вне фреймворка, и которые могут быть собраны вместе для достижения мощной функциональности с очень небольшим объемом кода.
InitWare - это модульный рефакторинг systemd, переносящий систему на платформы BSD без системных вызовов glibc или Linux. Известно, что он работает на DragonFly BSD, FreeBSD, NetBSD и GNU / Linux. Компоненты, которые считаются ненужными, отбрасываются.