Любая строка файла inittab, которая начинается символом решетки (#), является комментарием. Разумное число комментариев не повредит, поскольку синтаксис строк файла inittab весьма насыщенный и загадочный. Запись inittab имеет следующий формат:

метка:уровень:действие:процесс

Моле метка имеет длину от одного до четырех символов и идентифицирует строку. Отдельные системы поддерживают только двухсимвольные метки, поэтому в большинстве случаев их длина ограничена двумя символами. Метки могут быть произвольной строкой; они не имеют специального значения. Поле уровень определяет уровни исполнения, для которых действует эта запись. Если поле содержит цифру 3, процесс, на который указывает запись, должен быть запущен при инициализации системы по уровню исполнения 3.

Можно указывать несколько уровней одновременно. Записи с пустым полем уровня не участвуют в инициализации конкретных уровней. Например, в системах Linux существует запись inittab, связанная с обработкой комбинации из трех пальцев (<Ctrl>+<Alt>+<Del>); она имеет пустое поле уровня. Поле действие определяет условия, при которых выполняется процесс. В табл. 5.1 перечислены значения действий, существующие в системах Red Hat, Mandrake и Caldera Linux.

Таблица 5.1. Значения действий для inittab в Linux

И последнее поле записи - процесс. Оно указывает процесс, запускаемый init. Процесс имеет формат команды, выполняемой в командной строке. Таким образом, поле процесса начинается с имени программы, которую следует выполнить. За именем следуют аргументы, передаваемые процессу. Например, /sbin/shutdown -t3 - г now, процесс, выполняемый отдельными систе- мами Linux по сочетанию клавиш <Ctrl>+<Alt>+<Del>, - это команда, которую можно набрать в командной строке интерпретатора с целью перезагрузки системы. В большинстве записей inittab поле процесса содер жит имя стартового сценария. Существует два главных типа загрузочных сценариев: сценарии инициализации системы и сценарии инициализации уровней исполнения. В приведенном ниже фрагменте файла inittab системы Red Hat Linux отражены оба типа:

# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit
10:0:wait:/etc/rc.d/rc 0
11:1:wait:/etc/rc.d/rc 1
12:2:wait:/etc/rc.d/rc 2
13:3:wait:/etc/rc.d/rc 3
14:4:wait:/etc/rc.d/rc 4
15:5:wait:/etc/rc.d/rc 5
16:6:wait:/etc/rc.d/rc 6

Эти семь строк - сердцевина файла inittab, они вызывают загрузочные сценарии. Первая строка предписывает init выполнить загрузочный сценарий /etc/rc.d/rc.sysinit для инициализации системы. В этой записи отсутствует значение уровня исполнения. Сценарий выполняется при каждой загрузке системы. Сценарий инициализации системы выполняет ряд важных задач. Так, сценарий rc.sysinit системы Red Hat:

• инициализирует пространство подкачки;
• выполняет проверку файловой системы;
• монтирует файловую систему /ргос;
• монтирует корневую файловую систему в режиме чтения-записи после завершения работы fsck;
• загружает модули ядра.

Сценарии инициализации других систем могут выглядеть иначе, чем в Red Hat, но они решают очень похожие задачи. Например, процесс инициализации в системе Caldera начинается с загрузки модулей ядра. Затем происходит активизация пространства подкачки, проверка файловой системы и перемонтирование корневой файловой системы в режиме чтения-записи. Порядок иной, но основная функциональность не изменилась.

Выполнив сценарий инициализации системы, ini t вызывает сценарий для конкретного уровня исполнения. Остальные шесть строк примера используются для вызова загрузочных сценариев отдельных уровней. За исключением поля уровня исполнения, все эти строки идентичны.

Для примера рассмотрим строку с меткой 13. Данная строка запускает все процессы и службы, необходимые для полноценного многопользовательского режима. Уровень исполнения системы-3. Действие wait предписывает программе ini t ожидать завершения загрузочного сценария, прежде чем переходить к прочим записям файла inittab, относящимся к уровню 3. ini t выполняет сценарий /etc/rc.d/rc и передает ему аргумент командной строки - 3.

Управляющий сценарий, /etc/rc.d/rc, в свою очередь вызывает все сценарии, соответствующие уровню исполнения, то есть все сценарии из каталога /etc/rcn.d, где n - указанный уровень. В нашем примере управляющий сценарий гс получает значение 3, а потому выполняет сценарии из каталога /etc/rc.d/rc3.d. Просмотр каталога системы Red Hat показывает, что сценариев много:

$ Is /etc/rc.d
init.d rcO.d rc2.d rc4.d rc6.d rc.sysinit
rc rcl.d rc3.d rc5.d rc.local
$ Is /etc/rc.d/rc3.d
КОЗ rhnsd  K35smb  K74ntpd  S05kudzu  S25netfs  S85httpd 
K16rarpd  K45arpwatch  K74ypserv  S06reconfig  S26apmd  S90crond 
K20nfs  K45named  K74ypxfrd  S08ipchains  S28autofs  S90xfs 
K20rstatd  K50snmpd  K75gated  S09isdn  S40atd  S95anacron 
K20rusersd  K50tux  K84bgpd  SlOnetwork  S55sshd  S991inuxconf 
K20rwalld  K55routed  K84ospf6d  S12syslog  S56rawdevices  S991ocal 
K20rwhod  K61ldap  K84ospfd  S13portmap  S56xinetd 
K28amd  K65identd  K84ripd  S14nfslock  S601pd 
K34yppasswdd  K73ypbind  K84ripngd  S17keytable  S80sendmail 
K35dhcpd  K74nscd  K85zebra  S20random  S85gpm

Сценарии, имена которых начинаются с буквы К, используются для завершения процессов при завершении определенного уровня исполнения. В приведенном примере К-сценарии будут использованы в процессе завершения работы на уровне 3. Сценарии, имена которых начинаются с буквы S, используются при переходе на уровень 3. Однако ни один из файлов, хранимых в rc3.d, не является в действительности сценарием.

Это логические ссылки на настоящие сценарии, расположенные в каталоге /etc/гсЛ/init.d. Так, S80sendma.il - ссылка на файл init.d/sendmail. Сразу возникает вопрос - зачем выполнять сценарии из каталога rc3.d, когда можно вызвать их напрямую из init.d, где они на самом деле хранятся? Причины очень просты. Одни и те же сценарии используются в работе нескольких уровней. Логические ссылки позволяют хранить сценарии в одном месте и использовать их из каталога каждого конкретного уровня исполнения.

Сценарии исполняются в алфавитном порядке. SlOnetwork исполняется раньше, чем S80sendmail. Таким образом, можно контролировать порядок выполнения сценариев, изменяя их имена. Порядок вызова сценариев может быть различным для различных уровней исполнения, при том, что действительные сценарии в каталоге init.d будут по-прежнему иметь простые, осмысленные имена. Что и доказывает содержимое каталога init.d:

$ Is /etc/rc.d/init.d 
amd  functions  kdcrotate  network  rarpd  rwalld  xfs 
anacron  gated  keytable  nfs  rawdevices  rwhod  xinetd 
apmd  9 pr o  killal l  nfslock  reconfig  sendmail  ypbind 
arpwatch  halt  kudzu  nscd  rhnsd  single  yppasswdd 
atd  httpd  ldap  ntpd  ripd  smb  ypserv 
autofs  identd  linuxconf  ospf6d  ripngd  snmpd  ypxfrd 
bgpd  ipchains  lpd  ospfd  routed  sshd  zebra 
crond  iptables  named  portmap  rstatd  syslog 
dhcpd  isdn  netfs  random  rusersd  tux

Можно разместить специальную команду настройки прямо в соответствующем сценарии из каталога init.d. Более приемлемый вариант для системы Red Hat - размещать все подобные команды в сценарии гс .local.

Подобно системам BSD, системы Linux для внесения локальных изменений предоставляют файл rc.local. Общее правило: не вносите поправки в загрузочные сценарии. Исключением из этого правила является файл rc.local, расположенный в каталоге /etc/rc.d. Это единственный стартовый файл, подлежащий правке, он зарезервирован для этой цели и может иметь любое содержание. После выполнения сценария инициализации системы сценарии уровней работы вызываются в алфавитном порядке. Последним из них является S99local, ссылка на rc.local.

Поскольку сценарий rc.local вызывается в последнюю очередь, определенные в нем значения замещают встреченные системой ранее.

В системе Solaris также применяется модель загрузки System V, но дела обстоят несколько сложнее, чем в Linux. Во-первых, отсутствует сценарий rc.local. Чтобы воспользоваться таким сценарием, следует создать соответствующие файлы в каталогах уровней исполнения. Во-вторых, в системе Solaris не так много логических ссылок в каталогах уровней. Как следствие, отсутствует возможность централизованно изменять сценарии, задействованные на всех уровнях работы. Кроме того, каждому уровню исполнения соответствует отдельный управляющий сценарий, что может вносить различия в стартовый процесс уровней. Например, сценарий /sbin/rc2 управляет уровнем работы 2, а /sbin/гсЗ - управляющий сценарий для уровня 3. Все эти отличия делают процесс загрузки Solaris более сложным для анализа.

В системе Solaris 8 уровень исполнения 3 является уровнем по умолчанию для многопользовательской среды с доступом к сетевым службам. Управляющий сценарий /sbin/гсЗ выполняет сценарии из каталога /etc/rc2.d, а затем сценарии из каталога /etc/rc3.d. Базовая настройка сети происходит в /etc/rc2.d и реализована сценариями S69inet и S72inetsvc. Запуск сетевых служб выполняется рядом других сценариев, расположенных в каталогах /etc/rc2.d и /etc/rc3.d.

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

Разумеется, не все сетевые службы запускаются загрузочными сценариями. Большинство служб начинают работу по требованию. Наиболее распространенным инструментом для вызова сетевых служб по требованию является inetd, демон Интернета.