it-swarm-ru.tech

Каковы плюсы / минусы Upstart и systemd?

Похоже, systemd это горячая новая init система в блоке, такая же, как pstart несколько лет назад. Каковы плюсы/минусы для каждого? Кроме того, как каждая из них сравнивается с другими системами инициализации?

187
tshepang

Обновление 2016

Большинство ответов здесь пять лет, поэтому пришло время для некоторых обновлений.

Ubuntu по умолчанию использовал upstart, но отказался от него в прошлом году в пользу systemd - смотрите:

Из-за этого есть хорошая статья Systemd для пользователей Upstart на вики Ubuntu - очень подробное сравнение между upstart и systemd и руководство по переходу от upstart к systemd.

(Обратите внимание, что согласно вики Ubunt вы по-прежнему можете запускать upstart в текущих версиях Ubuntu по умолчанию, установив upstart-sysv и ​​работает Sudo update-initramfs -u но, учитывая масштабы проекта systemd, я не знаю, как он работает на практике, или можно ли удалить systemd.)

Большая часть информации в разделах "Команды и сценарии", приведенная ниже, адаптирована из некоторых примеров, использованных в этой статье (она удобно лицензируется, как и вклады пользователей Stack Exchange в рамках лицензии Creative Commons Attribution-ShareAlike 3. ) ,.

Вот быстрое сравнение общих команд и простых скриптов, подробное объяснение смотрите в разделах ниже. Этот ответ сравнивает старое поведение систем на основе Upstart с новым поведением систем на основе systemd, как было задано в вопросе, но обратите внимание, что команды, помеченные как "Upstart", не обязательно зависят от Upstart - они часто являются командами, которые являются общими для любой не системной системы Linux и Unix.

Команды

Запуск su:

  • выскочка: su
  • systemd: machinectl Shell

(см. раздел "Замена команды su" ниже)

Рабочий экран:

  • выскочка: screen
  • systemd: systemd-run --user --scope screen

(см. раздел "Неожиданное уничтожение фоновых процессов" ниже)

Запуск tmux:

  • выскочка: tmux
  • systemd: systemd-run --user --scope tmux

(см. раздел "Неожиданное уничтожение фоновых процессов" ниже)

Начало работы foo:

  • выскочка: start foo
  • systemd: systemctl start foo

Остановка работы foo:

  • выскочка: stop foo
  • systemd: systemctl stop foo

Возобновление работы foo:

  • выскочка: restart foo
  • systemd: systemctl restart foo

Список рабочих мест:

  • выскочка: initctl list
  • systemd: systemctl status

Проверка конфигурации задания foo:

  • выскочка: init-checkconf /etc/init/foo.conf
  • systemd: systemd-analyze verify /lib/systemd/system/foo.service

Перечисление переменных окружения задания:

  • выскочка: initctl list-env
  • systemd: systemctl show-environment

Установка переменной среды задания:

  • выскочка: initctl set-env foo=bar
  • systemd: systemctl set-environment foo=bar

Удаление переменной среды задания:

  • выскочка: initctl unset-env foo
  • systemd: systemctl unset-environment foo

Бревна

В upstart журналы - это обычные текстовые файлы в каталоге/var/log/upstart, поэтому вы можете обрабатывать их как обычно:

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

В systemd журналы хранятся во внутреннем двоичном формате (не в виде текстовых файлов), поэтому вам нужно использовать команду journalctl для доступа к ним:

Sudo journalctl -u foo
Sudo journalctl -u foo -f

Сценарии

Пример сценария запуска , написанного на /etc/init/foo.conf:

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

Пример сценария systemd , написанный на /lib/systemd/system/foo.service:

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

замена команды su

Замена команды su была объединена с systemd в запросе # 1022:

потому что, согласно Леннарту Поеттерингу, "су действительно плохая концепция" .

Он объясняет, что "вы можете использовать su и Sudo, как и раньше, но не ожидайте, что он будет работать полностью " ,.

Официальный способ достижения su-подобного поведения теперь:

machinectl Shell

Это было далее объяснено Леннартом Поеттерингом в обсуждении вопроса № 825:

"Ну, были долгие дискуссии по этому поводу, но проблема в том, что то, что должен делать su, очень непонятно. [...] Короче говоря, su - действительно сломанная концепция. Это даст вам своего рода Shell , и это хорошо, чтобы использовать это для этого, но это не полный вход в систему, и не должен быть принят за один. " - Леннарт Поэттеринг

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

Неожиданное уничтожение фоновых процессов

Команды как:

больше не работает должным образом . Например, Nohup - это команда POSIX, чтобы убедиться, что процесс продолжает выполняться после выхода из сеанса. Это больше не работает на systemd. Также такие программы, как screen и ​​tmux, должны вызываться особым образом или иным образом процессы, которые вы запускаете с ними, будут убиты (при этом эти процессы не будут убиты обычно это главная причина запуска экрана или tmux в первую очередь).

Это не ошибка, это осознанное решение, поэтому вряд ли оно будет исправлено в будущем. Вот что Lennart Poettering сказал об этой проблеме:

На мой взгляд, в UNIX было довольно странно, что по умолчанию произвольный пользовательский код оставался неограниченным после выхода из системы. Многие люди, работающие с ОС, уже давно обсуждают, что это должно быть возможно, но, конечно, не по умолчанию, но никто так и не осмелился щелкнуть переключателем, чтобы превратить его из значения по умолчанию в опцию. Не очистка пользовательских сессий после выхода из системы - это не только уродливо и несколько хакерски, но и проблема безопасности. systemd 230 теперь, наконец, щелкнул выключателем и, наконец, по умолчанию все корректно очищает, когда пользователь выходит из системы.

Для получения дополнительной информации см .:

Концепция стартапа высокого уровня

Таким образом, systemd работает задом наперед - в upstart-заданиях запускаются как можно быстрее, а в systemd-заданиях запускаются тогда, когда это необходимо. В конце дня обе системы могут запускать одинаковые задания в одном и том же порядке, но вы думаете об этом, глядя, так сказать, с противоположной стороны.

Вот как Systemd для Upstart Users объясняет это:

Модель Upstart для запуска процессов (заданий) является "жадной, основанной на событиях", т.е. е. все доступные задания, чьи события запуска происходят, запускаются как можно раньше. Во время загрузки программа upstart синтезирует некоторые начальные события, такие как запуск или rcS, в качестве "корня дерева", ранние службы запускаются на них, а более поздние службы запускаются при запуске первых. Новая работа просто должна установить свой файл конфигурации в/etc/init /, чтобы стать активной.

Модель systemd для запуска процессов (единиц) является "ленивой зависимой", т.е. е. юнит стартует только тогда, когда от него зависит какой-то другой стартовый юнит Во время загрузки systemd запускает "корневой модуль" (default.target, может быть переопределен в grub), который затем транзитивно расширяется и запускает свои зависимости. Новый модуль должен добавить себя в качестве зависимости от модуля последовательности загрузки (обычно multi-user.target), чтобы стать активным.

Использование в дистрибутивах

Теперь некоторые последние данные по Википедии:

По умолчанию дистрибутивы используют upstart:

По умолчанию дистрибутивы используют systemd:

  • Arch Linux - с октября 2012 года
  • CentOS - с апреля 2014 г. (7.14.04)
  • CoreOS - октябрь 2013 г. (v94.0.0)
  • Debian - с апреля 2015 г. (версия 8)
  • Fedora - с мая 2011 г. (версия 15)
  • Mageia - с мая 2012 года (версия 2.0)
  • openSUSE - с сентября 2012 г. (версия 12.2)
  • Red Hat Enterprise Linux - с июня 2014 г. (версия 7.0)
  • SUSE Linux Enterprise Server - с октября 2014 г. (версия 12)
  • bunt - с апреля 2015 г. (версия 15.04)

(См. Википедия для получения актуальной информации)

Дистрибутивы, не использующие ни Upstart, ни systemd:

Полемика

В прошлом была предложена ветка Debian, чтобы избежать systemd . Devuan GNU + Linux - ветвь Debian без systemd (спасибо fpmurphy1 за указание на это в комментариях).

Для получения дополнительной информации об этом противоречии, см .:

Как многие из вас уже могут знать, голосование по Debian Init GR, проводимое Иэном Джексоном, было бесполезным для защиты наследия Debian и его пользователей от лавины systemd.

Такая ситуация может привести к блокировке системных зависимостей, которые де-факто угрожают свободе разработки и имеют серьезные последствия для Debian, его исходных и последующих версий.

CTTE удалось поменять зависимость и выиграть время на тонкую установку systemd поверх sysvinit, но даже этот процесс был утомительным и полным драмы. В итоге неделю назад Ян Джексон подал в отставку. [...]

Я ухожу из Технического комитета с немедленным вступлением в силу.

Хотя важно, чтобы мнения 30-40% участников проекта, которые согласны со мной, и впредь были представлены в ТС, я сам явно слишком противоречив в этом вопросе, чтобы делать это. Я должен отойти в сторону, чтобы попытаться уменьшить степень персонализации разговоров об управлении проектом. [...]

Devuan был рожден из-за спора по поводу решения использовать Debian как систему инициализации по умолчанию. официальная позиция Debian по systemd полна утверждений о том, что другие опровергли . Заинтересованные читатели могут продолжить обсуждение этой горячей темы в Противоречие systemd . Тем не менее, мы рекомендуем вам сохранять спокойствие и спокойный голос. В Devuan мы больше заинтересованы в том, чтобы программировать их неправильно, чем оглядываться назад. [...]

Некоторые веб-сайты и статьи, посвященные противоречиям в systemd, были созданы:

Существует много интересных дискуссий на Hacker News:

Аналогичные тенденции наблюдаются и в других дистрибутивах:

Философия

upstart следует философии Unix DOTADIW - "Делай одно и делай хорошо". Это замена традиционного демона init. Он не делает ничего, кроме запуска и остановки служб. Другие задачи делегируются другим специализированным подсистемам.

systemd делает гораздо больше. Помимо запуска и остановки сервисов, он также управляет паролями, логинами, терминалами, управлением питанием, сбросом настроек, обработкой журналов, точками монтирования файловой системы, сетями и многим другим - см. [~ # ~] новости [~ #] ~] файл для некоторых функций.

Планы расширения

Согласно Перспектива для systemd Что было достигнуто и что ждет впереди презентация Lennart Poettering в 2014 году на GNOME.asia, вот основные цели systemd, области, которые уже были рассмотрены, и те, которые были все еще в процессе:

системные задачи:

Наши цели

  • Превращение Linux из пакета с битами в конкурентоспособную операционную систему общего назначения.
  • Создание ОС нового поколения в Интернете. Объединение бессмысленных различий между дистрибутивами.
  • Вернуть инновации в основную ОС

  • Рабочий стол, Сервер, Контейнер, Встроенный, Мобильный, Облако, Кластер,. , , Эти области ближе друг к другу, чем вы думаете

  • Уменьшение сложности администратора, надежность без надзора
  • Все самоанализ
  • Автоматическое обнаружение, подключи и играй ключ
  • Мы исправляем вещи там, где они сломаны, никогда не обматывая их

Области уже охвачены:

Что мы уже охватываем:

система инициализации, ведение журнала, управление входом в систему, управление устройством, управление временными и нестабильными файлами, регистрация двоичного формата, сохранение/восстановление подсветки, сохранение/восстановление rfkill, загрузочная диаграмма, чтение с головы, настройка зашифрованного хранилища, обнаружение раздела EFI/GPT, виртуальная машина/контейнер регистрация, управление минимальными контейнерами, управление именами хостов, управление локалями, управление временем, управление случайным начальным числом, управление переменными sysctl, управление консолью,. , ,.

Работа в процессе:

Над чем мы работаем:

  • управление сетью
  • systemd-networkd
  • Локальный кэш DNS, ответчик mDNS, ответчик LLMNR, проверка DNSSEC
  • МПК в ядре
  • kdbus, sd-bus
  • Синхронизация времени с NTP
  • systemd-timesyncd
  • Больше интеграции с контейнерами
  • Песочница Сервисов
  • Песочница приложений
  • Формат образа ОС
  • Формат изображения контейнера
  • Формат изображения приложения
  • GPT с авто-обнаружением
  • Системы без состояний, инстанцируемые системы, сброс настроек
  • / usr это ОС
  • / etc - это (необязательно) конфигурация
  • / var это (необязательно) состояние
  • Инициализация и обновления атомарного узла
  • Интеграция с облаком
  • Управление услугами через узлы
  • Проверяемые образы ОС
  • Весь путь до прошивки
  • Загрузка загрузки

Сфера этого ответа

Как отмечено в комментариях fpmurphy1 : "Следует отметить, что systemd расширила сферу своей работы за годы, намного превосходящие просто запуск системы".

Я попытался включить большую часть соответствующей информации здесь. Здесь я сравниваю общие функции Upstart и systemd при использовании в качестве систем инициализации, как было задано в вопросе, и я упоминаю только те особенности systemd, которые выходят за рамки системы init, поскольку их нельзя сравнивать с Startup, но их наличие важно чтобы понять разницу между этими двумя проектами. Соответствующая документация должна быть проверена для получения дополнительной информации.

Больше информации

Более подробную информацию можно найти по адресу:

Дополнительно

Команда LinOxide создала Системный код против SysV Init Linux Chatsheet .

92
rsp

И upstart, и systemd являются попытками решить некоторые проблемы с ограничениями традиционной системы инициализации SysV. Например, некоторые службы должны запускаться после других служб (например, вы не можете монтировать файловые системы NFS, пока сеть не работает), но единственный способ в SysV - это установить ссылки в каталоге rc # .d. такой, что один перед другим. Добавьте к этому, вам может понадобиться изменить нумерацию позже, когда зависимости будут добавлены или изменены. Upstart и Systemd имеют более интеллектуальные настройки для определения требований. Кроме того, существует проблема с тем, что все является своего рода сценарием Shell, и не все пишут лучшие сценарии инициализации. Это также влияет на скорость запуска.

Некоторые из преимуществ systemd я вижу:

  • Каждый запущенный процесс получает свою собственную группу или определенную группу.
  • Предварительное создание сокетов и файловых дескрипторов для сервисов, аналогично тому, как xinetd делает для своих сервисов, позволяя зависимым сервисам запускаться быстрее. Например, systemd будет держать дескриптор файла для/dev/log для syslog, а последующим службам, которые отправляют в/dev/log, будут буферизироваться их сообщения, пока syslogd не будет готов вступить во владение.
  • Меньше процессов запускаются, чтобы фактически запустить сервис. Это означает, что вы не пишете сценарий оболочки для запуска службы. Это может быть улучшение скорости, и (IMO) что-то проще настроить в первую очередь.

Мне известен один недостаток, заключающийся в том, что для использования преимуществ предварительного выделения сокетов/FH в systemd нужно будет пропатчить многие демоны, чтобы SystemH передавал им FH.

68
jsbillings

Видел systemd, упомянутых в Arch General ML сегодня. Так что читайте об этом. The H Online как всегда, является отличным источником для технологии Linux и именно там я нашел свое место, чтобы начать исследования Systemd как SysV Init и альтернатива Upstart . Однако статья H Online (в данном случае) не очень полезна для чтения, реальная польза от нее в том, что она дает ссылки на полезные материалы.

Реальный ответ в объявление systemd . Что дает некоторые важные моменты о том, что не так с SysV initd, и что нужно делать новым системам

  • Чтобы начать меньше.
  • И начать больше параллельно.

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

Другая часть плана, по-видимому, заключается в том, чтобы не сериализовать файловые системы, а вместо этого монтировать их по требованию, чтобы вы не ждали своего /home/ и ​​т. д. (не путать с /etc) для монтирования и/или fsck, когда вы можете запускать демоны как / а также /var/ и ​​т. д. уже смонтированы. Он сказал, что собирается использовать autofs для этой цели.

У него также есть цель создания .desktop стиль дескрипторов инициализации в качестве замены для сценариев. Это предотвратит множество медленных sh процессов и даже больше разветвлений процессов от таких вещей, как sed и ​​grep, которые часто используются в сценариях оболочки.

Они также планируют не запускать некоторые службы до тех пор, пока их не попросят, и, возможно, даже отключить их, если они больше не нужны, например, модуль Bluetooth и демон нужны только при использовании устройства Bluetooth. Другой приведенный пример - демон ssh. Это то, на что способен inetd. Лично я не уверен, что мне это нравится, так как это может означать задержку, когда они мне нужны, и в случае с ssh я думаю, что это означает возможную уязвимость безопасности, если бы мой inetd был скомпрометирован, то была бы вся система. Однако мне сообщили, что использовать это для взлома этой системы невозможно, и если я захочу, я могу отключить эту функцию для каждой службы и другими способами.

Другой особенностью, очевидно, будет возможность запуска на основе временных событий, либо через регулярно запланированный интервал, либо в определенное время. Это похоже на то, что сейчас делают crond и ​​atd. Хотя мне сказали, что он не будет поддерживать пользователя "cron". Лично это звучит как самая бессмысленная вещь. Я думаю, что это было написано/придумано людьми, которые не работают в многопользовательских средах, для пользователя cron нет особой цели, если вы единственный пользователь в системе, кроме того, что он не работает от имени пользователя root. Я работаю на многопользовательских системах ежедневно, и правило всегда заключается в запуске пользовательских сценариев от имени пользователя. Но, возможно, у меня нет предвидения, которое у них есть, и оно никоим образом не сделает так, чтобы я не мог запустить crond или atd, так что это никому не повредит, кроме Разработчики я полагаю.

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

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

Или, проще говоря: тот факт, что пользователь только что запустил D-Bus, никоим образом не является признаком того, что NetworkManager тоже нужно запускать (но именно это сделает Upstart). С другой стороны, все верно: когда пользователь запрашивает NetworkManager, это определенно указывает на то, что D-Bus также должен быть запущен (что, безусловно, ожидают большинство пользователей, верно?).
Хорошая система инициализации должна запускать только то, что нужно, и то, что по требованию. Лениво или распараллелено и заранее. Однако он не должен запускаться больше, чем необходимо, особенно не все установлено, что может использовать эту службу.

Как я уже сказал, это более подробно обсуждается в объявление systemd .

29
xenoterracide

Одна вещь, которую большинство из вас забыло, это организация процессов в cgroups .

Таким образом, если systemd что-то запустил, он поместит эту вещь в свою собственную cgroup, и нет никакого (непривилегированного) средства для выхода процесса из этой cgroup. Вот последствия этого:

  • Администратор большой системы со многими пользователями имеет эффективные новые способы выявления вредоносных пользователей/процессов.
  • Приоритеты для планирования CPU могут быть определены лучше, как это делается с помощью "Wonder autocgroup patch" .
11
enaut

Чтобы очень подробно взглянуть на systemd, начиная с первых черновиков проекта (и детальной критики существующих систем инициализации, включая upstart, и того, как systemd предлагает их исправить), перейдите на ее домашняя страница . Со временем было опубликовано несколько статей об автозагрузке в LWN . Просто имейте в виду, что любое упоминание о systemd (или pulseaudio) вызывает бесконечные пламенные войны.

IMVHO (и как пользователь Fedora) Я очень доволен этим. Что-то в этой линии давно пора было справиться со сложностью современных систем Linux. Некоторое время Fedora использовала upstart, но она никогда не выходила за рамки того, чтобы быть изящной заменой sysvinit, в основном выполняя неизмененные сценарии инициализации. Его обещание упростить загрузочную конфигурацию происходит за счет повторной ручной настройки взаимозависимостей, и это просто не работает. systemd вычисляет зависимости самостоятельно (или просто позволяет запускать вещи без учета зависимостей, они сами разбираются). Другое большое преимущество (некоторые говорят, что это серьезный недостаток) заключается в том, что он использует специфичные для Linux функции для защиты (в частности, cgroups позволяет изолировать демона и всех его потомков, что позволяет легко отслеживать, ограничивать ресурсы или уничтожать их по мере необходимости). группа, есть много других).

8
vonbrand

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

3
Bert