Systemd для Linux

1.

Systemd
Демон инициализации других демонов в
Linux, пришедший на замену другого
демона используемого ранее (/sbin/init).
По сути данный модуль представляет
собой сборник демонов управления
системой, утилит и библиотек
предназначенных для Linux. Его
особенностью является интенсивное
распараллеливание запуска служб в
процессе загрузки системы, что когда то
позволяло существенно ускорить запуск
операционной системы. Однако, после
добавления веб сервера и
журналирования, скорость упала. «d» на
конце означает, что это демон.
Опубликован как свободное программное обеспечение под условиями лицензии
GNU Lesser General Public License версии 2.1 или более поздней.

2.

Преимущества
По сравнению с System V Init:
Иновации — Ништяк! Дайте два!
Сокет-активные и шина-активные службы, которые иногда приводят к лучшему
распараллеливанию взаимозависимых служб.
cgroups используется для отслеживания служебных процессов, вместо
идентификаторов процессов (PID). Это означает, что демоны не будут потеряны
даже после разветвления в другие процессы.
Делает процесс загрузки куда проще, полностью устраняя необходимость
определения зависимостей, во многих случаях благодаря активации D-Bus,
сокетов, file/notify и интеграции udev
Systemd может управлять процессом загрузки с головы до ног, без необходимости
использования какого-либо из существующих сценариев оболочки.
Systemd проста. Интерфейс командной строки, вероятно, является одним из
лучших существующих способов для управления сервисами/модулями. Формат
файла модуля (как .desktop или "INI" файлы) полностью декларативный, может
быть проанализирован с использованием стандартных инструментов, и лёгок в
поддержке.

3.

Преимущества
Файлы модулей systemd, в отличие от скриптов SysV, обычно совместимы с другими
дистрибутивами (уже более 1000 существующих файлов модулей в Fedora) без какихлибо изменений, могут быть обработаны в Debian.
Systemd невероятно быстр (1 секунда для загрузки). Он не был разработан с намёком на
скорость, но делает вещи правильно избегая всех задержек, понесённых в процессе
загрузки.
План перехода легкий, так как существующие сценарии инициализации
рассматриваются в первую очередь: сценарии могут зависеть (с использованием LSB
заголовков) от модулей, модули могут зависеть от сценариев. Более 99% скриптов
инициализации могут быть использованы без модификаций.
Systemd предполагает, что все ресурсы могут появиться и исчезнуть в любой момент.
Здесь используется горячее подключение.
Мы контролируем состояние системы: Systemd отслеживает все демоны, все процессы,
которые запускаются, кто от кого породился или когда что-то вышло из строя, и т. д.
Кроме того, используя (удивительный) журнал, все события syslog() сохраняются и
выводятся в стандартный поток вывода/стандартный поток ошибок ото всех процессов
захваченных systemd. Он имеет модульную конструкцию: все, что сейчас соответствует
rc.sysinit разделяется на множество независимых сервисов, каждый из которых хорошо
документирован и понятен (На данный момент я не уверен в этом — примечание
автора).

4.

Преимущества
dbus/udev могут вернуться к выполнению тех задач, которые они должны делать: оба и udev и dbus
в настоящий момент (mis) - используются для запуска демонов/сервисов длительного действия по
требованию. В случае dbus так и задумано, но в случае udev это не так. В любом случае, это не то,
для чего эти демоны были созданы, что ж это здорово, что не уступая принципам юникса, одна
задача — один демон, теперь мы можем позволить systemd (чья работа заключается в том, чтобы
управлять демонами) контролировать этот процесс. То есть, udev и dbus могут сказать systemd
запустить определенного демона, и он будет вести себя так, как будто он был запущен каким-то
другим способом (у вас есть журналы, статус и т.д.). Одна из проблем, решаемая таким образом
состояние состязаний присуще некоторым демонам (я думаю, что bluetoothd был виновен в этом в
какой-то момент — примечание автора) позволяя обоим запускаться, как можно быстрее при
загрузке (например, поместив его в DAEMONS), и запуститься по требованию dbus. Systemd
гарантирует, что оба этих случая могут произойти, и если они произойдут одновременно у вас
будет только один экземпляр демона, как и ожидалось.
Мы можем сократить число прямых упорядоченных зависимостей между демонами ...
Множество свойств безопасности/песочниц
Сервисные файлы systemd могут (! и, надеюсь, будут — примечание автора) написаны и
распространятся повсеместно, а не каждый дистрибутив будет писать свой собственный rc-скрипт
ведение журнала, наконец, достигло того, что ConsoleKit должен был делать: теперь мы можем
отслеживать пользовательские сессии и места, назначать права доступа к ресурсам на лету и т.д.
Скорость
* http://alexander.holbreich.org/systemd-on-debian-what-do-you-think/

5.

Недостатки
С появлением systemd, а также идеей его
интеграции в дебиан 8, общество разделилось на 3 лагеря:
1. Те, кто был за
2. Те, кто был против
3. Те, кому было интересно смотреть на их сра…
разногласия
Итак почему же люди были против?
Systemd пытается взять на себя много обязанностей
от чего появляются следующие трудности:
Сложность в поддержке, в отладке,
в понимании, перегруженность, разрастание
Появление новых внезапностей(глюкофф). Система не грузится, если /usr
находится на другом разделе (Требуется, чтобы initramfs подсоединил раздел с
/usr до запуска systemd)
Не привычно
Скрытность. Журналирование происходит в двоичном формате, вместо обычного
текстового, требуются дополнительные инструменты для их чтения

6.

Философия Юникс
«Всё сложное состоит из упрощённого».
Init:
В процессе инициализации последовательно выполняются важные проверки,
запускаются необходимые системные процессы, а потом и приложения,
непосредственно взаимодействующие с пользователем. Когда же работа завершена,
именно init выключает компьютер. Вся функциональность построена на философии
юникс: он, при помощи понятных скриптов, запускает тот или иной процесс, всё
происходит прозрачным взаимодействием маленьких примитивных компонент
между собой, которые не лезут не в свою область и, к слову, взаимозаменяемы. За
годы работы система хорошо отладилась.
Systemd:
Скрипты заменены файлами с настройками, работа на высоком уровне осуществлена
за счёт дружелюбной к пользователю архитектуры, параллельная инициализация и
запуск. Изначально брал на себя обязанности по инициализации, запуску и
завершению сеанса, но со временем разработчики решили пойти против
устоявшегося мнения и начали расширять его дополнительными модулями,
добавлять дополнительный функционал, что теперь он уже не только инциализатор
системы. Это сложнейший многокомпонентный механизм, пытающийся своими
силами решать многие стандартные системные задачи (например, управлять
устройствами), причём и настройка, и контроль, и общение между его компонентами
реализованы средствами, далёкими от предлагаемых UNIX-философией.

7.

Компоненты systemd
Как было сказано ранее systemd — это набор утилит для управления загрузкой
системы, на рисунке сверху иллюстрация структуры строения systemd.
Описание некоторых из них будет на следующем слайде.

8.

Компоненты systemd. Продолжение.
systemctl — Главная команда, используемая для контроля и управления
systemd. Основная сфера её применения контроль за состоянием системы
и управление системой и сервисами.
journalctl — У systemd есть своя собственная система журналирования,
называемая ВНЕЗАПНО журнал(journal). Поэтому запуск демона syslog()
больше не требуется. Для вывода журнала используется journalctl
notify — уведомляет systemd о том, что сервис/демон запущен и готов к
работе, или каких то иных изменениях, связанных с его состоянием
cgroups - cgroups (aka control groups, ) особенность ядра линух по
ограничению, контролю и подсчёту использования ресурсов группой
процессов. Сравнивая её с другой похожей «замечательной» командой или
/etc/security/limits.conf, cgroups более гибкая: она может оперировать
(под)группой процессов (возможно, с разными системными
пользователями).
analyze — Показывает состояние процесса загрузки системы и сколько
времени осталось

9.

10.

Использование
Дистрибутивы, в которых systemd
установлен по умолчанию:
Debian GNU/Linux версии 8
Ubuntu 15.04 и позже
Fedora 15 и позже
Mageia 2
Mandriva 2011
Rosa
openSUSE 12.1 и позже
Arch Linux 12.11 (ранее предоставлял возможность использования
самописной системы инициализации, на текущее время можно использовать
любой другой (без официальной поддержки со стороны дистрибутива))
Sabayon 13.08

11.

Использование
Также доступен в:
Debian GNU/Linux версии 7 (имеет пакет systemd в главной ветке)
Gentoo (предоставляет пакеты systemd в стабильной ветке)
Red Hat Enterprise Linux 7 включает в себя systemd
В данных дистрибутивах оставлены другие системы инициализации, переход
осуществляется через две-три команды. Или можно использовать устаревшие
дистрибутивы.

12.

Вопросы на ответы

13.

Вопросики, вопросики
Как используются основные утилиты systemd? (systemctl, notify, analyze и
прочие)
Умеет ли systemd обрабатывать скрипты использовавшиеся в init? Если
нет, то почему?
Для добавления сервиса требуются 2 файла: скрипт(script), модуль(unit.service)
Если script что то включает/выключает, тогда они должны выглядеть примерно
так:
Unit.service:
Script:
start() {
exec blah-blah pwrOFF etc
}
stop() {
exec blah-blah pwrON etc
}
case $1 in
start|stop) "$1" ;;
esac
[Unit]
Description=TurnON/TurnOFF
SOMETHING
[Service]
Type=oneshot
ExecStart=/path/to/script start
ExecStop=/path/to/script stop
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target

14.

Вопросики, вопросики
Как можно изменять порядок загрузки стандатрых демонов и как добавить свой
демон для загрузки при старте системы?
/usr/lib/systemd/system/ – модули из установленных пакетов RPM.
/run/systemd/system/ — модули, созданные в рантайме. Этот каталог приоритетнее
каталога с установленными модулями из пакетов.
/etc/systemd/system/ — модули, созданные и управляемые системным
администратором. Этот каталог приоритетнее каталога модулей, созданных в рантайме.
* https://habrahabr.ru/company/infobox/blog/241237/
Systemd способен только запускать указанные ему скрипты или имеет ещё какойнибудь полезный функционал?
Systemd расширяет свои границы дозволенного, постепенно он становится сложным
многокомпонентным механизмом, пытающимся контролировать взаимодействие и
работу служб, далёких от инициализации, запуска и завершения работы.
Добавление веб-сервера и журналирования сделало загрузку через systemd
медленнее, чем через использовавшийся ранее init? Если да, то с чем это связано?
Нет, медленнее относительно загрузки через systemd без ведения журнала и веб-сервера.

15.

Пример загрузки системы с минимальной настройкой
волшебство

16.

Источники
https://en.wikipedia.org/wiki/Systemd
https://ru.wikipedia.org/wiki/Systemd
http://alexander.holbreich.org/systemd-on-debian-what-do-you-think/
https://habrahabr.ru/company/centosadmin/blog/255845/
https://habrahabr.ru/post/240839/
https://wiki.archlinux.org/index.php/Systemd и его русский аналог
http://www2.kangran.su/~nnz/pub/s4a/s4a_latest.pdf
https://habrahabr.ru/company/infobox/blog/241237/
https://coreos.com/docs/launching-containers/launching/getting-started-with-sy
stemd/
https://www.linux.org.ru/forum/general/8112060
https://www.linux.org.ru/forum/talks/7590171
http://complike.ru/mysli-o-systemd-ili-pochemu-mnogie-polzovateli-protiv/

17.

Источники
http://www.computerra.ru/106491/init-vs-systemd/
http://wiki.opennet.ru/Systemd_%D0%B4%D0%BB%D1%8F_%
D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1
80%D0%B0%D1%82%D0%BE%D1%80%D0%BE%D0%B2,_%D1%87%D0%B
0%D1%81%D1%82%D1%8C_3:_HOW-TO:_%D0%BF%D1%80%D0%B5%D
0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%
D%D0%B8%D0%B5_SysV_init-%D1%81%D0%BA%D1%80%D0%B8%D0
%BF%D1%82%D0%B0_%D0%B2_systemd_service-%D1%84%D0%B0
%D0%B9%D0%BB
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/
html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Unit
_Files.html
http://www.linuxuser.co.uk/features/systemd-for-better-or-worse
https://wiki.debian.org/Debate/initsystem/systemd
https://www.linuxquestions.org/questions/linux-general-1/what-are-the-advanta
ges-disadvantages-of-using-systemd-versus-sysvinit-4175422544/

18.

Источники
http://wiki.opennet.ru/Systemd_%D0%B4%D0%BB%D1%8F_%
D0%B0%D0%B4%D0%BC%D0%B8%D0%BD%D0%B8%D1%81%D1%82%D1
80%D0%B0%D1%82%D0%BE%D1%80%D0%BE%D0%B2,_%D1%87%D0%B
0%D1%81%D1%82%D1%8C_3:_HOW-TO:_%D0%BF%D1%80%D0%B5%D
0%BE%D0%B1%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D0%B0%D0%
D%D0%B8%D0%B5_SysV_init-%D1%81%D0%BA%D1%80%D0%B8%D0
%BF%D1%82%D0%B0_%D0%B2_systemd_service-%D1%84%D0%B0
%D0%B9%D0%BB
- про создание модуля для init скрипта для systemd
https://wiki.archlinux.org/index.php/systemd#Handling_dependencies
https://wiki.archlinux.org/index.php/systemd#Editing_provided_units