Оновлення 2016 року
Більшість відповідей тут - п'ять років, тож час для деяких оновлень.
Ubuntu раніше використовував запуск за замовчуванням, але минулого року вони відмовилися від нього на користь systemd - див.
Через це є приємна стаття Systemd for Upstart Users на Ubuntu wiki - дуже детальне порівняння між запуском та systemd та керівництвом про перехід від upstart до systemd.
(Зверніть увагу, що згідно з вікі Ubuntu ви все ще можете запустити на початку поточні версії Ubuntu за замовчуванням, встановивши upstart-sysvта запустивши, sudo update-initramfs -uале враховуючи сферу проекту systemd, я не знаю, як це працює на практиці, чи є systemd чи ні можна видалити.)
Більшість інформації в розділах Команди та Сценарії нижче пристосовані з деяких прикладів, використаних у цій статті (що зручно ліцензувати так само, як і внески користувачів Stack Exchange згідно з ліцензією Creative Commons Attribution-ShareAlike 3.0 ).
Ось швидкий порівняння загальних команд та простих скриптів, див. Розділи нижче для детального пояснення. Ця відповідь порівнює стару поведінку систем на основі Upstart з новою поведінкою систем на основі системних систем, про що йдеться у запитанні, але зауважте, що команди, позначені як "Upstart", не обов'язково залежать від Upstart - це часто команди, які є загальними для кожної несистемної системи Linux та Unix.
Команди
Запуск:
- на початку:
su
- systemd:
machinectl shell
(див. розділ «Заміна команди su») нижче
Запуск екрана:
- на початку:
screen
- systemd:
systemd-run --user --scope screen
(див. розділ "Несподіване вбивство фонових процесів" нижче)
Запуск tmux:
- на початку:
tmux
- systemd:
systemd-run --user --scope tmux
(див. розділ "Несподіване вбивство фонових процесів" нижче)
Початок роботи:
- на початку:
start foo
- systemd:
systemctl start foo
Припинення роботи foo:
- на початку:
stop foo
- systemd:
systemctl stop foo
Перезапуск робочого місця:
- на початку:
restart foo
- systemd:
systemctl restart foo
Лістинг:
- на початку:
initctl list
- systemd:
systemctl status
Перевірка конфігурації робочого місця:
- на початку:
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
Колода
Після запуску журнали - це звичайні текстові файли в каталозі / var / log / upstart, тому ви можете обробити їх як завжди:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
У системних журналах зберігаються у внутрішньому бінарному форматі (не як текстові файли), тому 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
Приклад системного сценарію, написаного /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 в запиті тягнути # тисячі двадцять-два:
тому що, на думку Леннарта Поттерінга, "су - це справді зламана концепція" .
Він пояснює, що "ви можете використовувати су і судо, як і раніше, але не сподівайтеся, що це спрацює в повному обсязі " .
Офіційний спосіб досягти suподібної поведінки зараз:
machinectl shell
Це було
пояснено Леннартом Поутеринг
в обговоренні випуску № 825:
"Ну, довгі дискусії з цього приводу тривали, але проблема полягає в тому, що те, що передбачається робити, є дуже незрозумілим. [...] Довге коротке оповідання: су - це справді зламана концепція. Це дасть вам вигляд оболонки , і прекрасно використовувати його для цього, але це не повний логін, і його не слід помиляти ". - Леннарт Поетинг
Дивитися також:
Несподіване вбивство фонових процесів
Такі команди, як:
більше не працює, як очікувалося . Наприклад, nohupце команда POSIX, щоб переконатися, що процес продовжує працювати після виходу з сеансу. Він більше не працює на systemd. Також такі програми, як screenі tmuxпотрібно викликати по-особливому, або в іншому випадку процеси, які ви запускаєте з ними, загинуть (хоча не отримувати цих процесів вбиті, як правило, головна причина запуску екрана або tmux в першу чергу).
Це не помилка, це обдумане рішення, тому воно, ймовірно, не виправиться в майбутньому. Ось що сказав Леннарт Поетрінг з цього приводу:
На мою думку, UNIX насправді був досить дивним, що він за замовчуванням дозволяв довільному коду користувача залишатись без обмежень після виходу з системи. Зараз багато людей ОС обговорювали, що це може бути можливим, але, звичайно, не за замовчуванням, але поки що ніхто не наважувався перевести комутатор, щоб перетворити його з замовчування на опцію. Не прибирати користувальницькі сеанси після виходу з мережі - це не тільки некрасиво і дещо шалено, але й проблема безпеки. systemd 230 тепер остаточно переключив перемикач і, нарешті, за замовчуванням все очистить правильно, коли користувач вийде з системи.
Для отримання додаткової інформації див:
Концепція запуску на високому рівні
Певним чином, systemd працює назад - в запущених роботах починаються, як тільки вони можуть, а в системних роботах починаються, коли треба. Зрештою, обидві системи можуть бути розпочаті однакові робочі місця і в майже однаковому порядку, але ви думаєте про це, дивлячись з протилежного напрямку, так би мовити.
Ось як це пояснює Systemd for Upstart Users :
Модель Upstart для запуску процесів (завдань) "жадібна на основі подій", тобто всі доступні завдання, чиї події запуску стартують якомога раніше. Під час завантаження upstart синтезує деякі початкові події, такі як запуск або rcS як "корінь дерева", ранні сервіси починаються з них, а пізніші служби починаються при запуску першого. Нове завдання просто повинне встановити його файл конфігурації в / etc / init /, щоб стати активним.
Модель systemd для запуску процесів (одиниць) "ледача залежність", тобто одиниця запускається лише тоді, коли і коли від неї залежить інший стартовий блок. Під час завантаження systemd запускає "кореневу одиницю" (default.target, може бути замінена в grub), яка потім транзитивно розширюється і запускає свої залежності. Новий блок повинен додати себе як залежність одиниці завантажувальної послідовності (зазвичай багатокористувацької. Цільової), щоб стати активним.
Використання в дистрибутивах
Зараз деякі останні дані згідно Вікіпедії:
Розподіл, що використовує початкові функції за замовчуванням:
Дистрибуції, використовувані systemd за замовчуванням:
(Дивітьсясь у Вікіпедії для найновішої інформації)
Дистрибуції, що не використовують ні Upstart, ні systemd:
Суперечки
Раніше вилка Debian пропонувалася уникати системних . Створено Devuan GNU + Linux - роздріб Debian без systemd (завдяки fpmurphy1 за вказівку на це у коментарях).
Для отримання додаткової інформації про цю суперечку див.
Як багато хто з вас, можливо, вже знає, голосування Init GR Debian за сприяння Ian Jackson не було корисним для захисту спадщини Debian та її користувачів від системної лавини.
Ця ситуація розраховує на блокування системних залежностей, що фактично загрожує свободі розвитку та має серйозні наслідки для Debian, його верхової та нижньої течії.
CTTE вдалося змінити залежність і завоювати нам час на тонку установку systemd над sysvinit, але навіть цей процес був виснажливим і повним драматизму. Зрештою, тиждень тому Іен Джексон пішов у відставку. [...]
Я подаю у відставку з Технічного комітету негайно.
Хоча важливо, щоб погляди 30-40% проекту, які погоджуються зі мною, продовжували бути представлені в ТК, я сам напевно занадто суперечливий на сьогоднішній день, щоб це зробити. Я повинен відійти, щоб спробувати зменшити ступінь персоналізації розмов про управління проектом. [...]
Девуан народився із суперечки щодо рішення використовувати Debian як систему за замовчуванням для Debian. Офіційна позиція Debian на Systemd повна претензій , що інші розвінчали . Зацікавлені читачі можуть продовжувати обговорювати цю гарячу тему в "Полеміці" . Однак ми радимо вам зберігати прохолоду та голос. У Devuan нам більше цікаво програмувати їх неправильно, ніж озиватися назад. [...]
Створено деякі веб-сайти та статті, присвячені системній суперечці:
У новинах Hacker є багато цікавих дискусій:
Аналогічні тенденції спостерігаються і в інших дистрибутивах:
Філософія
на початку слідує філософії Unix DOTADIW - "Зроби одну річ і зроби це добре". Це заміна традиційному демону Ініта. Це не робить нічого, крім запуску та зупинки послуг. Інші завдання делеговані іншим спеціалізованим підсистемам.
systemd робить набагато більше, ніж це. Окрім запуску та зупинки послуг, він також управляє паролями, входами, терміналами, керуванням електроенергією, скиданням заводських налаштувань, обробкою журналів, точками кріплення файлової системи, мережевим зв’язком та багато іншого - про деякі функції див. У файлі NEWS .
Плани розширення
Згідно з перспективою систематизованого того, що було досягнуто, а що - перед собою презентація 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 , "слід зазначити, що systemd протягом багатьох років розширив сферу своєї роботи, що виходить за рамки простого запуску системи".
Я намагався включити сюди більшість відповідної інформації. Тут я порівнюю загальні риси Upstart і systemd, коли вони використовуються як системи init, про що йдеться у запитанні, і я згадую лише функції systemd, які виходять за рамки системи init, оскільки їх не можна порівняти зі запуском, але важлива їх наявність щоб зрозуміти різницю між цими двома проектами. Для отримання додаткової інформації слід перевірити відповідну документацію.
Більше інформації
Більше інформації можна отримати за адресою:
Екстри
Команда LinOxide створила чіт-лист Systemd vs SysV Init Linux .