Библиотека сайта rus-linux.net
UNIX: руководство системного администратора. Для професcионалов
Немет Э., Снайдер Г., Сибасс С., Хейн Т.Издано: Издательский дом "Питер"
ISBN: 9665521063
Твердый переплет, 928 стр.
Отрывок
Глава 2. Запуск и останов системы
UNIX - сложная операционная система, и процедура ее включения/выключения не сводится к простому нажатию кнопки питания. Поэтому если вы хотите, чтобы система работала корректно, выполняйте операции запуска и останова по всем правилам.
Процесс начальной загрузки системы всегда казался загадочным, но он был проще в те времена, когда один производитель поставлял целиком как аппаратную, так и программную часть системы. Сейчас, когда UNIX работает на персональных компьютерах, необходимо придерживаться правил, установленных компанией Microsoft, что порождает существование многочисленных конфигураций. Несмотря на то, что мы рассматриваем особенности загрузки всех тестовых систем, вы увидите, что гораздо больше внимания уделяется системам, установленным на персональных компьютерах, чем системам, выполняющимся на оборудовании собственного поставщика.
Хотя данная глава в книге - одна из первых, в ней мы иногда оперируем понятиями, которые подробно рассматриваются лишь через несколько сотен страниц. Поэтому рекомендуем также ознакомиться с главами 5, 12 и 28. Если ваша система загружается без проблем, можно пропустить эту главу и вернуться к ней позже.
Отметим, что протекание процесса начальной загрузки зависит от типа используемого оборудования. Приведенная здесь информация верна для общего случая, однако в конкретной системе могут проявиться некоторые отличия.
2.1. Начальная загрузка
Под начальной загрузкой подразумевается самозапуск компьютера при включении питания. Поскольку средства операционной системы на данном этапе недоступны, компьютер должен в буквальном смысле "обслужить себя сам". Процесс включает загрузку системного ядра в память и его последующую активизацию. Затем выполняется ряд инициализационных задач, после чего система готова к обслуживанию пользователей.
Начальная загрузка - это период особой уязвимости в жизни системы. Ошибки в конфигурационных файлах, сбои в работе оборудования, повреждения файловых систем могут помешать компьютеру нормально начать работу. Настройка режимов загрузки во многих случаях является одной из первых задач, которую приходится решать администратору в новой системе. К несчастью, эта задача - одна из наиболее сложных, и для ее решения необходимо хорошо знать UNIX.
Когда происходит включение питания, запускается на выполнение загрузочный код, хранящийся в ПЗУ. В его обязанность входит запуск ядра. Ядро опрашивает состояние оборудования, а затем запускает системный процесс init, идентификатор которого всегда равен 1.
Прежде чем на экране появляется регистрационное приглашение, происходит целый ряд событий. Файловые системы должны быть проверены и смонтированы, а системные демоны - запущены. Соответствующие процедуры реализуются с помощью сценариев интерпретатора shell, которые один за другим запускаются процессом init. Стартовые сценарии часто называют "rc-файлами", поскольку они имеют префикс "rc". Он расшифровывается как "run command" - "команда запуска" - и является пережитком, доставшимся UNIX в наследство от операционной системы CTSS. Конкретная структура стартовых сценариев и способ их выполнения зависят от системы. Все эти вопросы будут рассмотрены в данной главе.
Автоматическая и ручная загрузка
Большинство UNIX-систем может загружаться либо в автоматическом, либо в ручном режиме. В первом случае система загружается самостоятельно, без какого-либо вмешательства извне. Во втором случае она также загружается автоматически, но до определенного момента: перед выполнением основных инициализирующих сценариев управление передается оператору (человеку, сидящему за терминалом). В это время система находится в так называемом "однопользовательском режиме". Большинство системных процессов не выполняется, и вход других пользователей в систему невозможен.
В повседневной работе почти всегда применяется автоматическая загрузка. Типичная процедура загрузки выглядит так: пользователь включает питание и ждет (ждет...), пока система перейдет в диалоговый режим. Системный администратор, однако, обязан не только понимать, как проходит процесс автоматической загрузки, но и знать, как загрузить систему вручную. Загружать систему вручную чаще всего приходится при возникновении проблем, вызывающих прерывание автоматического процесса загрузки. Это могут быть, например, повреждения файловой системы или ошибки в конфигурации сетевой платы.
Этапы загрузки
Обычно процесс начальной загрузки состоит из шести этапов:
загрузка и инициализация ядра;
распознавание и конфигурирование устройств;
запуск самовыполняющихся системных процессов;
выполнение команд оператора (только при ручной загрузке);
выполнение стартовых сценариев;
переход в многопользовательский режим.
Почти все этапы проходят без контроля со стороны администратора. Можно управлять процессом загрузки, редактируя стартовые сценарии.
Инициализация ядра
Подробно о ядре рассказывается в главе 12.
Ядро UNIX само по себе является программой, и первый этап начальной загрузки заключается в считывании этой программы в память для последующего выполнения. Имя файла ядра определяется разработчиком конкретной системы, но традиционное его название /unix или /vmunix. В настоящее время разработчики не придерживаются строго этого соглашения.
В большинстве систем загрузка ядра осуществляется в два этапа. Сначала в память машины с диска или магнитной ленты считывается (с помощью кода, записанного в ПЗУ) небольшая программа начальной загрузки, которая затем выполняет собственно загрузку ядра. Весь процесс происходит еще вне UNIX, поэтому в разных системах он реализован по-разному.
Ядро выполняет тестовые программы, позволяющие определить, сколько памяти имеется в наличии. Большинство внутренних структур ядра обладают фиксированным размером, поэтому ядро точно знает, сколько памяти нужно зарезервировать для самого себя. Эта память будет недоступной пользовательским процессам. В большинстве систем ядро выдает на консоль сообщение об общем объеме физической памяти и объеме памяти, не занятой ядром.
Конфигурация аппаратных средств
Одна из первых задач, стоящих перед ядром, - выявление компонентов аппаратного обеспечения. Создавая ядро для своей системы, вы можете указать, какие устройства оно должно проверять. Когда ядро начинает выполняться, оно пытается найти и инициализировать все устройства, о которых ему было сообщено. Большинство ядер выводят на консоль краткую информацию о каждом обнаруженном устройстве.
Информация об устройствах, задаваемая при конфигурировании ядра, зачастую является неполной. В таких случаях ядро пытается получить необходимые сведения, опрашивая системную шину на предмет наличия устройств и запрашивая нужную информацию у соответствующих драйверов. Драйверы отсутствующих или не отвечающих на контрольный сигнал устройств отключаются. Даже если позже устройство подключить к системе, оно будет недоступно для UNIX-процессов до тех пор, пока вы не перезагрузите машину.
Системные процессы
После завершения базовой инициализации ядро создает в области памяти, выделенной для процедур пользователя, несколько "самовыполняющихся" процессов. Это происходит в обход стандартного системного вызова fork (см. параграф 4.2).
Число и характер таких процессов определяются типом операционной системы. В BSD-системах создаются три процесса:
swapper (идентификатор 0);
init (идентификатор 1);
pagedaemon (идентификатор 2).
Число самовыполняющихся процессов в системах семейства System V варьируется:
sched (идентификатор 0);
init (идентификатор 1);
различные обработчики сигналов ядра.
В Linux процесс с идентификатором 0 отсутствует, а общее число самовыполняющихся процессов зависит от версии ядра:
init (идентификатор 1);
различные обработчики сигналов ядра (kflushd, kupdate, kpiod, kswapd).
Из всех упомянутых процессов только init является полноценным пользовательским процессом; остальные фактически представляют собой части ядра операционной системы, которые были преобразованы в процессы из концептуальных соображений.
После этого ядро больше не принимает участия в процедуре начальной загрузки системы. К этому моменту, однако, еще не создан ни один из процессов, управляющих базовыми операциями (например, входом пользователей в систему), и большинство демонов не запущено. Обо всех этих задачах позаботится (в некоторых случаях косвенно) процесс init.
Действия оператора (только при ручной загрузке)
Если систему нужно запустить в однопользовательском режиме, оператор указывает при запуске специальный флаг в командной строке, а ядро передает эту информацию процессу init. При загрузке в однопользовательском режиме обычно выдается приглашение ввести пароль пользователя root. Если он введен правильно, запускается командный интерпретатор с правами пользователя root. Можно не задавать пароль, а просто нажать <Ctrl-D>, после чего загрузка продолжится в многопользовательском режиме. В Red Hat командный интерпретатор запускается без ввода пароля.
Более подробная информация о привилегиях пользователя root содержится в главе 3.
В однопользовательском режиме оператор может выполнять команды почти так же, как и в многопользовательском. Однако обычно автоматически монтируется только раздел диска с корневым каталогом. Другие файловые системы оператор должен смонтировать вручную для того, чтобы использовать программы, находящиеся вне каталогов /bin, /sbin или /etc . Демоны в однопользовательском режиме не запускаются, поэтому команды, зависящие от некоторых серверных процессов (например, mail), работать не будут.
Подробнее о файловых системах и их монтировании читайте в главе 5.
Во многих однопользовательских средах корневая файловая система монтируется доступной только для чтения. Если каталог /tmp является частью корневой системы, множество программ, работающих с временными файлами (например, редактор vi), откажутся выполняться. Чтобы исправить подобную ситуацию, необходимо в самом начале однопользовательского сеанса смонтировать каталог / в режиме чтения/записи. Как это сделать, зависит от системы. В большинстве случаев достаточно выполнить команду mount /, а всю необходимую информацию команда возьмет из файла fstab или vfstab.
В Red Hat система ведет себя немного "агрессивнее" в однопользовательском режиме. К тому моменту, когда отобразится приглашение интерпретатора shell, система попытается смонтировать все локальные файловые системы. На первый взгляд, это кажется удобным, но если с какой-нибудь файловой системой что-то не в порядке, возникают проблемы.
Команда fsck, которая проверяет и восстанавливает поврежденные файловые системы, обычно выполняется в процессе автоматической загрузки. Если система запускается в однопользовательском режиме, команду fsck нужно "прогнать" вручную. Подробно данная команда описана в параграфе 8.4.
Когда интерпретатор команд, выполняющийся в однопользовательском режиме, завершит работу, система продолжит загрузку в многопользовательском режиме.
Выполнение стартовых сценариев
К тому моменту, когда система окажется готова выполнять стартовые сценарии, все "загадочные" этапы процесса загрузки будут завершены. Перед нами еще не полностью загруженная система, но это уже UNIX. Файлы сценариев, по сути, представляют собой обычные командные файлы, которые запускаются процессом init по определенному алгоритму.
Точное местонахождение, содержимое и организация стартовых сценариев заслуживают отдельного изучения (см. параграф 2.4).
Работа в многопользовательском режиме
Детальное описание процесса регистрации в системе дано в параграфе 7.8.
После выполнения инициализационных сценариев система полностью готова к работе, за одним исключением: никто не может в нее войти. Для того чтобы с конкретного терминала можно было попасть в систему, необходимо, чтобы терминал имел свой процесс getty, ожидающий поступления запросов от этого терминала . По окончании работы последнего стартового сценария процесс init порождает все необходимые процессы getty, завершая процесс загрузки. Если система сконфигурирована для работы в графическом режиме, процесс init также порождает соответствующие регистрационные процессы, такие как xdm, gdm или dtlohin.
Необходимо помнить, что процесс init продолжает играть важную роль даже после завершения начальной загрузки. В BSD-системах он имеет всего два состояния: однопользовательское и многопользовательское. В других системах у него есть один однопользовательский и несколько многопользовательских "уровней выполнения", определяющих, какие ресурсы системы будут доступны пользователю. Уровни выполнения описаны в параграфе 2.4.
2.2. Загрузка системы на персональном компьютере
До сего момента описывалась общая процедура загрузки. Теперь некоторые наиболее важные (и сложные) ее этапы необходимо рассмотреть подробно, проанализировав особенности работы каждой из тестовых операционных систем.
А начнем мы опять с этапа включения питания и загрузки ядра. На традиционном UNIX-оборудовании это простой процесс, заслуживающий лишь нескольких строк описания. Однако если система установлена на персональном компьютере, то все значительно сложнее. Нам придется дать много вводной информации, чтобы вы смогли понять суть происходящих событий.
Если вы не работаете на персональном компьютере, переходите непосредственно к параграфу 2.3.
Чем персональный компьютер отличается от фирменного оборудования
Когда компьютер загружается, начинает выполняться код, записанный в ПЗУ. Точное его местоположение и структура зависят от типа оборудования. В компьютерах, созданных специально для UNIX, код "прошивается" разработчиком, который заранее задает алгоритм подключения устройств, базовой инициализации сети и распознавания локальных файловых систем. Это очень удобно для системного администратора. Ему достаточно ввести имя нового файла ядра, а код ПЗУ автоматически обнаружит и прочитает этот файл.
На персональных компьютерах код начальной загрузки представлен в виде базовой подсистемы ввода-вывода - BIOS (Basic Input/Output System), которая чрезвычайно упрощена в сравнении с фирменным кодом UNIX-машин. В действительности в BIOS существует несколько уровней кода: один для самого компьютера, другой для видеоплаты и еще один для SCSI-адаптера, если таковой имеется.
Встроенный код BIOS знает о некоторых устройствах, расположенных на материнской плате, в частности о контроллере IDE (и жестких дисках), клавиатуре, последовательных и параллельных портах. А SCSI-адаптеры распознают только те устройства, которые подключены непосредственно к ним. Выявление конфликтов между различными уровнями BIOS может стать настоящим кошмаром. Сложнее всего понять то, как происходит выбор устройства, с которого должна быть произведена загрузка.
Процесс загрузки ПК
В современных компьютерах BIOS-программы "умнее", чем раньше. Они позволяют на этапе загрузки входить в режим конфигурирования, удерживая нажатой одну или две клавиши. Как правило, названия этих клавиш отображаются на экране, чтобы их не нужно было искать в документации.
В режиме конфигурирования можно выбрать, с какого устройства требуется производить загрузку. Как правило, это дисковод для гибких дисков, первый IDE-дисковод CD-ROM или первый жесткий диск IDE. Нам бы хотелось объяснить вам, как все работает, но, к сожалению, это невозможно, так как данная стадия процесса загрузки находится под контролем производителей персональных компьютеров и их многочисленных BIOS-программ. Они устанавливают свои собственные правила игры, которых приходится придерживаться.
Когда компьютер определил, с какого устройства следует загружаться, производится считывание первых 512-ти байтов с диска. Этот сегмент диска известен как главная загрузочная запись (ГЗЗ). В ней содержится программа, которая сообщает компьютеру о том, в каком разделе диска находится программа вторичной загрузки (загрузчик ОС). Дополнительная информация о разделах дисков на персональных компьютерах и главной загрузочной записи приводится в главе 8.
Стандартная программа ГЗЗ дает компьютеру указание извлечь загрузчика ОС из первого раздела диска. Linux и FreeBSD поддерживают более сложные программы, которые знают, как работать с несколькими операционными системами и ядрами.
Когда программа ГЗЗ находит раздел, с которого будет выполнена загрузка, она пытается запустить загрузочную программу, связанную с этим разделом. В случае успеха этой программе передаются полномочия по дальнейшей загрузке ядра.
LILO: загрузчик Linux
Загрузчик LILO невероятно сложен и в то же время ужасно бестолков. В нем поддерживается множество возможностей, отсутствующих у других загрузчиков, но нет некоторых элементарных свойств.
Загрузчик LILO входит в состав практически всех дистрибутивов Linux, включая Red Hat. При первой установке системы инсталляционные сценарии создают копию LILO со стандартными параметрами загрузки. Как-то повлиять на этот процесс нельзя. LILO не так уж необходим для загрузки Linux, но это часть системы. Придется научиться ее любить...
LILO может быть установлен в главную загрузочную запись диска или в загрузочную запись корневого раздела Linux. Конфигурирование и инсталляция загрузчика осуществляется с помощью программы lilo, которая извлекает параметры конфигурации из файла /etc/lilo.conf. Чтобы изменить настройки загрузчика, достаточно отредактировать этот файл и повторно запустить программу lilo. Эту процедуру необходимо проделывать всякий раз при изменении процесса загрузки - в частности, каждый раз, когда добавляется новый загрузочный раздел или создается новое ядро.
Конфигурирование LILO
Ниже приведено содержимое файла lilo.conf для системы, в которой имеется рабочее и резервное ядро:
boot=/dev/hda # помещаем загрузчик в ГЗЗ
root=/dev/hda1 # задаем корневой раздел
install=/boot/boot.b
map=/boot/map
delay=20 # 2-секундная задержка, дающая пользователю
возможность вмешаться
image=/vmlinuz # загружаемое ядро
label=linux # метка ядра
read-only
image=/vmlinuz-backup # резервное ядро
label=backup
read-only
Каждому возможному сценарию загрузки назначается метка. Введя метку на этапе загрузки, можно сообщить модулю LILO о том, какой из сценариев следует выбрать. Тот сценарий, который указан в файле lilo.conf первым, выбирается по умолчанию.
В стандартном сценарии (метка linux) загружается файл /vmlinuz. Флаг read-only указывает на то, что ядро монтирует свою файловую систему в режиме "только чтение". Этот флаг должен всегда присутствовать; стартовые сценарии позаботятся о том, чтобы повторно смонтировать раздел в режиме "чтение/запись", когда возникнет такая необходимость. Система сконфигурирована таким образом, чтобы в случае неудачи загрузить резервное ядро (файл /vmlinuz-backup). Подобная возможность является очень удобной.
Если запустить программу lilo без аргументов, она создаст и инсталлирует загрузчика, сообщив о том, какие ядра доступны. Рядом с названием основного ядра будет отображена звездочка. При наличии ошибок в файле lilo.conf они не будут обнаружены до тех пор, пока процедура инсталляции загрузчика не достигнет середины. Система окажется в переходном состоянии. Не перезагружайте ее, пока программа lilo не завершится успешно. Чтобы не попасть в подобную ситуацию, запускайте программу с опцией -t, которая позволяет протестировать файл, не выполняя инсталляцию. Если ошибок не выявлено, можно переходить к процедуре инсталляции. Честно говоря, непонятно, почему программа lilo не делает такую проверку автоматически.
В нашем случае результаты работы программы будут выглядеть так:
# lilo
Added linux*
Added backup
При загрузке системы модуль LILO выдаст приглашение следующего вида:
LILO:
После паузы длиной 2 секунды (параметр delay, равный 1, соответствует 1/10 секунды, а в рассматриваемом файле lilo.conf он равен 20) будет загружено ядро /vmlinuz и смонтирован первый раздел первого IDE-диска в качестве корневого раздела. Список сценариев загрузки можно просмотреть, нажав клавишу <Tab>:
LILO: <Tab>
linux backup
LILO:
Чтобы загрузить резервное ядро, введите его метку в строке приглашения.
Загрузчик FreeBSD
Модуль загрузки во FreeBSD прост и эффективен. Он разделен на две части: одна находится в главной загрузочной записи, а вторая - в корневом разделе FreeBSD. Обе части инсталлируются раздельно.
Первичный загрузчик инсталлируется с помощью команды boot0cfg. Например, команда
# boot0cfg -B /dev/wd0
помещает первую часть загрузчика в ГЗЗ первого IDE-диска системы. Здесь практически ничего не нужно менять (а чаще всего это сделать просто невозможно). В процессе загрузки модуль просматривает список доступных дисков (извлекается из BIOS) и находит разделы, которые, по его мнению, являются загрузочными. Перечень разделов отображается в виде небольшого меню:
F1 FreeBSD
F2 Windows
Default: F1
Дополнительную информацию о тонкой настройке первичного загрузчика можно получить на странице интерактивного руководства, посвященной программе boot0cfg.
Второй модуль непосредственно отвечает за загрузку FreeBSD и позволяет пользователю передать ядру дополнительные параметры. Инсталляция модуля осуществляется с помощью команды disklabel -B. Программа disklabel является достаточно мощной: она обладает множеством опций и поддерживает почти все дисковые накопители. Вот как она обычно вызывается:
# disklabel -B /dev/wd0s1
Здесь вторичный загрузчик записывается в первый раздел первого IDE-диска.
Параметры конфигурации вторичный загрузчик извлекает из следующих файлов:
/boot/loader.conf
/boot/loader.conf.local
/boot/defaults/loader.conf
Последний файл содержит стандартные установки загрузчика и не должен никогда модифицироваться. Все эти установки можно переопределить с помощью файлов loader.conf и loader.conf.local, а также из командной строки на этапе загрузки системы. Информацию о параметрах загрузчика вы можете найти на страницах руководства boot(8) и loader(8).
Мультисистемная загрузка
Поскольку на одном персональном компьютере могут работать несколько операционных систем, привычной является ситуация, когда компьютер загружается в мультисистемном режиме. Чтобы добиться этого, необходимо правильно сконфигурировать модуль загрузки, позволив ему распознать имеющиеся на локальных дисках операционные системы.
В каждом разделе диска может располагаться собственный вторичный загрузчик, однако главная загрузочная запись только одна. Поэтому необходимо решить, какой из загрузчиков будет главным. Как правило, выбор диктуется особенностями имеющихся операционных систем. Если одной из них является Linux, то лучше всего в качестве главного загрузчика выбрать LILO. Исключение составляет случай, когда присутствует Windows NT/2000. Загрузчик этой операционной системы всегда должен помещаться в ГЗЗ.
Проблемы при мультисистемной загрузке
Организация мультисистемной загрузки может быть болезненным процессом. Ниже излагается информация, которая позволит вам сберечь множество нервных клеток.
Когда на компьютере с мультисистемной загрузкой планируется установить одну из клиентских версий Windows (95, 98 или Me), это должно быть сделано до того, как будут инсталлированы остальные системы. Данные версии Windows слишком глупы и не предполагают, что на компьютере может быть установлена какая-нибудь другая ОС. Они всегда занимают первый раздел первого диска, перезаписывая в процессе инсталляции существующие программы загрузки.
Аналогичное правило применяется в отношении Windows NT/2000: Windows всегда инсталлируется первой. Причины этого могут быть разными, но результат всегда один. Загрузчик NT/2000 очень хочет инсталлировать себя в главную загрузочную запись и быть Самым Главным. Сопротивление бесполезно.
Чтобы заставить этого загрузчика распознавать разделы UNIX, необходимо предварительно инсталлировать UNIX и загрузиться с дискеты или компакт-диска. Затем нужно прочитать первые 512 байтов раздела UNIX (загрузочный сектор раздела) и записать их в файл. Это можно сделать с помощью команды dd. Вот пример ее использования в Linux:
# dd if=/dev/hda2 of=linux.bin bs=512 count=1
Далее следует скопировать этот файл в раздел NT/2000 и добавить в файл конфигурации загрузчика NT запись о том, как загружаться с использованием данного файла. Все, что для этого требуется, - поместить в файл C:\boot.ini строку с указанием пути к файлу и метки. В случае Linux эта строка будет выглядеть так:
C:\linux.bin="Linux"
Дополнительную информацию о структуре файла boot.ini можно получить в интерактивной базе знаний на Web-узле support.microsoft.com.
Если Linux и Windows NT/2000 сосуществуют вместе, загрузчик LILO должен быть инсталлирован в раздел Linux, так как главная загрузочная запись уже занята. Для этого достаточно в файле lilo.conf поместить в параметр boot ссылку на раздел Linux. Например, если ОС Linux инсталлирована на втором разделе первого IDE-диска, строка будет иметь следующий вид:
boot=/dev/hda2
Это действие должно быть проделано до того, как вторичный загрузчик будет записан в файл и скопирован в раздел NT. По сути, весь процесс должен повторяться каждый раз, когда требуется повторный запуск программы lilo.
Мультисистемное конфигурирование LILO
Если LILO является главным загрузчиком (например, на компьютере установлены системы Linux и Windows 98), начните со стандартного процесса конфигурирования LILO, описанного выше. Затем по мере необходимости можно добавлять записи для других операционных систем в файл /etc/lilo.conf.
Вот как будет выглядеть запись, предназначенная для загрузки Windows из первого раздела первого IDE-диска:
other = /dev/hda1
label = windows
table = /dev/hda
Ниже приведен полный текст файла lilo.conf для случая, когда Windows загружается из первого раздела, Linux - из второго, а FreeBSD - из третьего:
boot = /dev/hda # помещаем загрузчик в ГЗЗ первого
IDE-диска
delay = 20 # <%-4>2-секундная задержка, дающая пользователю<%0>
возможность вмешаться
default = linux # по умолчанию загружается Linux
из второго раздела
image = /boot/vmlinuz-2.3.41
root = /dev/hda2
label = linux
read-only
image = /dev/hda1 # загрузка Windows из первого раздела
label = windows
table = /dev/hda
image = /dev/hda3 # загрузка FreeBSD из третьего раздела
label = freebsd
table = /dev/hda
После модификации файла lilo.conf программа lilo должна быть вызвана повторно. Не забудьте предварительно выполнить ее в тестовом режиме с помощью опции -t.
Мультисистемное конфигурирование FreeBSD
Загрузчик FreeBSD всегда пытается автоматически обнаружить загрузочные разделы. Но можно самостоятельно сообщить ему о них, воспользовавшись опцией -m маска программы boot0cfg. Параметр маска содержит битовую маску разделов, из которых требуется загружаться. Первый раздел представляется двоичным кодом 0001 (шестнадцатеричный эквивалент - 0x1), второй раздел - кодом 0010 (эквивалент 0x2) и т.д. Например, команда
# boot0cfg -B -m 0x7
инсталлирует первичного загрузчика и сообщает ему о том, что разделы 1, 2 и 3 являются загружаемыми (0x7=0111). В процессе загрузки на экране отобразится меню с тремя элементами - по одному для каждого раздела.
2.3. Загрузка в однопользовательском режиме
В следующих параграфах описываются особенности однопользовательской загрузки в каждой из тестовых операционных систем.
Solaris
Чтобы прервать процесс загрузки и войти в ПЗУ на компьютерах Sun, нажмите одновременно клавиши <L1> и <a>. На современных клавиатурах Sun клавиша <L1> иногда обозначается как <STOP>. Перейдя в ПЗУ, введите boot -s, для того чтобы продолжить загрузку в однопользовательском режиме.
Если в системе Solaris требуется загрузить альтернативное ядро, необходимо задать полный путь к устройству и файлу. Имя устройства - это длинная загадочная строка, которую можно увидеть, выполнив команду ls -l по отношению к соответствующему файлу /dev:
% ls -l /dev/rdsk/c0t0d0s0
lrwxrwxrwx 1 root root 55 Jan 15 1998 /dev/rdsk/c0t0d0s0 ->
../../devices/sbus@1f,0/SUNW,fas@e,8800000/sd@0,0:a,raw
Чтобы загрузить ядро, хранящееся на диске в файле /kernel/backup, нужно ввести следующую команду:
boot /devices/sbus@1f,0/SUNW,fas@e,8800000/sd@0,0:a,raw/kernel/backup
В табл. 2.1 перечислен ряд полезных команд, которые можно вводить в режиме конфигурирования ПЗУ на компьютерах Sun.
Таблица 2.1. Команды конфигурирования ПЗУ для компьютеров Sun
| Команда | Выполняемое действие |
| boot /путь_к_файлу_ядра | Загрузка альтернативного ядра |
| boot -s | Загрузка в однопользовательском режиме |
| boot -r | Переконфигурирование ядра и поиск новых устройств |
| boot -a /etc/system.bak | Уведомление ядра о необходимости чтения файла /etc/system.bak, а не /etc/system |
| probe-scsi | Выдача списка подключенных SCSI-устройств |
HP-UX
Процедура однопользовательской загрузки на компьютере HP-UX зависит от типа машины. Приведенные ниже сведения относятся к компьютеру HP 9000/735.
После выдачи соответствующего сообщения прервите процесс загрузки. Появится строка приглашения. Введите boot pri isl, чтобы отобразить расширенную строку приглашения. Она будет выглядеть примерно так:
ISL> prompt:
Следующая команда выбирает требуемое ядро и загружает систему в однопользовательском режиме:
ISL> prompt: hpux -iS /stand/vmunix
Linux
Перейти в однопользовательский режим в Linux можно с помощью загрузчика LILO. В строке приглашения LILO введите метку ядра, которое требуется загрузить (задана в файле lilo.conf), а затем опцию -s или single. Например, стандартное ядро, поставляемое в составе Red Hat, имеет метку "linux", поэтому, чтобы загрузиться в однопользовательском режиме, необходимо задать такую команду:
LILO: linux single
Загрузчик LILO понимает различные опции командной строки (табл. 2.2).
Таблица 2.2. Примеры опций загрузчика LILO
| Опция | Назначение |
| root=/dev/foo | Сообщает ядру о том, что корневым является устройство /dev/foo |
| single | Задает режим однопользовательской загрузки |
| init=/sbin/init | Сообщает ядру путь к программе init |
| ether=0,0,eth1 | Заставляет ядро осуществить поиск адаптера Ethernet |
В однопользовательском режиме система Red Hat особенно чувствительна к ошибкам. Прежде чем войти в этот режим, Red Hat пытается выполнить команду fsck и смонтировать все локальные файловые системы, причем практически ни одна из системных команд не компонуется статически. Если в результате ошибок монтирования нужные библиотеки функций оказались не подключенными, динамически компонуемые команды не будут выполняться. Даже базовые команды манипулирования файлами, сетевые утилиты и текстовые редакторы требуют наличия совместно используемых библиотек функций.
По этой причине работать в однопользовательском режиме в Red Hat, в общем-то, бессмысленно. Необходимо будет всегда держать под рукой спасательную загрузочную дискету. Обычно для решения незначительных проблем удобнее загружаться в режиме подтверждения или непосредственно со спасательной дискеты.
FreeBSD
Чтобы перейти в однопользовательский режим, прежде всего выберите FreeBSD из меню первичного загрузчика:
F1 FreeBSD
Default: F1
Затем, получив соответствующее приглашение, прервите процесс загрузки и введите boot -s:
Hit [Enter] to boot immediately, or any other key for the command prompt.
Booting [kernel] in 9 seconds...
<Пробел>
Type '?' for a list of commands, 'help' for more detailed help.
disk1s1a:> boot -s
Система продолжит загрузку до того момента, когда потребуется ввести путь к командному интерпретатору. Если нажать <Enter>, будет вызван интерпретатор /bin/sh.
Вторичный загрузчик понимает различные опции командной строки. Например, чтобы найти и загрузить альтернативное ядро, выполните следующую последовательность команд:
disk1s1a:> ls
d var
d stand
d etc
...
kernel.SYNACK
kernel.LMC
kernel
...
disk1s1a:> unload
disk1s1a:> load kernel.SYNACK
disk1s1a:> boot
Здесь демонстрируется, как оператор получает список файлов корневой файловой системы, выгружает стандартное ядро (/kernel), загружает новое ядро (/kernel.SYNACK) и продолжает процесс загрузки.
2.4. Стартовые сценарии
После выхода из интерактивного режима (или при автоматической загрузке, когда завершает работу командный интерпретатор, запущенный с правами пользователя root) программа init выполняет сценарии запуска системы. Они являются сценариями интерпретатора Bourne shell (sh), а их точное местоположение и содержимое зависят от системы.
Наиболее широко распространены два способа организации работы со стартовыми сценариями, уходящие корнями в историю. В BSD-системах эти файлы хранятся в каталоге /etc и их имена начинаются с префикса "rc". В системах семейства System V файлы сценариев располагаются в каталоге /etc/init.d, а ссылки на них созданы в каталогах /etc/rc0.d, /etc/rc1.d и т.д. Второй вариант организации является более четким и позволяет аккуратнее выполнять останов системы.
Ниже приведен перечень задач, которые часто выполняются инициализационными сценариями:
задание имени компьютера;
установка часового пояса;
проверка дисков с помощью команды fsck (только в автоматическом режиме);
монтирование системных дисков;
удаление файлов из каталога /tmp;
конфигурирование сетевых плат;
запуск процессов-демонов и сетевых служб.
Большинство стартовых сценариев выводит на консоль подробную информацию о выполняемых ими задачах. Это может оказать существенную помощь при отладке или поиске причин зависания в процессе начальной загрузки.
В старых системах нередко приходилось модифицировать стартовые сценарии, чтобы настроить их для конкретной среды. Сегодня сценарии, поставляемые разработчиком системы, должны быть достаточно общими, чтобы работать в системах любой конфигурации. Сведения о локальной конфигурации системы не задаются в самом сценарии, а помещаются в отдельный файл (или набор файлов). Конфигурационные файлы, как правило, представляют собой небольшие сценарии Bourne shell, включаемые в стартовые сценарии для получения доступа к некоторым переменным командного интерпретатора.
Стартовые сценарии в системах семейства System V
Сегодня сценарии в стиле System V наиболее распространены. Они используются в трех из четырех рассматриваемых нами операционных систем. Мы в первую очередь опишем общие принципы запуска системы, а затем перейдем к анализу особенностей конкретных ОС.
В системах семейства System V программа init определяет 7 "уровней выполнения", на каждом из которых должен выполняться конкретный набор системных сервисов.
Уровень 0 говорит о том, что система полностью прекратила работу.
Уровень 1 или S означает однопользовательский режим.
Уровни 2-5 предназначены для многопользовательского режима.
Уровень 6 определяет этап перезагрузки системы.
Уровни 0 и 6 отличаются тем, что система в действительности не может в них оставаться. Переход на эти уровни означает, что система либо завершает работу, либо перезагружается. В многопользовательском режиме чаще всего установлен уровень выполнения 2 или 3; уровни 4 и 5 используются редко. Уровни 1 и S различны для каждой системы.
Однопользовательскому режиму традиционно соответствует уровень 1. На этом уровне запрещены все многопользовательские сеансы и процессы удаленной регистрации, а в системе выполняется минимальный набор программ. Поскольку в данном режиме доступ к системе осуществляется с правами пользователя root, администраторам необходимо, чтобы при загрузке в таком режиме система выдавала приглашение на ввод пароля. Для этой цели предназначен уровень S: в нем создается отдельный процесс, выдающий требуемое приглашение на экран. В Solaris уровень S является вполне самостоятельным, но в Linux он носит переходный характер и завершается сразу после ввода пароля.
Создается впечатление, что уровней выполнения больше, чем нужно. Обычно это объясняется тем, что в телефонном коммутаторе 7 уровней, поэтому в UNIX-системе должно быть как минимум столько же. В Red Hat поддерживается до 10-ти уровней, хотя уровни 7-9 не определены.
В файле /etc/inittab содержатся параметры, определяющие, что должна делать программа init на каждом из уровней. Формат файла зависит от системы, но основная идея состоит в том, что в нем задаются команды, которые должны быть выполнены (или продолжать выполняться), когда система переходит на конкретный уровень.
В процессе загрузки программа init последовательно продвигается от уровня 0 к уровню, заданному по умолчанию в файле /etc/inittab. Чтобы осуществить переход между соседними уровнями, программа init выполняет команды из этого файла. Аналогичные действия производятся в обратном порядке при останове системы.
К сожалению, структура файла /etc/inittab довольно сложна и не всегда согласуется с тем, как на самом деле происходит запуск и останов сервисов в UNIX-системах. Чтобы сделать этот файл более полезным, многие системы семейства System V реализуют дополнительный, абстрактный уровень. Он обычно представлен в виде команды, которая запускается из файла /etc/inittab и осуществляет смену уровней. На этом уровне выполняются сценарии из каталога, зависящего от целевого уровня; они переводят систему в новое состояние.
Системным администраторам обычно нет необходимости работать непосредственно с файлом /etc/inittab, так как существующие сценарии подходят для большинства случаев. Далее в главе мы не будем упоминать этот файл и все те механизмы, которые связывают программу init со стартовыми сценариями. Просто когда мы говорим о том, что программа init выполняет такой-то сценарий, нужно понимать: связь со сценарием может быть косвенной.
Основные копии стартовых сценариев хранятся в каталоге init.d. Он, в свою очередь, может располагаться в каталоге /etc, но это не всегда так. Каждый сценарий отвечает за запуск одного демона или определенной подсистемы. Сценариям можно передавать аргументы start и top, которые означают, что соответствующий сервис должен быть либо запущен, либо остановлен. Большинство сценариев понимают также аргумент restart, который эквивалентен связке stop+start. Обладая правами системного администратора, можно вручную запускать или останавливать отдельные сервисы, вызывая нужный сценарий из каталога init.d и передавая ему требуемый аргумент.
Ниже показан простой сценарий, позволяющий запускать, останавливать или перезапускать демон sshd:
#! /bin/sh
test -f /usr/local/sbin/sshd || exit 0
case "$1" in
start)
echo -n "Starting sshd: sshd"
/usr/local/sbin/sshd
echo "."
;;
stop)
echo -n "Stopping sshd: sshd"
kill `cat /var/run/sshd.pid`
echo "."
;;
restart)
echo -n "Stopping sshd: sshd"
kill `cat /var/run/sshd.pid`
echo "."
echo -n "Starting sshd: sshd"
/usr/local/sbin/sshd
echo "."
;;
*)
echo "Usage: /etc/init.d/sshd start|stop|restart"
exit 1
;;
esac
Чтобы перейти на требуемый уровень, программа init должна получить дополнительную информацию о том, какие сценарии и с какими аргументами запускать. Но она не просматривает непосредственно каталог init.d, а обращается к каталогу rcуровень.d, где уровень - это номер требуемого уровня выполнения, к которому осуществляется переход (rc0.d, rc1.d и т.д.).
В каталогах rcуровень.d обычно содержатся символические ссылки на сценарии в каталоге init.d. Имена ссылок начинаются с префикса S или K, за которым идет номер и имя сервиса, управляемого сценарием (например, S34named). Если программа init переходит к более высокому уровню, она выполняет все сценарии с префиксом S ("start" - запуск) в порядке возрастания номеров, причем каждому сценарию передается аргумент start. Когда осуществляется переход к более низкому уровню, запускаются сценарии с префиксом K ("kill" - уничтожить) в порядке убывания номеров, и всем им передается аргумент stop. В зависимости от системы, программа init может просматривать только каталог rcуровень.d, относящийся к целевому уровню, либо все каталоги на пути от исходного к целевому уровню.
Чтобы сообщить системе, когда следует запускать тот или иной демон, необходимо создать символическую ссылку в соответствующем каталоге. В большинстве систем основная часть сетевых демонов запускается на уровне 2. Следующие команды информируют систему о том, что демон sshd должен быть запущен на уровне 2 и остановлен при завершении работы системы:
# ln -s /etc/init.d/sshd /etc/rc2.d/S99ssh2
# ln -s /etc/init.d/sshd /etc/rc0.d/K25ssh2
Первая ссылка говорит о том, что сценарий /etc/init.d/sshd следует запустить в самом конце этапа перехода на уровень 2 и передать ему аргумент start. Вторая ссылка сообщает, что в процессе завершения работы системы сценарий /etc/init.d/sshd должен быть запущен относительно рано, причем с аргументом stop. В некоторых системах процессы останова и перезагрузки трактуются по-разному, поэтому необходимо также поместить символическую ссылку в каталог /etc/rc6.d, чтобы обеспечить корректный останов демона при перезагрузке системы.
Solaris
Системы Solaris, HP-UX и Red Hat используют сценарии в стиле System V, которые хранятся в каталоге init.d. В Solaris этот каталог, как и каталоги rcуровень.d, находится в каталоге /etc.
Раньше стартовые сценарии Solaris обращались к конфигурационным файлам, разбросанным по всей системе, что приводило к невообразимой путанице. В последних версиях системы компания Sun устранила большинство проблем. Стартовые сценарии теперь значительно улучшены и большей частью самодостаточны.
Некоторые конфигурационные файлы собраны в каталоге /etc/defaults (табл. 2.3), однако общее число настраиваемых параметров не так уж велико. Остальные файлы по-прежнему распределены между различными каталогами.
Таблица 2.3. Конфигурационные файлы стартовых сценариев Solaris
| Файл | Назначение |
| /etc/.UNCONFIGURED | Сообщает стартовым сценариям о необходимости полностью переконфигурировать систему (обычно используется только в процессе инсталляции) |
| /etc/hostname.интерфейс | Содержит имя узла, связанное с указанным сетевым интерфейсом (сетевой платой) |
| /etc/dhcp.интерфейс | Сообщает о том, что сетевой интерфейс должен быть сконфигурирован с помощью протокола DHCP |
| /etc/defaultrouter | Содержит имя узла и адрес стандартного шлюза |
HP-UX
В HP-UX стартовые сценарии хранятся в каталоге /sbin/init.d. Каталоги символических ссылок также находятся в каталоге /sbin. Конфигурационные файлы размещаются в каталоге /etc/rc.config.d. Их имена соответствуют именам стартовых сценариев. Например, сценарий
/sbin/init.d/SnmpMaster
извлекает конфигурационную информацию из файла
/etc/rc.config.d/SnmpMaster
и вызывается программой init с помощью таких ссылок:
/sbin/rc2.d/S560SnmpMaster
/sbin/rc1.d/K440SnmpMaster
Результаты работы стартовых сценариев сохраняются в файле /etc/rc.log. Если какой-то из сценариев не смог выполниться, просмотрите этот файл на предмет наличия сообщений об ошибках или другой информации, позволяющей выявить суть проблемы. Это настолько полезная и несложная в реализации особенность, что просто удивительно, почему поставщики других систем не догадались сделать нечто подобное.
Конфигурационные файлы могут быть сложны для понимания, хотя они снабжены хорошими комментариями. В табл. 2.4 описано назначение файлов, которые модифицируются чаще других.
Таблица 2.4. Конфигурационные файлы HP-UX (каталог /etc/rc.config.d)
| Файл(ы) | Назначение |
| SnmpMaster | Включает или отключает поддержку протокола SNMP |
| Snmp* | Другие параметры, связанные с протоколом SNMP |
| acct | Включает или отключает подсистему учета процессов; см. acct(1M) |
| auditing | Управляет работой подсистемы аудита; см. audsys(1M) и audevent(1M) |
| cde | Содержит настройки CDE (Common Desktop Environment - единая настольная среда) |
| clean* | Управляет операциями очистки, выполняемыми на этапе загрузки |
| desktop | Определяет, какой из имеющихся рабочих столов будет выбран по умолчанию |
| hpbase100conf | Конфигурирует устройства Fast Ethernet |
| hpetherconf | Конфигурирует Ethernet-платы; см. lanadmin(1M) |
| list_mode | Управляет отображением меню стартовой загрузки |
| lp | Включает или отключает подсистему буферизации печати |
| mailservs | Запускает утилиту sendmail или задает почтовый сервер |
| nameservs | Конфигурирует или запускает демон службы имен |
| nddconf | Задает параметры ядра, устанавливаемые на этапе загрузки с помощью демона ndd |
| netconf | Задает параметры конфигурации сети (IP-адрес и т.п.) |
| netdaemons | Указывает на то, какие сетевые демоны следует запустить |
| nettl | Конфигурирует подсистемы сетевой трассировки и регистрации; см. nettl(1M), nettlconf(1M) и nettlgen.conf(4) |
| nfsconf | Задает параметры NFS (Network File System - сетевая файловая система) |
| pd | Конфигурирует сервис распределенной печати HP-UX |
| vt | Запускает демон vtdaemon |
| xfs | Включает и отключает сервис шрифтов X Windows |
Для большинства этих файлов вполне подходят стандартные установки. Чаще всего модифицируются файлы netconf, netdaemons и, возможно, nddconf.
Red Hat
Стартовые сценарии - это то, что отличает дистрибутивы Linux друг от друга. Например, сценарии Debian очень напоминают сценарии Solaris, а сценарии Slackware сходны со своими "родственниками" во FreeBSD. В Red Hat используются гибридные сценарии, сочетающие в себе черты сценариев System V и FreeBSD плюс еще несколько "наворотов", добавленных только для того, чтобы сделать жизнь администраторов сложнее.
В сценариях Red Hat достаточно сложно разобраться, так как в них могут присутствовать комментарии вида
# дурацкий прием, но должен работать
или
# это неправильно!
Программа init в Red Hat в основном соответствует своему аналогу в System V. На каждом уровне выполнения программа вызывает сценарий /etc/rc.d/rc, передавая ему номер уровня в качестве аргумента. Этот сценарий может выполняться как в обычном режиме, так и в режиме подтверждения, в котором перед выполнением каждого стартового сценария выдается запрос. Управлять символическими ссылками на стартовые сценарии можно с помощью команды chkconfig.
В Red Hat имеется также сценарий rc.local, напоминающий одноименный сценарий во FreeBSD. В процессе загрузки он выполняется последним. Не стоит добавлять в него собственные команды; лучше воспользоваться средствами System V.
Вот пример сеанса загрузки в Red Hat:
[информация о ядре]
INIT: version 2.77 booting
Welcome to Red Hat Linux
Press 'I' to enter interactive startup.
Mounting proc filesystem [ OK ]
Setting clock (utc): Fri Mar 10 07:16:41 MST 2000 [ OK ]
Loading default keymap [ OK ]
Activating swap partitions [ OK ]
...
Когда появится сообщение "Welcome to Red Hat Linux", можно нажать клавишу <I>, чтобы продолжить загрузку в режиме подтверждения. Однако подтверждение о нажатии самой клавиши выдано не будет. Red Hat спокойно продолжит монтировать локальные файловые системы, активизировать разделы диска подкачки, загружать таблицы клавиш и вести поиск модулей ядра. Только после перехода на уровень 3 программа init начнет выдавать запросы:
Welcome to Red Hat Linux
Press 'I' to enter interactive startup.
Mounting proc filesystem [ OK ]
Setting clock (utc): Fri Mar 10 07:16:41 MST 2000 [ OK ]
Loading default keymap [ OK ]
Activating swap partitions [ OK ]
Setting hostname redhat.synack.net [ OK ]
Checking root filesystem
/dev/hda1: clean, 73355/191616 files, 214536/383032 blocks [ OK ]
Remounting root filesystem in read-write mode [ OK ]
Finding module dependencies [ OK ]
Checking filesystems [ OK ]
Mounting local filesystems [ OK ]
Turning on user and group quotas for local filesystems [ OK ]
Enabling swap space [ OK ]
INIT: Entering runlevel: 3
Entering interactive startup
Start service kudzu (Y)es/(N)o/(C)ontinue? [Y]
Режимы интерактивной и однопользовательской загрузки начинаются с одного и того же места. Если в процессе загрузки возникли серьезные проблемы и этой точки достичь невозможно, воспользуйтесь спасательной загрузочной дискетой.
Можно передать загрузчику LILO параметр init=/bin/sh, чтобы заставить его вызвать командный интерпретатор однопользовательского режима еще до того, как будет запущена программа init . В этом случае все действия по запуску системы придется производить вручную, включая выполнение программы fsck и монтирование локальных файловых систем.
Повлиять на процесс загрузки в Red Hat можно путем модификации конфигурационных файлов, расположенных в каталоге /etc/sysconfig. Принципы работы с ними такие же, как и с файлами в каталоге /etc/rc.config.d в HP-UX, хотя самих файлов меньше, а опций в них больше (табл. 2.5).
Таблица 2.5. Файлы и подкаталоги каталога /etc/sysconfig в Red Hat
| Файл/подкаталог | Назначение или содержимое |
| apmd | Список аргументов для демона подсистемы APM (Advanced Power Management - расширенное управление питанием) |
| clock | Задает тип системных часов (почти всегда UTC) |
| console | Загадочный каталог, который всегда пуст |
| hwconf | Включает всю информацию о системном оборудовании; используется сервисом Kudzu |
| i18n | Содержит региональные установки системы (формат представления даты/времени, язык и т.д.) |
| init | Определяет, как отображаются сообщения, поступающие от стартовых сценариев |
| keyboard | Задает тип клавиатуры (используйте идентификатор "us" для стандартной 101-клавишной клавиатуры ) |
| mouse | Задает тип мыши; используется системой X Windows и программой gpm |
| network | Задает глобальные сетевые опции (имя узла, шлюз, маршрутизация и т.д.) |
| network-scripts | Каталог, в котором содержатся вспомогательные сценарии и сетевые конфигурационные файлы |
| pcmcia | Сообщает, следует ли запускать демоны PCMCIA, и содержит необходимые опции |
| sendmail | Задает параметры для утилиты sendmail |
| Файл hwconf | просматривается сервисом Kudzu, который проверяет, было ли добавлено или удалено какое-нибудь устройство, и запрашивает у пользователя дополнительные инструкции. В промышленных системах этот сервис можно деактивировать, поскольку он сильно задерживает процесс загрузки. Каждый раз, когда обнаруживается изменение аппаратной конфигурации, возникает задержка в 30 с. |
| Каталог network-scripts | содержит вспомогательные файлы, связанные с сетевой конфигурацией. Все, что может потребоваться в нем изменить, - это файлы с именами ifcfg-интерфейс. Например, файл network-scripts/ifcfg-eth0 включает параметры платы с идентификатором eth0, в частности ее IP-адрес. О конфигурировании сетевых плат рассказывается в параграфе 13.10. |
| Файл sendmail | содержит две переменные: DAEMON и QUEUE. Если переменная DAEMON равна yes, система запустит утилиту sendmail в процессе загрузки. Переменная QUEUE информирует утилиту sendmail о том, сколько времени после возникновения ошибки сообщение должно находиться в очереди, прежде чем будет предпринята попытка повторной отправки. |
FreeBSD
Представленная ниже информация касается FreeBSD, но общие принципы организации стартовых сценариев применимы ко всем BSD-системам.
Программа init во FreeBSD выполняет только один, главный сценарий - /etc/rc. Он, в свою очередь, запускает остальные сценарии, которые расположены в каталоге /etc и носят имена вида rc.имя. Сценарии запускаются в определенном порядке, а концепция уровней выполнения не поддерживается.
Сценарий /etc/rc начинает свою работу с выполнения трех сценариев, определяющих конфигурационную информацию:
/etc/defaults/rc.conf
/etc/rc.conf
/etc/rc.conf.local
В этих файлах задаются другие каталоги, в которых необходимо искать стартовые сценарии (имена каталогов заносятся в переменную local.startup). Кроме того, в них определяется ряд переменных интерпретатора shell, используемых последующими сценариями. Сценарий /etc/rc применяет команду source (точнее, ее оригинальный псевдоним '.'), чтобы преобразовать конфигурационные и все последующие сценарии в единый поток выполнения. Эта процедура включает в себя конкатенацию файлов в один большой сценарий.
Файл /etc/defaults/rc.conf содержит огромный перечень всех конфигурационных параметров и их стандартных значений. Его нельзя редактировать. Если требуется изменить значение какой-либо переменной, просто переопределите ее в файлах /etc/rc.conf и /etc/rc.conf.local. На страницах интерактивного руководства, посвященных файлу /etc/rc, приведен исчерпывающий список переменных, которые можно менять.
Заглянув в каталог /etc, вы можете обнаружить в нем много различных сценариев:
% ls /etc/rc*
rc rc.diskless1 rc.isdn rc.pccard
rc.atm rc.diskless2 rc.local rc.resume
rc.conf rc.firewall rc.serial rc.devfs
rc.i386 rc.network rc.shutdown rc.suspend
Если ядро сконфигурировано как бездисковый клиент, в первую очередь вызывается сценарий rc.diskless1. Затем вызываются сценарии rc.sysctl, rc.serial, rc.pccard и rc.network, после чего сценарий /etc/rc переходит к выполнению служебных функций. В качестве завершающего аккорда запускается сценарий rc.local. Если какой-то сценарий не определен, он просто пропускается (в приведенном выше списке сценарий rc.sysctl отсутствует).
Стандартный сценарий rc.serial ничего не делает, а лишь определяет набор функций, которые позволяют инициализировать последовательные порты и устройства на этапе загрузки.
Если в одном из файлов rc.conf задана поддержка интерфейсов PCMCIA/CardBus, сценарий rc.pccard загружает модули ядра, связанные с контроллером PCMCIA, и запускает демон pccardd, управляющий динамическим конфигурированием устройств PCMCIA по мере их подключения и отключения.
Сценарий rc.network инициализирует сетевую среду компьютера. Он использует переменные, определенные в файлах rc.conf, для конфигурирования сетевых интерфейсов, протоколов DHCP и PPP, маршрутизаторов и брандмауэров. Редактировать этот сценарий нет необходимости, так как все параметры содержатся в файлах rc.conf. Он вызывает другие сетевые стартовые сценарии: rc.atm, rc.isdn и rc.firewall.
Для конфигурирования сетевого интерфейса во FreeBSD предназначены три переменные: hostname, defaultrouter и ifconfig_инт (где инт - имя интерфейсного устройства). Переменная ifconfig_инт должна содержать строку опций, передаваемых команде ifconfig при инициализации устройства. Например, в строках сценария
hostname="my.fullyqualified.name"
ifconfig_de0="inet 192.168.1.2 netmask 0xffffff00"
defaultrouter="192.168.1.1"
узлу назначается IP-адрес 192.168.1.2 и задается стандартный адрес шлюза 192.168.1.1. Если данное интерфейсное устройство должно конфигурироваться динамически по протоколу DHCP, задайте строку следующего вида:
ifconfig_de0="DHCP"
Сервер DHCP автоматически назначит узлу IP-адрес, доменное имя и маршрут по умолчанию.
2.5. Перезагрузка и останов системы
UNIX-системы хранят буферы изменений в памяти и лишь изредка записывают их на диск. Это ускоряет выполнение операций дискового ввода-вывода, но также делает систему более подверженной потерям данных в случае внезапных зависаний.
Раньше UNIX-системы были очень щепетильны в отношении процедуры выключения. Современные системы более терпимы, но все же по возможности лучше корректно завершать работу. Неправильное выключение системы может привести к появлению труднообнаруживаемых, неочевидных ошибок, а иногда и к полному краху.
Перезагрузка операционной системы на персональном компьютере - средство решения почти всех проблем. Но при работе в UNIX советуем сначала подумать и только потом перезагружаться. Проблемы, возникающие в этой системе, как правило, скрытые и сложные, поэтому перезагрузка дает ожидаемый результат гораздо реже, чем в других системах. Кроме того, процесс перезагрузки UNIX занимает больше времени, что создает неудобства для пользователей.
Перезагружаться необходимо в том случае, когда подключается новое устройство или работающее устройство зависает так, что его невозможно сбросить. Если модифицируется файл конфигурации, который используется только при начальной загрузке, то изменения вступят в силу лишь после перезагрузки. И наконец, если систему "заклинило" так, что в ней невозможно зарегистрироваться, иного выхода, кроме как перезагрузиться, просто не существует.
В отличие от начальной загрузки, которая осуществляется одним-единственным способом, останов и перезагрузку системы можно выполнить по-разному:
выключить питание;
дать команду shutdown;
использовать команды halt и reboot (в BSD-системах и Linux);
послать программе init сигнал TERM;
изменить уровень выполнения программы init с помощью команды telinit (в системах семейства System V);
уничтожить процесс init.
Выключение питания
Даже в небольших UNIX-системах такой способ останова неприемлем. Он может привести не только к потере данных и повреждению системных файлов. Вы рискуете испортить дисковод, если он относится к числу тех, на которых перед отключением питания необходимо установить в соответствующее положение защитный переключатель либо произвести парковку головок.
В некоторых компьютерах (например, Hewlett-Packard) присутствует кнопка программного останова, при нажатии которой выполняется ряд команд, осуществляющих корректное завершение работы системы. Если вы не уверены, поддерживает ли ваш компьютер такую возможность, не нажимайте кнопку выключения питания в процессе работы системы. Будет меньше проблем, если остановить систему вручную.
Конечно, в случае наводнения или пожара лучше отключить питание, если вы не успеваете корректно остановить систему. В машинных залах и сейчас иногда встречается аварийная кнопка, которая позволяет выключить все оборудование одновременно.
Команда shutdown: корректный способ останова системы
Команда shutdown - самый безопасный и наиболее корректный способ остановить или перезагрузить систему либо вернуться в однопользовательский режим. К сожалению, трудно найти поставщика, который бы "не приложил руку" к ее аргументам. Мы рассмотрим эту команду в общем, а затем приведем сводку синтаксиса и аргументов, которые пригодятся при работе в какой-либо из описываемых систем.
Можно дать команде shutdown указание делать паузу перед остановом системы. Во время ожидания команда посылает зарегистрированным пользователям через постепенно укорачивающиеся промежутки времени сообщения, предупреждая их о приближающемся останове. По умолчанию в сообщениях говорится о том, что система заканчивает работу, и указывается время, оставшееся до останова. При желании администратор может добавить собственное короткое сообщение, в котором поясняется, почему система останавливается и сколько примерно времени придется подождать, прежде чем пользователи вновь смогут войти в систему.
Многие версии команды shutdown позволяют задать, что конкретно должна сделать система: остановиться, перейти в однопользовательский режим или перезагрузиться. Иногда можно также указать, необходимо ли после перезагрузки проверить диски с помощью команды fsck. В современных системах с большими дисками такая проверка займет много времени, поэтому в общем случае ее можно не выполнять, если работа системы была перед этим корректно завершена. В некоторых системах этап проверки дисков автоматически пропускается, если файловые системы были правильно демонтированы.
В табл. 2.6 перечислены аргументы командной строки команды shutdown для шести рассматриваемых систем. Прочерк означает вариант по умолчанию.
Таблица 2.6. Многоликая команда shutdown
| Система | Путевое имя | Пауза | П1 | О | В | Без fsck |
| Solaris | /usr/sbin/shutdown | -gсекунды | -i6 | -i0 | -iS | - |
| HP-UX | /etc/shutdown | секунды | -r | -h | - | - |
| Red Hat | /sbin/shutdown | время | -r | -h | - | -f |
| FreeBSD | /sbin/shutdown | +минуты | -r | -h | - | - |
1 П - перезагрузка, О - останов, В - вход в однопользовательский режим.
Команда halt: более простой способ останова
Команда halt выполняет все основные операции, необходимые для останова системы. Чтобы вызвать эту команду, можно в командной строке указать shutdown -h или непосредственно halt. Команда halt регистрирует в журнальном файле событие останова, уничтожает несущественные процессы, выполняет команду sync (она, в свою очередь, осуществляет системный вызов sync), дожидается завершения операций дисковой записи, а затем прекращает работу ядра.
При указании команды halt -n системный вызов sync подавляется. Эта команда используется после восстановления корневого раздела командой fsck, чтобы ядро не могло затереть исправления старыми версиями раздела, хранящимися в кэше. Команда halt -q инициирует почти немедленный останов без синхронизации, уничтожения процессов и регистрации события. Флаг -q используется редко.
Команда reboot: быстрый перезапуск
Команда reboot почти идентична команде halt. Разница заключается в том, что система перезагружается, а не останавливается. Режим перезагрузки вызывается также командой shutdown -r. Помимо этого, команда shutdown поддерживает флаги -n и -q.
Передача программе init сигнала TERM
Результаты уничтожения программы init непредсказуемы и в большинстве случаев очень вредны. Перед тем как посылать этой программе какой-либо сигнал, обратитесь к документации. Когда BSD-версия программы init получает сигнал TERM, она обычно уничтожает все пользовательские процессы, демоны, процессы getty и переводит систему в однопользовательский режим. То же самое делает команда shutdown.
Для того чтобы послать процессу сигнал, нужно с помощью команды ps узнать идентификатор этого процесса. Программа init - это всегда процесс номер один. С целью отправки сигнала воспользуйтесь командой kill:
# sync; sync
# kill -TERM 1
Подробная информация о сигналах и команде kill приведена в главе 4.
Команда telinit: изменение уровня выполнения программы init
В системах, где программа init поддерживает несколько уровней выполнения, можно с помощью команды telinit дать программе указание перейти на конкретный уровень. Например, команда
# telinit S
переводит систему в однопользовательский режим в Solaris и HP-UX. В Red Hat необходимо указать 1, а не S, иначе будет запущен интерпретатор shell с правами пользователя root, а сам уровень изменен не будет:
# telinit 1
То же самое можно сделать с помощью команды
# shutdown -i1
которая, помимо всего прочего, может выдать предупреждающее сообщение и сделать небольшую паузу перед переходом на новый уровень.
Команда telinit наиболее полезна при проверке изменений, внесенных в файл inittab. При наличии флага -q команда заставит программу init повторно прочитать этот файл.
Уничтожение процесса init
Процесс init настолько важен для работы системы, что если его уничтожить с помощью команды kill -KILL или kill -9, то большинство систем автоматически перезагрузится (некоторые ядра при этом просто выдают сообщение о панике - фатальной ошибке). Это очень "грубый" способ перезагрузки. Лучше пользоваться командами shutdown и reboot.