Обновление 2016
Большинство ответов здесь пять лет, поэтому пришло время для некоторых обновлений.
Ubuntu по умолчанию использовал upstart, но отказался от него в прошлом году в пользу systemd - смотрите:
По этой причине в Wiki Ubuntu есть хорошая статья Systemd для пользователей Upstart - очень подробное сравнение между upstart и systemd и руководство по переходу от upstart к systemd.
(Обратите внимание, что согласно вики Ubuntu, вы по-прежнему можете запускать upstart в текущих версиях 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 в запросе тянуть # 1022:
потому что, по словам Леннарта Поеттеринга, «су - действительно сломанная концепция» .
Он объясняет, что «вы можете использовать su и sudo, как и раньше, но не ожидайте, что он будет работать в полном объеме » .
Официальный способ достижения suподобного поведения теперь:
machinectl shell
Это было
объяснено Леннартом Поеттерингом
в дискуссии по вопросу № 825:
«Ну, были долгие дискуссии по этому поводу, но проблема в том, что то, что должен делать su, очень непонятно. [...] Короче говоря, su - действительно сломанная концепция. Это даст вам вид оболочки , и это хорошо, чтобы использовать это для этого, но это не полный вход в систему, и не должен быть принят за один. " - Леннарт Поэттеринг
Смотрите также:
Неожиданное уничтожение фоновых процессов
Команды как:
больше не работает, как ожидалось . Например, nohupэто команда POSIX, чтобы убедиться, что процесс продолжает работать после выхода из сеанса. Это больше не работает на systemd. Также такие программы, как screenи tmuxдолжны вызываться особым образом, иначе процессы, которые вы запускаете с ними, будут убиты (в то время как не уничтожение этих процессов обычно является основной причиной запуска screen или tmux в первую очередь).
Это не ошибка, это осознанное решение, поэтому вряд ли оно будет исправлено в будущем. Вот что Леннарт Поеттеринг сказал по этому поводу:
На мой взгляд, в UNIX было довольно странно, что по умолчанию произвольный пользовательский код оставался неограниченным после выхода из системы. Многие люди, работающие с ОС, уже давно обсуждают, что это должно быть возможно, но, конечно, не по умолчанию, но никто так и не осмелился щелкнуть переключателем, чтобы превратить его из значения по умолчанию в опцию. Не очистка пользовательских сессий после выхода из системы - это не только уродливо и несколько хакерски, но и проблема безопасности. Теперь systemd 230 наконец-то щелкнул переключателем и, наконец, по умолчанию все корректно очищает, когда пользователь выходит из системы.
Для получения дополнительной информации см .:
Концепция стартапа высокого уровня
Таким образом, systemd работает задом наперед - в upstart-заданиях запускаются как можно быстрее, а в systemd-заданиях запускаются тогда, когда это необходимо. В конце дня обе системы могут запускать одинаковые задания в одном и том же порядке, но вы думаете об этом, глядя, так сказать, с противоположной стороны.
Вот как это объясняет Systemd для пользователей Upstart :
Модель Upstart для запуска процессов (заданий) «основана на жадных событиях», т.е. все доступные задания, события запуска которых запускаются, запускаются как можно раньше. Во время загрузки программа upstart синтезирует некоторые начальные события, такие как запуск или rcS, в качестве «корня дерева», ранние службы запускаются на них, а более поздние службы запускаются при запуске первых. Новая работа просто должна установить свой файл конфигурации в / etc / init /, чтобы стать активной.
Модель systemd для запуска процессов (модулей) основана на «отложенной зависимости», то есть модуль будет запускаться только в том случае, если от него зависит какой-либо другой начальный модуль. Во время загрузки systemd запускает «корневой модуль» (default.target, может быть переопределен в grub), который затем транзитивно расширяется и запускает свои зависимости. Новый модуль должен добавить себя в качестве зависимости модуля загрузочной последовательности (обычно multi-user.target), чтобы стать активным.
Использование в дистрибутивах
Теперь некоторые последние данные по Википедии:
По умолчанию дистрибутивы используют upstart:
По умолчанию дистрибутивы используют systemd:
(Смотрите Википедию для получения актуальной информации)
Дистрибутивы, не использующие ни Upstart, ни systemd:
- Devuan (созданный форк Debian, возникший из-за разногласий systemd в сообществе Debian, которые привели к отставке Яна Джексона ), специально продвигает Init Freedom со следующими системами init, которые рассматриваются для включения: sinit , OpenRC , runit , s6 и shepherd .
- Void Linux - использует runit в качестве системы инициализации и супервизора службы
- Gentoo - использует OpenRC
- OS X - использует launchd
- FreeBSD использует традиционную инициализацию в стиле BSD (не SysV init)
- NetBSD использует rc.d
- DragonFly использует традиционный init
- OpenBSD использует скрипт запуска системы rc , описанный здесь
- Alpine Linux (относительно новый и мало известное распределение, с сильным акцентом на безопасности становится все более популярным - например , Docker является перемещение его официальных изображений с Ubuntu на Alpine ) использует OpenRC системы инициализации
полемика
В прошлом был предложен форк 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 много интересных дискуссий:
Аналогичные тенденции наблюдаются и в других дистрибутивах:
философия
Выскочка следует философии Unix DOTADIW - «Делай одно и делай хорошо». Это замена традиционного демона init. Он не делает ничего, кроме запуска и остановки служб. Другие задачи делегируются другим специализированным подсистемам.
systemd делает гораздо больше. Помимо запуска и остановки сервисов, он также управляет паролями, логинами, терминалами, управлением питанием, сбросом настроек, обработкой журналов, точками монтирования файловой системы, сетями и многим другим - смотрите файл NEWS для некоторых функций.
Планы расширения
В соответствии с презентацией Lennart Poettering в 2014 году на GNOME.asia, озаглавленной « Перспектива для systemd« Что было достигнуто »» и «Что ждет впереди», вот основные цели 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 создала системную таблицу Systemd vs SysV Init Linux .