Десятиріччя systemd у світі Linux відзначається без єдиної думки серед користувачів – розбіжності щодо нього залишаються такими ж гострими, як і раніше. Попри його поширення у багатьох провідних дистрибутивах Linux, сильна опозиція не згасає.
Етапи завантаження Linux
Після ввімкнення комп’ютера, відбувається ініціалізація апаратного забезпечення. Далі, в залежності від типу завантажувального сектора, або головного завантажувального запису (MBR), або Уніфікованого розширюваного інтерфейсу прошивки (UEFI) виконуються відповідні операції. Завершальним етапом цих процесів є запуск ядра Linux.
Ядро завантажується в оперативну пам’ять, розпаковується та ініціалізується. Потім у ОЗП створюється тимчасова файлова система, зазвичай за допомогою утиліти initramfs або initrd. Це дозволяє ідентифікувати та завантажити потрібні драйвери. В результаті, файлова система користувацького простору може завантажитися і підготуватися до запуску користувацького середовища.
За створення користувацького середовища відповідає процес ініціалізації, який є першим процесом, запущеним ядром у користувацькому просторі. Він має ідентифікатор процесу (PID) 1. Усі інші процеси є прямими або непрямими нащадками процесу ініціалізації.
До systemd основним стандартом для процесу ініціалізації була система Unix System V init. Існували й інші варіанти, але System V init була найбільш поширеною у більшості дистрибутивів, що не походять від Berkeley Software Distribution (BSD). Оскільки вона походить безпосередньо з System V Unix, багато хто вважав її “офіційним способом” ініціалізації.
Процес ініціалізації запускає всі демони та служби, необхідні для повноцінної роботи операційної системи. Ці демони забезпечують функціонування мережі, управління апаратним забезпеченням та відображення екрану завантаження.
Багато з цих фонових процесів продовжують працювати після запуску. Вони виконують такі завдання, як реєстрація подій, моніторинг змін апаратного забезпечення при підключенні або відключенні пристроїв, та керування процесом входу користувачів. Не дивно, що система ініціалізації також надає функції управління службами.
Ми можемо скористатися командою ps, щоб переглянути процес з PID 1. Використаємо параметри f (повний формат списку) та p (ідентифікатор процесу):
ps -fp 1
Як бачимо, процес з PID 1 – це systemd. Виконання цієї ж команди в Manjaro Linux дало інший результат. Процес з PID 1 був визначений як /sbin/init. Швидкий огляд цього файлу показує, що це символічне посилання на systemd:
ps -fp 1
ls -hl /sbin/init
Використовуючи параметр ppid (ідентифікатор батьківського процесу) з ps, ми можемо побачити, які процеси були безпосередньо запущені systemd:
ps -f --ppid 1
Список виходить досить довгим, як видно на зображенні нижче.
Альтернативні варіанти
Розроблялися численні проєкти як альтернатива традиційній системі System V init. Однією з основних проблем є те, що в System V init усі процеси запускаються послідовно, один за одним. Для підвищення ефективності завантаження багато альтернативних проєктів використовують паралелізм для одночасного та асинхронного запуску процесів.
Ось деяка інформація про декілька з них:
Upstart: Розроблений компанією Canonical, використовувався в Ubuntu 9.10, Red Hat, Red Hat Enterprise Linux (RHEL) 6, CentOS 6 та Fedora 9.
Runit: Працює на FreeBSD та інших похідних BSD, macOS та Solaris, а також системах Linux. Це також є системою ініціалізації за замовчуванням в Void Linux.
s6-linux-init: Ця заміна для System V init створена з дотриманням філософії Unix, яка часто зводиться до вислову “роби одну річ і роби її добре”.
Існує ще багато альтернативних систем з різною функціональністю та дизайном. Проте жодна з них не викликала такого резонансу, як systemd.
Поява systemd
systemd був випущений у 2010 році та почав використовуватися в Fedora у 2011 році. З того часу він був впроваджений у багатьох дистрибутивах. Його розробили Леннарт Поттерінг та Кей Сіверс, два інженери-програмісти з RedHat.
systemd – це набагато більше, ніж просто заміна ініціалізації. Це набір приблизно з 70 бінарних файлів, які обробляють ініціалізацію системи, демони та служби, ведення журналів та багато інших функцій, які раніше оброблялися окремими модулями в Linux. Більшість з них не мають прямого відношення до ініціалізації системи.
Ось деякі демони, які надає systemd:
systemd-udevd: керує фізичними пристроями.
systemd-logind: керує входом користувачів.
systemd-resolved: забезпечує роздільну здатність мережевих імен для локальних програм.
systemd-networkd: керує мережевими пристроями та їх виявленням, а також мережевими конфігураціями.
systemd-tmpfiles: створює, видаляє та очищає тимчасові файли та каталоги.
systemd-localed: керує налаштуваннями мовного стандарту системи.
systemd-machined: виявляє і відстежує віртуальні машини та контейнери.
systemd-nspawn: запускає команди або процеси в легкому контейнері, що надає функціонал, схожий на chroot.
І це лише верхівка айсберга, що і є головною причиною суперечок. Systemd давно вийшов за рамки функціональності, необхідної від системи ініціалізації, що його критики називають розширенням сфери відповідальності.
“Занадто великий. Занадто багато робить”
Критики systemd наголошують на його великому наборі різноманітних функцій. Усі ці можливості вже існували в Linux, можливо, потребували оновлення або нового підходу. Однак, об’єднання усієї цієї функціональності в те, що має бути системою ініціалізації, з архітектурної точки зору є дивним.
Systemd називають єдиною точкою відмови для занадто багатьох важливих функцій, хоча це і не зовсім так. Звичайно, це йде врозріз з філософією Unix щодо створення невеликих інструментів, які добре працюють разом, замість великих програм, що роблять усе одразу. Хоча systemd не є монолітом в прямому розумінні (він складається з багатьох виконуваних файлів, а не одного величезного), він включає в себе різноманітні інструменти управління та команди під одним “парасолем”.
Хоча systemd не є монолітним, він великий. Щоб оцінити його масштаб, ми порахували кількість рядків тексту в кодовій базі ядра 5.6.15 та гілки master репозиторію systemd на GitHub.
Це був досить грубий підрахунок. Рахувалися рядки тексту, а не лише рядки коду. Тому враховувалися коментарі, документація і все інше. Тим не менш, це було пряме порівняння, яке дало нам простий критерій:
( find ./ -name '*.*' -print0 | xargs -0 cat ) | wc -l
Ядро містило майже 28 мільйонів (а точніше 27 784 340) рядків тексту. Натомість у systemd було 1 349 969, тобто майже 1,4 мільйона. Згідно з нашою прямолінійною метрикою, розмір systemd складає близько 5% розміру ядра, що є значною цифрою!
Для порівняння, кількість рядків для сучасної реалізації System V init для дистрибутиву Arch Linux склала 1721 рядок.
Поттерінг явно не звертає уваги на стандарти Інституту інженерів електротехніки та електроніки (IEEE), чи POSIX. Він навіть заохочував розробників ігнорувати POSIX:
“Отже, придбайте собі копію програмного інтерфейсу Linux, ігноруйте все, що там говорить про сумісність POSIX, і створюйте своє дивовижне програмне забезпечення для Linux. Це значно полегшує життя!”
Звучали звинувачення, що systemd – це проєкт Red Hat, який приносить користь лише Red Hat, але нав’язується усім користувачам Linux. Так, він був започаткований в Red Hat і керується ними. Однак, з 1321 автора, лише деякі працюють у Red Hat.
То ж які переваги це дає Red Hat?
Джим Уайтхерст, президент IBM, який колись був генеральним директором Red Hat, сказав:
“Red Hat розглянула багато доступних варіантів і навіть використовувала Upstart від Canonical для Red Hat Enterprise Linux 6. Зрештою, ми обрали systemd, оскільки це найкраща архітектура, що забезпечує розширюваність, простоту, масштабованість та чітко визначені інтерфейси для вирішення проблем, які ми бачимо сьогодні та передбачаємо в майбутньому.”
Уайтхерст також зазначив, що бачать переваги і у вбудованих системах. Red Hat співпрацює з “найбільшими постачальниками вбудованих пристроїв у світі, особливо в телекомунікаційній та автомобільній галузях, де стабільність та надійність є головними пріоритетами”.
Це виглядає як технічно обґрунтовані причини. Зрозуміло, що компанія потребує надійності, і Red Hat має право дбати про власні інтереси, але чи всі інші повинні слідувати цьому прикладу?
Чи всі фанати systemd?
Деякі критики systemd стверджують, що дистрибутиви та користувачі сліпо підтримують Red Hat і приймають systemd.
Однак, як і фраза “пити Kool-Aid”, це не зовсім точно. Фраза виникла в 1978 році після того, як лідер культу Джим Джонс змусив понад 900 своїх послідовників вчинити самогубство, випивши рідину зі смаком винограду з ціанідом. З тих пір, Kool-Aid асоціюється з цим трагічним випадком, хоча насправді група пила Flavor Aid.
Крім того, дистрибутиви Linux не слідують Red Hat сліпо; вони приймають systemd після серйозних роздумів. Дискусії точилися в списках розсилки Debian протягом тривалого часу. У 2014 році спільнота проголосувала за прийняття systemd як системи ініціалізації за замовчуванням, а також за підтримку альтернатив.
Debian є важливим прикладом, оскільки він не є похідним від RedHat, Fedora чи CentOS. Red Hat не має впливу на рішення Debian. І Debian, як і PID 1, має багато нащадків, включаючи Ubuntu та її численні варіанти.
Рішення, прийняті спільнотою Debian, є важливими. Вони активно обговорюються і голосуються з використанням методу голосування Кондорсе. Спільнота не приймає таких рішень легковажно.
У грудні 2019 року було проведено повторне голосування продовжувати зосереджуватися на systemd та далі вивчати альтернативи. Це не сліпе слідування, а скоріше класичний приклад демократії та свободи вибору в дії.
Обмеження вибору
Зазвичай ви не можете вибирати, чи використовувати systemd з певним дистрибутивом Linux. Натомість самі дистрибутиви вирішують, чи хочуть вони його використовувати, а ви можете вибрати, який дистрибутив Linux вам більше подобається. Можливо, дистрибутив Linux, який вам подобався, перейшов на systemd. Як улюблений музикант, що змінює жанри, це може бути неприємно.
Користувачі, які використовують Debian, Fedora, CentOS, Ubuntu, Arch, Solus та openSUSE і не згодні з прийняттям systemd, можуть відчути себе витісненими з улюбленого дистрибутива. Якщо вони мають сильні почуття щодо архітектурних рішень, розширення функціональності або ігнорування POSIX, вони можуть вважати недоцільним продовжувати використовувати цей дистрибутив.
Звичайно, є різні думки. З одного боку, є ті, хто не розуміють проблему (або вона їх не хвилює), а з іншого – палкі противники. Десь посередині знаходяться ті, хто не любить змін, але не турбуються про це настільки, щоб змінювати дистрибутив. Але як щодо тих, хто вимушено залишає дистрибутив через свої переконання чи принципи?
На жаль, не так просто встановити потрібну систему ініціалізації. Не всі мають достатньо технічних навичок для цього, а проблеми ускладнюються, коли такі програми, як GNOME, мають залежності від systemd.
А як щодо переходу на інший дистрибутив? Деякі, як Devuan, з’явилися як форки дистрибутивів без systemd (у цьому випадку Debian), які прийняли systemd. Використання Devuan має бути схожим на використання батьківського дистрибутиву, але це стосується не всіх форків без systemd. Наприклад, якщо ви перейдете з Fedora на AntiX, Gentoo або Slackware, ви отримаєте зовсім інший досвід.
Це не зникне
Мені подобається дещо з того, що робить systemd (прості та стандартизовані механізми керування процесами). Я не розумію обґрунтування деяких інших його функцій (бінарні журнали). Мені також не подобається те, що він робить (оновлення домашніх папок – хто про це просив?).
Такі дистрибутиви, як Debian, роблять розумні кроки і вивчають альтернативи, щоб мати можливість вибору. Проте systemd тут надовго.
Якщо ви адмініструєте машини Linux для інших, вивчайте systemd так само добре, як ви знаєте System V init. У такому разі, ви будете готові до будь-якої ситуації.
Просто використовуєте Linux вдома? Тоді виберіть дистрибутив, який відповідає як вашим технічним потребам, так і вашим принципам використання Linux.