Я создаю дистрибутив Linux, и теперь мне нужна программа init. Я очень хорошо умею кодировать на c и знаю немного о linux (не так много, но я использую arch linux для разработки в течение 4 лет), поэтому я подумал, что должен попробовать написать свой базовый скрипт инициализации на 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( чей код был восстановлен и доступен Уорреном Туми и др. ) Непосредственно породил 12 gettyпроцессов, смонтировал 3 встроенные файловые системы из встроенной таблицы и непосредственно запустил программу из домашнего каталога пользователь по имени mel. gettyСтол был также непосредственно в образе программы.

Еще одно десятилетие после UNIX System 5 появилась так называемая «традиционная» система инициализации Linux. В 1992 году Микель ван Смуренбург (пере) написал Linux init+ rcи связанные с ним инструменты, которые люди теперь называют «Системой 5 init», хотя на самом деле это не программное обеспечение UNIX System 5 (и не только init).

Система 5 init/ rc- не лучшее место для старта, и даже если добавить знания о systemd, которые не покрывают половину того, что нужно знать. В области проектирования систем инициализации (для Linux и BSD) было проделано много работы только за последние два десятилетия. Все виды инженерных решений были обсуждены, приняты, спроектированы, реализованы и реализованы на практике. Коммерческие Unices тоже многое сделали.

Существующие системы для изучения и изучения

Вот неполный список некоторых основных систем инициализации, отличных от этих двух, и один или два из их (нескольких) существенных моментов:

• Конец Иоахима Нильссона пошел по пути использования более удобочитаемого файла конфигурации.
• Минит Феликса фон Лейтнера был направлен на создание системы конфигурации «файловая система - база данных», небольшие объемы памяти и зависимости «старт / стоп» среди всего, что initначинается.
• Рунит Геррита Пейпа был основан на том, что я ранее описал как подход «только порождающий четыре сценария оболочки» .
• Цель InitNG - иметь зависимости, именованные цели, несколько файлов конфигурации и более гибкий синтаксис конфигурации с целой загрузкой большего количества параметров для дочерних процессов.
• upstart пошел на полную модернизацию, моделируя систему вовсе не как сервисы и взаимозависимости, а как события и задания, вызванные ими.
• Конструкция nosh включает вытеснение всего управления службами (включая даже gettyпорождение и зомби) в отдельный диспетчер служб и просто обработку специфичных для операционной системы устройств / символических ссылок / каталогов / каталогов и системных событий.
• Синит это очень простой инициат. Он выполняет /bin/rc.initчью работу - запускать программы, монтировать файловую систему и т. Д. Для этого вы можете использовать что-то вроде minirc .

Более того, около 10 лет назад среди пользователей daemontools и других пользователей обсуждалась возможность использования в 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из Daemontools, Адам Сэмпсон svscanиз Freedt , Брюс Гюнтер из Daemontools-Encoresvscan и Лоран Берко s6-svscanиз S6
• Уэйн Маршалл perpdиз Перп
• Средство управления сервисом в Solaris 10
• service-managerот Nosh

Точно так же, как объяснено в https://superuser.com/a/888936/38062 , вся /dev/initctlидея не должна быть рядом с процессом # 1. По иронии судьбы, именно высокоцентрализованный systemd демонстрирует, что его можно вывести из процесса # 1.

И наоборот, обязательные вещи для init, что люди обычно забывают в их вне-топ-оф-головки конструкции, такие вещи, как обработка SIGINT, SIGPWR, SIGWINCHи так далее отправляется из ядра и введения в действие различные запросы на изменение состояния системы , посланные из программ, которые «знают», что определенные сигналы для обработки # 1 означают определенные вещи. (Например: как объяснено на https://unix.stackexchange.com/a/196471/5132 , наборы инструментов BSD «знают», что SIGUSR1имеет особое значение.)

Существуют также разовые задачи инициализации и финализации, от которых невозможно уйти или которые они сильно пострадают, например, монтирование файловых систем «API» или очистка кеша файловой системы.

Основы работы с файловыми системами «API» мало чем отличаются от работы с init1-й редакцией UNIX: у каждого есть список информации, встроенной в программу, а у одного просто mount()все записи в списке. Вы найдете этот механизм в таких разнообразных системах, как BSD (sic!) init, Через nosh system-manager, для systemd.

«настроить систему на простую оболочку»

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

Чтобы увидеть, что у человека на самом деле нет другого выбора, кроме как выполнять программы процесса № 1, и, таким образом, выбрать правильный курс для достижения заявленной цели проектирования, лучше всего посмотреть на совпадения в работе рунита Геррита Папе, Феликса фон Минит Лейтнера и 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.
• Он будет вызывать исполняемые файлы в ответ на определенные события, такие как события power или 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, часто читают файлы конфигурации, /etc/initrcа затем разветвляют группу пользовательских процессов, основанных на этих конфигурациях, для реализации различных аспектов системы.

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

Ядро Linux просто ищет исполняемый файл по пути /initпо умолчанию, но это может быть переопределено init=параметром командной строки ядра Linux.

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

Вот моя минимальная полностью автоматизированная установка Buildroot + QEMU, которая позволяет очень легко поэкспериментировать с вашими собственными устройствами, чтобы разоблачить проблему.

Если вы привержены модульному принципу «делай одно и делай хорошо», тогда initпрограмма должна запускать процессы.

Начать процессы

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

Поскольку процесс загрузки и завершения работы по существу противоположен друг другу, для программы init характерно также гарантировать, что процессы останавливаются по команде завершения работы.

Остановить процессы

Это означает, что он должен останавливать процессы в соответствии со справочной страницей этого процесса (другими словами, не просто наглым образом kill -9, он должен сбивать процесс так, как он хочет завершиться), размонтировать диски и, в конечном итоге, выдать команду окончательного отключения питания. ,

Ссылки

Хорошая ссылка на то, как это делают другие, - это посмотреть на скрипты Slackware /etc/rc.d , а также на уже существующую простую систему инициализации, например ninit (преемник minit). Он контролирует процесс (это означает, что если процесс умирает, он перезапускается), что, возможно, не является задачей инициата, но все еще довольно простой и понятный, особенно с помощью примеров сценариев автора.