Каковы преимущества /недостатки Upstart и systemd?

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

162 голоса | спросил Tshepang 14 Jpm1000000pmFri, 14 Jan 2011 23:00:47 +030011 2011, 23:00:47

6 ответов


71

Обновление 2016

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

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

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

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

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

Ниже приведено краткое сравнение общих команд и простых скриптов, см. разделы ниже для подробного объяснения. Этот ответ сравнивает старое поведение систем на основе 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

Сценарии

Пример сценария upstart , написанного в /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 в запросе pull # 1022:

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

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

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

machinectl shell

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

  

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

См. также:

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

Команды вроде:

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

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

  

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

Подробнее см .:

Концепция запуска на высоком уровне

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

Вот как Systemd для пользователей Upstart объясняет это:

  

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

     Модель

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

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

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

Распределения с использованием выскочки по умолчанию:

Распределения с использованием systemd по умолчанию:

(см. Wikipedia для актуальной информации)

Распределения, не использующие ни Upstart, ни systemd:

Полемика

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

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

  

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

     

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

     

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

  

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

     

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

  

Девуан родился из разногласий по поводу решения использовать в качестве   default init для Debian. официальная позиция Debian на   systemd полон заявлений о том, что другие развенчали . заинтересованный   читатели могут продолжить обсуждение этой горячей темы в Системаdd   Противоречие . Однако мы призываем вас держать голову крутой и   голос гражданский. В Devuan мы больше заинтересованы в том, чтобы программировать их неправильно   чем оглядываться назад. [...]

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

В Hacker News есть интересное обсуждение много :

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

Философия

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

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

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

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

Цели системы:

  

Наши цели

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

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

  •   
  • Сокращение сложности администратора, надежность без надзора
  •   
  • Все интроспективно
  •   
  • Автоматическое обнаружение, подключение и воспроизведение - это ключ.
  •   
  • Мы фиксируем вещи, где они сломаны, никогда не накладывайтесь на них.
  •   

Области, уже покрытые:

  

Что мы уже рассказываем:

     

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

Незавершенное производство:

  

О чем мы работаем:

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

Объем этого ответа

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

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

Подробнее

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

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

Команда LinOxide создала Systemd vs SysV Init Linux Cheatsheet .

ответил rsp 2 J0000006Europe/Moscow 2016, 21:13:06
67

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

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

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

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

ответил jsbillings 20 Jpm1000000pmThu, 20 Jan 2011 19:16:04 +030011 2011, 19:16:04
28

Пила 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 является то, что некоторые демоны должны быть изменены, чтобы в полной мере использовать его. Они будут работать сейчас, но они будут работать лучше, если бы они были написаны специально для своей модели сокетов.

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

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

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

ответил xenoterracide 20 Jpm1000000pmThu, 20 Jan 2011 18:56:13 +030011 2011, 18:56:13
11

Хорошо, что большинство из вас забыло, это организация процессов в группах .

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

  • Администратор большой системы со многими пользователями имеет эффективные новые способы выявления вредоносных пользователей /процессов.
  • Приоритеты для планирования CPU могут быть определены лучше, как это сделано " Wonder autocgroup patch ".
ответил 22 Jpm1000000pmSat, 22 Jan 2011 15:10:36 +030011 2011, 15:10:36
8

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

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

ответил vonbrand 28 Jam1000000amMon, 28 Jan 2013 02:37:21 +040013 2013, 02:37:21
3

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

ответил Bert 6 Mayam16 2016, 07:46:33

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132