Процесс INIT — это движущая сила, которая обеспечивает работу компьютера под управлением Linux
Процесс INIT — это движущая сила, которая обеспечивает работу компьютера под управлением Linux, но она может и убить систему. Эта статья расскажет о том, что такое процесс Init, а также поможет узнать, как подчинить поведение этого процесса себе. (Да, Init — это сила, но администратор системы может управлять этой силой).
Вообще-то в UNIX слово «init» не обозначает конкретную программу, скорее всего целый класс программ. Название «init» используется для вызова первого процесса после загрузки системы, первого и единственного процесса. Когда кернел завершает проверку и настройку аппаратного обеспечения компьютера, он вызывает «init» и передает ему контроль над компьютером. С этого момента кернел обрабатывает только системные вызовы ( system calls), не заботясь более о поведении операционной системы. После того как кернел монтирует корневую файловую систему, все контролируется процессом «init».
Сейчас существует несколько способов реализации процесса «init». Вы можете использовать классическую программу Микеля ван Смаренбурга, которая поставляется с модулем SysVinit, simpleinit Питера Орбака (его можно найти среди модулей приложений util-linux), или простой шелловский скрипт (например, тот, который приведен в этой статье, правда, он обладает гораздо меньшими возможностями, чем любое приложение языка С).
Если Вы настраиваете ограниченную изолированную систему, можно выбрать любое приложение, которое будет использоваться в качестве процесса «init». Некоторые мазохисты, которым не нравится многозадачность, могут даже перенести command.com на Linux и запустить его в качестве процесса «init», хотя Вам никогда не удастся ограничить себя 640 Kb оперативной памяти, пока загружен кернел Linux.
Вне зависимости от того, какую программу Вы выбрали, доступ к ней должен осуществляться по пути /sbin/init, /etc/init или /bin/init, так как именно эти пути жестко скомпиллированы в кернел. Если ни одна из этих программ не может быть найдена и запущена на выполнение, система считается неисправной и кернел порождает шелл администратора системы, пользователя root, чтобы дать возможность исправить ситуацию (таким образом, в качестве процесса «init» используется шелл /bin/sh).
Для достижения максимальной гибкости разработчики кернела предоставили возможность выбирать другой, альтернативный путь для запуска процесса «init». Кернел воспринимает командную строку «init=» именно для этой цели. Параметры кернела могут быть переданы интерактивно во время загрузки, либо можно использовать команду «append=» в файле /etc/lilo.conf. Silo, Milo, Loadlin и другие загрузчики также позволяют передавать некоторые параметры кернелу.
Как Вы уже догадываетесь, простейший путь для получения прав доступа супервизора системы и его администратора на компьютере с ОС Linux — это напечатать строку «init=/bin/sh» в ответ на приглашение загрузчика LILO. Учтите, что это не является «прорехой» в безопасности системы, потому что настоящей угрозой безопасности системы является физический доступ к компьютеру и его системной консоли. Если Вы опасаетесь возможности ввода параметров «init=» в процессе загрузки, то сам загрузчик LILO может предотвратить возможность подобного несанкционированного управления при помощи защиты своим собственным паролем.
Задача процесса Init
Мы уже знаем, что имя «Init» не собственное, а, скорее, нарицательное, и его может использовать почти любая программа. Вопрос лишь в том, чем в самом деле должен заниматься «Init»? Будучи первым (и единственным) процессом, выполняемым кернелом, «Init» должен заботиться о запуске всех остальных процессов в системе, включая различные программы-демоны, используемые операционной системой, а также обеспечивать сеансы связи с текстовыми консолями. «Init» также должен перезапускать некоторые из своих порожденных процессов после завершения их работы. Обычно это касается всех сеансов связи через консоли. Как только Вы отключаетесь от системы, она должна вновь запустить программу getty, чтобы предоставить возможность следующего соединения. Кроме этого, «Init» заботится о мертвых процессах и отделывается от них. В соответствии с понятием процессов в UNIX, процесс не может быть удален из системной таблицы процессов, пока о его смерти не будет сообщено процессу, породившему данный процесс (или другому процессу-предку, в случае, если процесс-родитель больше не существует). В случае, если процесс прекращает работу после системного вызова exit, он остается в состоянии зомби-процесса, пока кто-нибудь не позаботится о нем. «Init», будучи предком любого другого процесса, должен собирать информацию о состоянии завершения каждого усыновленного зомби-процесса. Следует отметить, что грамотно написанная программа должна сама заботиться о всех порожденных собой процессах, зомби появляются только как следствие некорректного поведения программ. Если бы «Init» не собирал все зомби-процессы, то ленивые программисты легко и быстро исчерпали бы все системные ресурсы и компьютер с переполненной системной таблицей процессов просто завис бы.
Последняя задача «Init» — забота об отключении системы. Программа «Init» должна остановить все процессы и размонтировать все файловые системы, когда системный администратор решит, что пришло время выключать компьютер. Программа shutdown не делает ничего, она только сообщает процессу «Init», что все закончено.
Как видно, задача «Init» не так уж трудно выполнима, и простой шелловский скрипт может справиться с большинством из поставленных задач. Вспомним, что любой шелл сам прекрасно заботится о порожденных собой же процессах, так что забота об умерших потомках — не проблема для простого скрипта. Но настоящий «Init» должен заниматься контролем над поведением всей системы и выполнять его достаточно эффективно, надежно и быстро.
Использование /bin/sh в качестве минимального выбора
Как говорилось выше, шелл может использоваться в качестве программы «Init». Использование «голого»шелла (init=/bin/sh) просто открывает сеанс связи системного администратора на абсолютно несконфигурированном компьютере. Эта глава описывает, как скрипт шелла может выполнить все задачи, необходимые для работы системы в минимальной конфигурации. Этот вид упрощенной программы «Init» может использоваться в изолированных системах либо в случаях ограничения системных ресурсов, когда нужно экономить каждый бит памяти. Самым радикальным решением для изолированных систем является прямое использование конкретного приложения в качестве процесса «Init», в результате мы получим закрытую систему (без возможности взаимодействия с ее администратором, что, несомненно, вызовет проблемы), но иногда такая конфигурация удовлетворяет конкретным технологическим требованиям. Типичным примером системы Linux без реальной программы «Init» служит установочный диск с дистрибутивом операционной системы, в ней /sbin/init — это символьная ссылка на программу установки.
Листинг 1. Пример скрипта init
#!/bin/sh
# избегаем указания полного пути к именам файлов
export PATH=/usr/bin:/bin:/sbin:/usr/sbin
# монтируем корневую файловую систему только для чтения,
# и все разделы диска
mount — -n -o remount, rw /
mount -a
swapon -a
# протоколирование работы системы
syslog
klogd
# запуск сети
modprobe eth0 2 /dev/null
ifconfig eth0 192.168.0.1
route add 192.168.92.0 eth0
route add default gw 192.168.92.254
# запуск сетевых служб
inetd
sendmail -bd -q30m
# все остальное: crond, named.
# и запуск одной getty
export PATH=/usr/bin:/bin
/sbin/mingetty tty1
В Листинге 1 приведен скрипт, который может использоваться в качестве программы «Init». Скрипт этот короток и неполон, в частности, видно, что он запускает только одну программу getty, которая не может рестартовать после своего завершения. Будьте осторожны, если Вы решите использовать этот скрипт, так как каждый дистрибутив Linux использует свой собственный вид программы getty. Наберите команду: grep getty /etc/inittab, чтобы узнать, какая программа используется в вашей системе и как она называется.
В этом скрипте есть второй недостаток: он не заботится об отключении системы. Добавить поддержку отключения системы (shutdown) довольно легко, нужно просто отключить все процессы, когда завершит работу сеанс командного интерпретатора. Добавление текста, приведенного в листинге 2, выполнит этот трюк.
Листинг 2. Команды остановки всех процессов перед выключением
# убиваем все процессы, которые мы запустили
killall inetd
killall sendmail
killall klogd
killall syslogd
killall inetd
# убиваем все остальное
kill -TERM -1
sleep 2
kill -KILL -1
# освобождаем диск
swapoff -a
umount -a
mount -n -o remount, ro /
echo «The system is halted»
exit
Когда Вы загружаете систему в режиме init=/bin/sh, Вы должны по крайней мере перемонтировать корневую файловую систему перед тем, как делать что-либо еще, не забудьте также выполнить команду:
umount -a
перед нажатием ctrl-alt-del, потому что шелл не перехватывает эту комбинацию из трех клавиш.
Программа simpleinit
Модуль util-linux содержит исходники программы Init на языке С. У этой программы гораздо больше возможностей, чем у простого скрипта, и она может хорошо работать с большинством персональных компьютеров, хотя она не обладает такими широкими возможностями изменения своей конфигурации, как модуль SysVinit, поставляемый со многими дистрибутивами Linux.
Роль программы simpleinit (которая должна называться init для нормальной работы) очень похожа на роль скрипта, приведенного выше, с добавлением возможностей управления однопользовательским режимом и интерактивным вызовом сеансов связи через консоли. Также она корректно выполняет процедуру отключения системы. На программу simpleinit интересно посмотреть, она хорошо документирована, Вам, несомненно, понравится знакомство с прилагаемой документацией. Я советую обратиться к дистрибутиву модуля util-linux для получения более свежей информации. Средства программы simpleinit предельно просты, как и обещает ее название. Программа вызывает скрипт ( /etc/rc) и запрашивает файл конфигурации, чтобы определить, какой процесс должен быть перезапущен. Файл конфигурации называется /etc/inittab, аналогично файлам конфигурации других программ «init», хотя его формат и отличается от них. Если Вы планируете установить simpleinit на свой компьютер (который, скорее всего, уже содержит SysVinit), вы должны делать это очень осторожно и быть готовым к загрузке системы с аргументом кернела «init=/bin/sh» для исправления ошибок.
Продолжение следует
Алессандро РубиниLinux Journal, issue 55, November 1998, перевод Игоря Греня
Компьютерная газета. Статья была опубликована в номере 49 за 1998 год в рубрике soft :: unix
Источник
Исследуем процесс загрузки Linux
(C) В.А.Костромин, 2007
(версия файла от 03.10.2007 г.)
Этап 5: Процесс init и файл /etc/inittab
Как было показано в предыдущем разделе, если в параметре начальной загрузки «init=» не задан запуск какой-то другой программы, после монтирования корневой файловой системы в режиме «только для чтения» ядро запускает процесс init , который, как известно, является родоначальником всех других процессов в Linux. Сам по себе init в принципе ничем не отличается от других программ в системе Linux, просто это первая (и единственная) программа, которая запускается непосредственно ядром, все остальные процессы являются потомками процесса init. Файл программы init вы можете найти в каталоге /sbin среди других исполняемых файлов.
Init отвечает за продолжение процедуры загрузки, и перевод системы от начального состояния, возникающего после загрузки ядра, в стандартное состояние обработки запросов многих пользователей. Основная задача, которая стоит перед init, заключается в том, чтобы запускать в определенной последовательности другие программы в процессе загрузки системы и останавливать процессы в случае переключения уровня выполнения (в частности, при остановке системы). Init выполняет еще массу различных операций, необходимых для дальнейшей работы системы: проверку и монтирование файловых систем, запуск различных служб (демонов), запуск процедур логирования, оболочек пользователей на различных терминалах и т.д. Но, прежде чем рассматривать работу процесса init более детально, нужно сказать несколько слов о стилях загрузки и так называемых «уровнях выполнения».
5.1. Уровни выполнения
Уровни выполнения (run levels) – это просто несколько стандартных вариантов загрузки системы, каждый из которых определяет перечень действий, выполняемых процессом init , и состояние системы после загрузки, т. е. конфигурацию запущенных процессов. Уровень выполнения идентифицируется одним символом. В большинстве дистрибутивов ОС Linux используется 6 основных уровней выполнения. В следующей таблице показано, как эти уровни используются в дистрибутивах Slackware и Red Hat:
| Уровень | Slackware | Red Hat |
|---|---|---|
| 0 | остановка системы | остановка системы |
| 1 | однопользовательский режим | однопользовательский режим |
| 2 | использование не регламентировано | многопользовательский режим без NFS (то же, что и 3, если компьютер не работает с сетью) |
| 3 | многопользовательский режим | полный многопользовательский режим |
| 4 | запуск системы в графическом режиме (X11 с KDM/GDM/XDM) | использование не регламентировано |
| 5 | использование не регламентировано | запуск системы в графическом режиме |
| 6 | перезагрузка системы | перезагрузка системы; |
В некоторых дистрибутивах (например, в Debian), кроме того, используется дополнительный уровень S (или s) — примерно то же, что и однопользовательский режим, но S и s используются в основном в скриптах.
Как видите, уровни 0, 1 и 6 зарезервированы для особых случаев. Относительно того, как использовать уровни со 2 по 5, единого мнения не существует. Некоторые системные администраторы используют разные уровни для того, чтобы задать разные варианты работы, например, на одном уровне запускается графический режим, на другом работают в сети и т. д. Вы можете сами решить, как использовать разные уровни для создания разных вариантов загрузки. Но для начала проще всего воспользоваться тем способом определения разных уровней, который был задан при установке.
Уровень выполнения может быть задан как одна из опций, передаваемых ядру загрузчиком. Обычно единственной причиной, по которой уровень загрузки может быть задан как аргумент при загрузке, является необходимость запуска системы в однопользовательском режиме (уровень выполнения 1) для выполнения каких-то административных задач или в случае повреждения диска. Но если уровень выполнения не задан как опция загрузки, то init будет загружать систему на уровень, заданный в файле /etc/inittab .
Если вам нужно узнать, на каком уровне выполнения работает ваша система, то можно воспользоваться командой runlevel. Будучи запущенной без параметров, она сообщает предыдущий и текущий уровень выполнения в виде двух цифр (лучше сказать символов, потому что существуют уровни S и s), разделенных пробелом. Если уровень выполнения не изменялся, то первый символ (идентифицирующий предыдущий уровень) примет значение N.
Изменять уровень выполнения в в работающей системе можно с помощью команды telinit. Естественно, что для ее запуска нужно иметь права суперпользователя. Но об этой команде мы поговорим чуть позже, а пока давайте посмотрим что из себя представляет файл /etc/inittab .
5.2. Файл inittab
Конфигурационный файл /etc/inittab состоит из отдельных строк. Если строка начинается со знака # или пуста, то она игнорируется. Все остальные строки состоят из 4 полей, разделенных двоеточиями:
- id — идентификатор строки. Это произвольная комбинация, содержащая от 1 до 4 символов. В файле inittab не может быть двух строк с одинаковыми идентификаторами;
- runlevels — уровни выполнения, на которых эта строка будет задействована. Уровни задаются цифрами или буквами без разделителей, например, 345;
- process — процесс, который должен запускаться на указанных уровнях. Другими словами в этом поле указывается имя программы, вызываемой при переходе на указанные уровни выполнения;
- action — действие.
В поле action стоит ключевое слово, которое определяет дополнительные условия выполнения команды, заданной полем process . Допустимые значения поля action :
- respawn — перезапустить процесс в случае завершения его работы;
Кодовое слово respawn заставляет init запустить команду, которая указана в этой строке и, если вызванная программа завершает работу, запустить ее снова. Возьмем, например, следующую строку в файле inittab:
Программа getty обеспечивает открытие виртуальной консоли (в данном случае — первой) и запуск в ней программы login, выводящей приглашение ко входу пользователя в систему. Ключевое слово respawn в приведенной строке означает, что после того, как пользователь выйдет из системы, приглашение login будет выведено на первую виртуальную консоль снова.
означает, что init при переходе на 5-ый уровень запустит на выполнение команду /etc/rc.d/rc 5 и будет ожидать окончания работы этой программы прежде чем приступить к чему-либо другому.
Этот список не является исчерпывающим. Более подробно о файле inittab можно узнать из man-страниц init (8), inittab (5) и getty (8).
5.3. Стили начальной загрузки
А теперь давайте вспомним, что существует два разных стиля начальной загрузки операционной системы типа UNIX, происхождение которых уходит корями в историю развития UNIX-систем: так называемый стиль BSD (используемый также в таких системах как FreeBSD, NetBSD и OpenBSD), и стиль System V (или стиль ATT). Различие между ними проявляется в организации и размещении стартовых сценариев (скриптов), обеспечивающих управление процессами загрузки системы. В классических BSD-системах эти файлы хранятся в каталоге /etc и их имена начинаются с префикса «rc». В системах семейства System V файлы сценариев располагаются в каталоге /etc/init.d, а ссылки на них созданы в каталогах /etc/rc0.d, /etc/rc1.d и т.д. Как пишет В.Попов в статье [42] главное отличие стиля BSD от стиля System V состоит в организации скриптов rc: если в системах стиля System V вызывается один и тот скрипт rc, только ему передается параметр, задающий уровень выполнения, то для систем BSD-стиля характерно наличие отдельного скрипта для каждого из уровней выполнения. Вариант организации в стиле System V является более четким и позволяет аккуратнее выполнять останов системы. Если вы хотите подробнее узнать о различиях в двух названных стилях загрузки, прочитайте главу 2 книги [41] или статьи [42]-[45].
Большая часть дистрибутивов Linux использует на этапе загрузки стиль System V. К этому классу относятся Debian, все клоны Red Hat, включая Mandrake и российские дистрибутивы ASPlinux и ALT Linux. В стиле BSD организована загрузка в дистрибутивах Gentoo, Slackware (см. [43]-[45]) и производных последнего). Однако тот или иной стиль сценариев начальной загрузки выдерживается не очень четко. Поскольку стиль System V взят за основу при создании стандарта LSB (Linux Standart Base), дистрибутивы, ранее использовавшие стиль BSD, в последнее время заботятся о совместимости с System V. Slackware обеспечивает такую совместимость начиная с версии 7.0.
Структура каталогов, в которых хранятся инициализационные скрипты, в основных дистрибутивах существенно различается:
| Fedora (Red Hat) и Mandriva 2007 |
| Knoppix (клон Debian) |
| Slackware |
| Gentoo |
| SuSE |
Как видите, даже в Red Hat и Debian, которые следуют стилю System V, структура каталогов несколько отличается. А SuSE, хотя и происходит от Slackware, движется в сторону стиля System V, по крайней мере в организации структуры каталогов. А вот Red Hat, наоборот, завел скрипт rc.local, напоминающий одноименный сценарий во FreeBSD. В процессе загрузки он выполняется последним. Правда, в последних версиях Red Hat и Fedora Core этот скрипт «пустой», то есть практически не используется. И авторы книги [41] не советуют добавлять в него собственные команды, рекомендуя лучше воспользоваться средствами System V.
Но структура каталогов и названия инициализационных скриптов, может быть, и не самое главное. Более существенно то, что в этих скриптах содержится и как они используются. В листинге 9 приведены выдержки из файла /etc/inittab для нескольких дистрибутивов. Приводится не полный текст файла /etc/inittab, а только по 4 группы самых важных строк, определяющих процесс загрузки. Во всех дистрибутивах кроме приведенных инструкций определяются еще действия по комбинации клавиш ++ и выполняется запуск виртуальных терминалов (только в Fedora Core и SuSE для этого вызываются процессы mingetty, в Gentoo и Slackware — agetty, в Knoppix — /bin/bash -login).
| Fedora Core (Red Hat) |
| Knoppix (клон Debian) |
| Slackware |
| Gentoo |
| SuSE |
Как видите, во всех случаях порядок действий примерно одинаков:
- Вначале задается уровень выполнения (runlevel).
- Затем выполняются действия начальной инициализации системы, не зависящие от заданного уровня. В разных дистрибутивах для этого вызываются разные скрипты:
- в Fedora Core — /etc/rc.d/rc.sysinit
- в Knoppix — /etc/init.d/rcS
- в Slackware — /etc/rc.d/rc.S (то есть скрипт перехода в Single User mode):
- в Gentoo — /sbin/rc boot
- в SuSe — /etc/init.d/boot
- Затем выполняется скрипт перехода на заданный уровень выполнения. При этом, если в Fedora Core и Gentoo для каждого уровня выполнения задана своя строка, то в Slackware для уровней со 2-го по 5-ый выполняются одни и те же действия.
- Наконец, во всех дистрибутивах, кроме SuSE, отдельная строка задает процедуры запуска графической оболочки.
При использовании стиля System V используется один и тот же скрипт перехода на заданный уровень, а то, что он делает, определяется содержимым каталога /etc/rc.d/rcN.d. Этот каталог содержит перечень ссылок на скрипты запуска тех системных сервисов, которые должны работать на уровне N. Сами скрипты размещаются в каталоге /etc/init.d или /etc/rc.d/init.d.
В отличие от стиля System V в BSD-стиле каждому уровню загрузки соответствует свой сценарий. И сначала всегда происходит переход на уровень S (однопользовательский), а затем уже переход на заданный уровень. Стиль BSD в наиболее чистом виде (из рассматриваемых примеров) представлен в дистрибутиве Slackware.
Поскольку стиль System V взят за основу при создании стандарта LSB (Linux Standart Base), дистрибутивы, ранее использовавшие стиль BSD, в последнее время заботятся о совместимости с System V. Slackware обеспечивает такую совместимость начиная с версии 7.0. Достигается это путем использования сценария rc.sysinit, который производит поиск всех сценариев стиля System V в каталоге /etc/rc.d и выполнит их, если уровень загрузки соответствующий. Это полезно, если вы пользуетесь коммерческим программным обеспечением, которое ориентируется на стиль System V. В то же время, вы можете пользоваться и BSD сценариями.
Можно по-разному оценивать, какой из вариантов организации инициализационных скритпов лучше или хуже. Я считаю, что скорее всего тут просто дело привычки. Но сошлюсь на мнение авторов книги [42], которые высказали следующие мнения о скриптах трех наиболее распространенных дистрибутивов:
- «В сценариях Red Hat непросто разобраться.»
- «Сценарии запуска системы — это та область, в которой SUSE превосходит другие дистрибутивы Linux. Эти сценарии четко организованы, надежны и хорошо документированы.»
- «Сценарии Debian ненадежны, недокументированы и невероятно противоречивы. Печально, но отсутствие стандартных правил организации сценариев запуска привело в данном случае к хаосу.»
Как бы то ни было, разобраться в сценариях запуска возможно, что мы и попытаемся сделать в следующем разделе. А пока рассмотрим в целом, какие задачи выполняет процесс init.
5.4. Действия, выполняемые процессом init
Для примера возьмем файл inittab из дистрибутива ASP Linux 11, то есть будет рассматриваться процедура начальной загрузки в стиле System V.
Листинг 10. Файл /etc/inittab системы ASP Linux 11.
Обработка файла /etc/inittab процессом init начинается в однопользовательском режиме (уровень 1), в котором единственным пользователем является root, работающий с консоли. Первым делом init находит строку, которая определяет, какой уровень выполнения запускается по умолчанию:
Это и будет тот уровень, в котором запустится и будет работать система после загрузки, поэтому естественно, что нельзя указывать в строке initdefault уровни 0 и 6.
Далее init выполняет команды, указанные в строке с ключевым словом sysinit . В нашем примере здесь выполняется скрипт rc.sysinit из каталога /etc/rc.d:
После этого процесс init просматривает файл /etc/inittab и выполняет скрипты, соответствующие однопользовательскому уровню (1 во втором поле строки):
всем уровням (строки с пустым вторым полем):
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
pf::powerfail:/sbin/shutdown -f -h +2 «Power Failure; System Shutting Down»
и уровню, заданному по умолчанию:
pr:12345:powerokwait:/sbin/shutdown -c «Power Restored; Shutdown Cancelled»
Как видим, вначале вызывается скрипт rc из каталога /etc/rc.d. Какой бы уровень выполнения не был задан, вызывается один и тот скрипт, только в зависимости от уровня выполнения ему передается соответствующее значение параметра вызова, так что, например, для 3-го уровня вызов скрипта осуществляется с параметром 3.
Следующая важная функция, которую выполняет этот процесс (на уровнях со 2 по 5) — запуск шести виртуальных консолей (процессов getty), чтобы предоставить пользователям возможность регистрироваться в системе с терминалов. В нашем примере запускается только 3 виртуальных консоли, поскольку еще 3 строки в файле /etc/inittab закомментированы (я сделал это в целях экономии системных ресурсов, мне вполне хватает трех консолей).
Функции, выполняемые скриптами rc.sysinit и rc, а также процесс запуска виртуальных консолей мы подробнее рассмотрим ниже, а сейчас вернемся к краткому обзору действий процесса init .
После завершения загрузки init продолжает работать в фоновом режиме, отслеживая изменения в состоянии системы. Например, если будет подана команда telinit , позволяющая изменить уровень выполнения, процесс init обеспечит выполнение команд, заданных для нового уровня файлом /etc/inittab. Этот файл прочитывается заново и в случае поступления сигнала HUP; эта особенность избавляет от необходимости перезагружать систему для того, чтобы сделать изменения в начальной конфигурации.
Таким образом, процесс начальной загрузки init постоянно находится в оперативной памяти и при получении соответствующих сигналов повторно выполняет цикл чтения из файла /etc/inittab инструкций о том, что нужно делать, причем этот набор инструкций различен для разных уровней выполнения.
Когда суперпользователь останавливает систему (командой shutdown ), именно init завершает все другие исполняющиеся процессы, размонтирует все файловые системы и останавливает процессор.
К вопросу о том, что делает процесс init после завершения процесса загрузки системы, нам, видимо, еще придется вернуться, а пока обратимся к разбору инициализационных скриптов.
Если вы некорректно модифицируете файл /etc/inittab, система может перестать загружаться. Так что перед внесением каких-либо изменений в этот файл по меньшей мере запаситесь загрузочной дискетой и сохраните копию исходного файла на случай фатальных ошибок.
Источник
