Я створюю дистрибутив Linux, і тепер мені потрібна програма init. Я можу кодувати в c дуже добре, і я знаю досить багато про Linux (не так багато, але я використовую Arch Linux для розробки протягом 4 років), тому я подумав, що я повинен спробувати написати свій власний базовий сценарій init у C. Я був просто цікаво, які завдання виконує init, щоб налаштувати систему на просту оболонку? (Коли я запитую "що робить init?", Я знаю, що таке init і для чого це. Я просто не знаю, які завдання він виконує.)

Мені не потрібен код , і я , можливо , навіть не потрібні базові команди , але я дійсно потрібен порядок , що вони працюють в.

Система 5 initрозповість лише невелику частину історії.

Існує свого роду короткозорість, яка впливає на світ Linux. Люди думають, що вони використовують річ, яку називають "Система 5 init", і це те, що є традиційним і найкращим місцем для початку. Насправді це не так.

Традиція насправді не є такою, якою говорять такі люди, для початку. Система 5 initта Система 5 rcвідносяться до AT&T UNIX System 5, що було майже таким же далеким після першого UNIX, як зараз (скажімо, після першої версії Linux-Mandrake).

Перше видання UNIX мало init. Цього не було rc. Мова збірки 1-го видання init( чий код був відновлений і наданий доступними Warren Toomey et al. ) Безпосередньо породив і відновив 12 gettyпроцесів, встановив 3 вбудовані файлові системи із вбудованої таблиці та безпосередньо запустив програму з домашнього каталогу ім'я користувача mel. gettyСтіл був також безпосередньо в образі програми.

Ще через десятиліття після UNIX System 5 з'явилася так звана "традиційна" система init Linux. У 1992 році Мікель ван Смооренбург (пере-) написав Linux init+ rcта пов'язані з ними інструменти, які зараз люди називають «Система 5 init», хоча це насправді не програмне забезпечення системи UNIX 5 (і це не просто init).

Система 5 init/ rcне найкраще місце для запуску, і навіть якщо додати знання про systemd, яке не охоплює половини того, що потрібно знати. Провели багато роботи в галузі дизайну init (для Linux та BSD), що відбулося лише за останні два десятиліття. Були обговорені, прийняті, розроблені, впроваджені та застосовані всілякі інженерні рішення. Комерційні спілки теж багато зробили.

Існуючі системи для вивчення та навчання

Ось неповний перелік деяких основних систем init, окрім цих двох, та однієї чи двох їх (декількох) важливих точок:

• Фінанси Йоахіма Нілссона пішли шляхом використання більш зручного для редагування файлу конфігурації.
• Мінімальність Фелікса фон Лейтнера пішла на систему конфігурації файлової системи - це база даних, невеликі сліди пам’яті та залежність від запуску / зупинки init.
• Пробіг Герріта Папа підходив до того, що я раніше описав як підхід до нерегулярного чотирьох сценаріїв оболонок .
• InitNG мав на меті мати залежності, названі цілі, кілька файлів конфігурації та більш гнучкий синтаксис конфігурації з цілим завантаженням більше налаштувань для дочірніх процесів.
• На початку попрацювали на повне перепроектування, моделюючи систему не як послуги та взаємозалежності взагалі, а як події та завдання, викликані ними.
• Дизайн ноша включає виштовхування всіх служб управління (включаючи навіть нерестування та пожовкненняgetty зомбі) в окремий менеджер сервісів, а також просто обробку пристроїв / символьних посилань / каталогів та каталогів та системних подій, характерних для операційної системи.
• sinit - дуже простий ініт . Він виконує /bin/rc.initзавдання, запускати програми, монтувати файлову систему тощо. Для цього можна використовувати щось на зразок minirc .

Більше того, близько 10 років тому серед користувачів демонтів і інших людей було обговорено використання svscanв якості процесу №1, що призвело до таких проектів, як svscan Пола Ярка як дослідження 1-го процесу , ідеї Герріта Папа та svscan Лорана Беркота як процес 1 .

Що підводить нас до того, чим займаються програми №1.

Що виконують програми №1

Поняття про те, що слід "робити" процесу №1, за своєю природою суб'єктивні. Важливим об'єктивним критерієм проектування є те, що потрібно робити як мінімум №1 . Ядро пред'являє до нього кілька вимог. І завжди є якісь особливі для операційної системи речі різного роду. Якщо говорити про те, який процес №1 традиційно робимо, то ми не на такому мінімумі і ніколи насправді не були.

Існує кілька речей, які вимагають у різних ядрах операційної системи та інших програмах процесу №1, від якого просто не вдається вийти.

Люди скажуть вам, що fork()головна функція процесу №1 - це те, що є батьком сирітських процесів. Як не дивно, це неправда. Справа з осиротілими процесами (із останніми ядрами Linux, як пояснено на https://unix.stackexchange.com/a/177361/5132 ) є частиною системи, яку можна значною мірою вивести з процесу №1 в інші процеси, наприклад спеціалізований менеджер з обслуговування . Все це менеджери сервісних послуг, які працюють поза процесом №1:

• програма IBM AIX srcmstr, контролер системних ресурсів
• Ґерріт Папе runsvdirз бігу
• Даніель Дж. Бернштейн svscanз демонтаолів, Адам Сампсон svscanз фрідета , Брюс Гюнтер svscanз демонмонтолів-на біс і Лоран Берко s6-svscanз s6
• Уейн Маршалл perpdз перп
• інструмент управління сервісом в Solaris 10
• service-managerвід Nosh

Так само, як пояснено на веб- сайті https://superuser.com/a/888936/38062 , вся /dev/initctlідея не повинна знаходитись поблизу процесу №1. Як не дивно, саме високоцентралізована система, яка демонструє, що її можна вийти з процесу №1.

І навпаки, обов'язкові речі для init, що люди зазвичай забувають в їх поза-топ-оф-головки конструкції, такі речі, як обробка SIGINT, SIGPWR, SIGWINCHі так далі вирушає з ядра і введення в дію різні запити на зміну стану системи , послані від програм, які "знають", що певні сигнали для обробки №1 означають певні речі. (Наприклад: Як пояснено на https://unix.stackexchange.com/a/196471/5132 , набори інструментів BSD "знають", що SIGUSR1мають конкретне значення.)

Існують також одноразові завдання ініціалізації та доопрацювання, які неможливо уникнути, або страждати від цього не будуть, наприклад, встановлення файлових систем "API" або промивання кешу файлової системи.

Основи роботи з файловими системами "API" мало чим відрізняються від функціонування initром 1-го видання UNIX: В одному є список інформації, вкладений в програму, а в одному просто mount()всі записи в списку. Цей механізм ви знайдете в системах, таких як BSD (sic!) init, Через ніс system-manager, до systemd.

"налаштувати систему на просту оболонку"

Як ви зауважили, init=/bin/shне встановлюється файлова система "API", аварійно виходить з ладу , не змиваючись кеш, коли один тип exit( https://unix.stackexchange.com/a/195978/5132 ) і взагалі залишає його (супер) користувачеві вручну робити дії, які роблять систему мінімально зручною.

Щоб побачити, що насправді не має іншого вибору, як робити в програмах № 1, і, таким чином, налаштувати вас на хороший курс для вашої заявленої мети проектування, найкращим варіантом є перегляд перекриттів у роботі провідника Герріта Папа, Фелікс фон Мініатюр Leitner, а system-managerпрограма з пакету nosh. Колишні двоє демонструють дві спроби бути мінімалістичними, але все-таки обробляють речі, яких неможливо уникнути.

Останнє корисне, я пропоную, для його широкого ручного запису для system-managerпрограми, в якому детально описано, які файлові системи "API" встановлені, які завдання ініціалізації виконуються та якими сигналами обробляються; у системі, яка за задумом системного менеджера просто породила три інші речі (менеджер сервісів, супровідний реєстратор та програма для запуску змін стану), і це зробити неминуче лише в процесі №1.

System V init на Debian (є й інші варіанти та варіанти) робить наступне:

• При введенні рівня пробігу він викликає скрипти /etc/rcX.d/S*в алфавітно-цифровому порядку, де Xзнаходиться рівень пробігу. Ці сценарії повинні налаштувати рівень запуску. Типова установка - це запуск демонів і виконання завдань налаштування для цього рівня запуску. Це разова річ, яка робиться під час виходу на рівень.
• Перебуваючи на рівні запуску, він запускає демони, перелічені в /etc/inittabяк потрібні бути активними під час цього рівня. Якщо ці демони перестають працювати, вони перезапускають їх. Хоча у вас може бути будь-який демон, яким ви хочете керувати init, як мінімум, ви хочете декілька getty, щоб ви могли увійти в систему. gettyВиходить із завершення входу, а потім initперезавантажує його, надаючи новий запит на вхід.
  
  • Якщо демон перезавантажується занадто багато разів за занадто короткий час, він зупиняється на спробі перезапустити його на деякий час.
  • Просто тому, що щось було запущено скриптами запускання при введенні рівня запуску, не змушує initавтоматично намагатися продовжувати його працювати. Вам потрібно вказати це окремо в /etc/inittab.
• Виходячи з рівня запуску, він викликає сценарії /etc/rcX.d/K*в алфавітно-цифровому порядку, де Xзнаходиться рівень пробігу. Спосіб реалізації відключення або перезавантаження - це визначення рівня запуску для цих подій і виконання останнього завдання, виконаного командою haltабо reboot.
• Він закликає виконувані файли у відповідь на певні події, наприклад, події живлення або Ctrl-Alt-Del.
• Він прослуховує сокет, якщо він отримає певні повідомлення, він змінить рівень запуску.

Таким чином, ви можете використовувати initв якості менеджера рудиментарних послуг, якщо хочете, але головне завдання цих днів - тримати gettyдоступність, щоб користувач міг увійти в систему і почати переходи на рівні пробігу.

Мені було просто цікаво, які завдання виконує init, щоб налаштувати систему на просту оболонку?

Що б ти не хотів. У Debian у кожному /etc/rcX.dкаталозі є символьне посилання на сценарій у, /etc/init.dі ви можете повністю налаштувати або видалити ці сценарії. Порядок встановлюється попереднім попередженням кожного сценарію з а 00, 01і т.д.

Ви також можете вказати -bпараметр init(тобто за допомогою командного рядка ядра), якщо ви просто хочете initнерестовити оболонку. Коли ви виходите з оболонки, initвмирає, а коли initпомирає, ядро ​​панікуватиме.

Абсолютний голий мінімум, який повинен зробити init, це запустити принаймні одну іншу програму і ніколи не виходити. Якщо init виходить, система виходить з ладу. Я гадаю, що навіть запуск однієї іншої програми не є суворо необхідним, але якщо ви цього не зробите, init повинен був би нести відповідальність за те, щоб робити все, що система має зробити, або це не буде дуже корисно.

init Ви можете робити все, що завгодно

init - це довільний виконуваний файл, який викликається ядром Linux в кінці процесу завантаження (і єдиний з таких виконуваних файлів).

Зазвичай він реалізується як виконуваний файл ELF, але він навіть може бути сценарієм оболонки з chmod +x: Init як сценарій оболонки

Типові реалізації, такі як sysemd, будуть читати файли конфігурації, ofen /etc/initrc, а потім розщеплюватимуть купу процесів в користувальницькій основі на основі цих конфігурацій для реалізації різних аспектів системи.

Однак це повністю конкретна реалізація, і тому на запитання не можна відповісти, не вказавши конкретну реалізацію. Наприклад, я грав з initпроцесом, який просто робить rebootсистематичний виклик для цілей освіти.

Ядро Linux просто шукає виконуваний файл у шляху /initза замовчуванням, але це може бути замінено init=параметром командного рядка ядра Linux.

Один чудовий спосіб пограти з цим init- використовувати QEMU, оскільки ви можете передати параметри командного рядка ядра в QEMU з командного рядка QEMU за допомогою цієї -appendопції, і не побоюючись прискорити свій робочий стіл.

Ось моя мінімально повністю автоматизована програма Buildroot + QEMU, яка дозволяє дуже легко пограти своїми власними ініціами, щоб демістифікувати цю проблему.

Якщо ви прихильні до модульного принципу "зроби одну справу і зроби це добре", initпрограма повинна запустити процеси.

Запустіть процеси

Він повинен бути виконаний після того, як ядро ​​було успішно декомпресовано, доглядаючи за всіма рудиментарними завданнями, які беруть участь у ініціалізації всіх початкових процесів, необхідних для роботи системи (наприклад, монтажу приводів, знайдених у / etc / fstab, підключенні мережевих інтерфейсів та так далі).

Оскільки процес завантаження та вимкнення по суті є зворотним один одному, програма init звичайно також гарантує, що процеси зупиняються при команді відключення.

Зупинити процеси

Це означає, що він повинен зупиняти процеси відповідно до сторінки сторінки цього процесу (інакше кажучи, не просто кричущої kill -9, вона повинна зводити процес таким чином, як він хоче закінчитися), відключити накопичувачі і, нарешті, видати остаточну команду відключення живлення .

Список літератури

Хорошим посиланням на те, як це роблять інші, є перегляд сценаріїв /etc/rc.d Slackware , а також простої системи init, яка вже існує, як ninit (наступник minit). Він має нагляд за процесом (мається на увазі, що якщо процес вмирає, він знову відновлюється), що, мабуть, не є ініціальною роботою, але це все-таки досить просто і просто, щоб зрозуміти, особливо за допомогою зразків сценаріїв автора.