Внутреннее устройство Linux

Изменение последовательности загрузки системы

Изменение последовательности запуска системы в команде System V init обычно выполняется с помощью изменения фермы ссылок. Самое распространенное изменение — запрет работы какой-либо команды из каталога init.d на определенном уровне запуска. Следует внимательно относиться к тому, как это осуществлено. Например, вы могли бы решить удалить символическую ссылку из соответствующего каталога rc*.d. Но будьте осторожны: если вам когда-нибудь понадобится вернуть эту ссылку обратно, у вас могут возникнуть трудности при указании точного имени ссылки. Одним из лучших способов является добавление символа подчеркивания (_) в начало имени ссылки, например так:

# mv S99httpd _S99httpd

Это приводит к тому, что команда rc игнорирует файл _S99httpd, поскольку его имя не начинается с символа S или K, однако при этом исходное имя по-прежнему очевидно.

Чтобы добавить службу, создайте сценарий, подобный тем, которые находятся в каталоге init.d, а затем создайте символическую ссылку в правильном каталоге rc*.d. Проще всего это выполнить с помощью копирования и изменения одного из сценариев, который вы понимаете (в главе 11 содержится дополнительная информация о сценариях оболочки).

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

6.6.3. Утилита run-parts

Механизм, который команда System V init использует для запуска сценариев из каталога init.d, находит себе применение в различных версиях Linux, вне зависимости от того, используют ли они команду System V init. Это утилита run-parts, единственной ее задачей является запуск подборки исполняемых команд из указанного каталога в некотором предсказуемом порядке. Можно представлять себе эту команду как исполнителя, запускающего для некоторого каталога команду ls, а затем просто выполняющего все команды, которые видит в результатах вывода.

По умолчанию запускаются все команды из каталога, однако зачастую у вас есть возможность выбрать определенные команды и игнорировать остальные. В некоторых версиях системы у вас не будет большого контроля над работающими программами. Например, Fedora поставляется с очень простым вариантом утилиты run-parts.

Другие версии, такие как Debian и Ubuntu, располагают более сложной командой run-parts. Их функции содержат возможность запуска команд на основе регулярных выражений (например, используя выражение S[0–9]{2} для запуска всех сценариев «запуск» из каталога уровня запуска /etc/init.d), а также для передачи аргументов командам. Такие возможности позволяют вам запускать и останавливать уровни запуска System V с помощью единственной команды.

Нет необходимости разбираться в деталях использования утилиты run-parts; многие даже и не знают о ее существовании. Главное — помнить о том, что она время от времени возникает в сценариях и служит только для того, чтобы запускать команды из указанного каталога.

6.6.4. Управление командой System V init

Иногда вам может понадобиться слегка «подтолкнуть» команду init, чтобы она переключила уровень запуска, заново считала свою конфигурацию или выключила систему. Для управления командой System V init используйте команду telinit. Например, для переключения на уровень запуска 3 введите:

# telinit 3

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

Когда необходимо добавить или удалить задания, а также выполнить какие-либо изменения в файле inittab, следует сообщить команде init о таком изменении и побудить ее к перезагрузке этого файла. Для этого используется следующая команда:

# telinit q

Можно также применять команду telinit s для переключения в режим одиночного пользователя (см. раздел 6.9).

6.7. Выключение системы

Команда init управляет выключением и перезапуском системы. Команды для выключения системы одни и те же, вне зависимости от используемого варианта команды init. Корректный способ выключения компьютера с Linux заключается в применении команды shutdown.

Существуют два основных способа использования команды shutdown. При останове системы она выключает компьютер и оставляет его в выключенном состоянии. Чтобы немедленно остановить компьютер, запустите следующую команду:

# shutdown — h now

На большинстве компьютеров и во многих версиях Linux при останове прекращается подача электропитания. Можно также выполнить перезагрузку компьютера. Для перезагрузки используйте флаг — r вместо — h.

Процесс выключения занимает несколько секунд. Никогда не выполняйте сброс или отключение питания на этой стадии.

В приведенном примере параметр now задает время выключения. Данный параметр является обязательным, есть много способов указать это время. Если, например, вы желаете, чтобы компьютер был выключен через определенный промежуток времени, можно использовать параметр +n, где число n задает количество минут, которое должна подождать команда shutdown, прежде чем выполнить свою работу. Другие параметры можно увидеть на странице руководства shutdown(8).

Чтобы перезагрузить систему через 10 минут, введите такую команду:

# shutdown — r +10

В Linux команда shutdown уведомляет пользователя о том, что компьютер будет выключен, но реальной работы она выполняет немного. Если вы укажете время, отличающееся от now, команда shutdown создаст файл с именем /etc/nologin. Когда такой файл присутствует, система не позволяет выполнить вход никому, кроме пользователя superuser.

Когда наступает момент выключения системы, команда shutdown дает знать команде init о начале процесса выключения. В версии systemd это означает активизацию модулей выключения; в версии Upstart — порождение событий выключения; а в версии System V init — изменение уровня запуска с 0 на 6. Вне зависимости от реализации команды init или ее конфигурации процедура обычно проходит следующим образом.

1. Команда init просит каждый процесс корректно завершиться.

2. Если какой-либо процесс не отвечает через некоторое время, команда init прерывает его, попробовав сначала сигнал TERM.

3. Если сигнал TERM не сработал, команда init использует сигнал KILL для всех затянувшихся процессов.

4. Система блокирует системные файлы на своих местах и выполняет другую подготовку к выключению.

5. Система демонтирует все файловые системы, кроме корневой.

6. Система заново монтирует корневую файловую систему в режиме «только чтение».

7. Система записывает все буферизованные данные в файловую систему с помощью команды sync.

8. На последнем шаге она дает указание ядру о перезагрузке или останове с помощью системного вызова reboot(2). Это может быть выполнено с помощью команды init или какой-либо вспомогательной команды вроде reboot, halt или poweroff.

Команды reboot и halt ведут себя по-разному, в зависимости от того, как они вызваны. По умолчанию эти команды вызывают команду shutdown с параметром — r или — h. Однако если система уже находится на уровне запуска, который соответствует останову или перезагрузке, эти команды приказывают ядру немедленно отключиться. Если вам действительно необходимо спешно выключить компьютер, несмотря на возможные повреждения в результате неорганизованного выключения, используйте параметр — f.

6.8. Начальная файловая система оперативной памяти

Несмотря на то что процесс загрузки системы Linux довольно прост, один компонент постоянно приводит в замешательство: initramfs, или начальная файловая система оперативной памяти. Представьте его в виде маленького вставного пространства пользователя, которое появляется перед запуском нормального пользовательского режима. Но сначала поговорим о том, для чего оно существует.

Проблема заключается в доступности различных типов аппаратных средств для хранения данных. Как вы помните, ядро системы Linux не взаимодействует с интерфейсами BIOS или EFI для получения данных с дисков, поэтому для монтирования корневой файловой системы ему нужны драйверы, поддерживающие механизм хранения, заложенный в основу системы. Если, например, корневая файловая система расположена на дисковом массиве RAID, подключенном к контроллеру от стороннего разработчика, то ядру в первую очередь понадобится драйвер для такого контроллера. К сожалению, существует такое множество драйверов для контроллеров устройств хранения данных, что в ядро системы невозможно включить их все, поэтому многие драйверы поставляются в качестве загружаемых модулей. Однако загружаемые модули являются файлами, и, если у ядра не будет смонтированной в первую очередь файловой системы, оно не сможет загрузить необходимые модули драйверов.

Обходной путь заключается в объединении небольшой подборки модулей драйверов для ядра, а также некоторого количества других утилит в виде архива. Загрузчик системы загружает этот архив в память перед запуском ядра. Во время запуска ядро считывает содержимое архива во временную файловую систему оперативной памяти (initramfs), монтирует ее в корневой каталог и в пользовательском режиме выполняет передачу управления команде init в файловой системе initramfs. Затем включенные в состав initramfs утилиты позволяют ядру загрузить необходимые модули драйверов для реальной корневой файловой системы. Наконец, утилиты монтируют реальную корневую файловую систему и запускают настоящую команду init.

Реализации этого процесса различны и более сложны. В некоторых версиях команда init в файловой системе initramfs — это всего лишь простой сценарий оболочки, который запускает демон udevd для загрузки драйверов, а затем монтирует реальный корневой каталог и выполняет в нем команду init. В версиях, использующих вариант systemd, как правило, можно увидеть полноценную сборку systemd, которая не использует файлы конфигурации модулей и содержит совсем немного файлов конфигурации демона udevd.

Одной из основных характеристик начальной файловой системы оперативной памяти, которая (пока) остается неизменной, является возможность обойти ее, если она вам не нужна. То есть, если ядро содержит все необходимые для монтирования корневой файловой системы драйверы, вы можете изъять начальную файловую систему оперативной памяти из конфигурации загрузчика системы. Если это удается сделать, время загрузки системы сокращается, как правило, на несколько секунд. Попробуйте выполнить это самостоятельно во время загрузки системы, использовав редактор меню загрузчика GRUB для удаления строки initrd. Лучше не экспериментировать с изменениями файла конфигурации загрузчика GRUB, поскольку можно совершить ошибку, которую будет трудно исправить. С недавних пор обойти начальную файловую систему оперативной памяти стало труднее, поскольку такие функции, как монтирование по идентификатору UUID, могут быть недоступны для обобщенных версий ядра.

Содержимое начальной файловой системы оперативной памяти легко увидеть, поскольку в большинстве современных систем это всего лишь архивы cpio (см. страницу руководства cpio(1)), сжатые с помощью утилиты gzip. Сначала отыщите файл архива, заглянув в конфигурацию загрузчика системы (используйте, например, команду grep для поиска строк initrd в файле конфигурации grub.cfg). Затем примените команду cpio, чтобы выгрузить содержимое архива в какой-либо временный каталог и исследовать результаты. Например:

$ mkdir /tmp/myinitrd

$ cd /tmp/myinitrd

$ zcat /boot/initrd.img-3.2.0-34 | cpio — i — no-absolute-filenames

— snip—

Особый интерес представляет «опорная точка» почти в самом конце процесса init для начальной файловой системы оперативной памяти. Этот участок отвечает за удаление содержимого временной файловой системы (чтобы освободить пространство) и окончательное переключение на реальную корневую файловую систему.

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

Наиболее распространенными являются утилиты dracut и mkinitramfs.

примечание

Термин начальная файловая система оперативной памяти (initramfs) относится к такой реализации, которая использует архив cpio в качестве источника для временной файловой системы. Существует устаревшая версия под названием «начальный диск оперативной памяти», или initrd, которая применяет образ диска в качестве основы для временной файловой системы. Этот вариант выходит из употребления, поскольку гораздо проще работать с архивом cpio. Тем не менее вам часто будет встречаться термин initrd применительно к начальной файловой системе оперативной памяти на основе архива cpio. Зачастую (как в приведенном примере) имена файлов и файлы конфигурации по-прежнему содержат слово initrd.

6.9. Аварийная загрузка системы и режим одиночного пользователя

Когда в системе происходит что-то неладное, первым средством помощи обычно является загрузка системы с использованием «живого» образа дистрибутива (в большинстве версий образ дистрибутива играет также вторую роль «живого» образа) или выделенного аварийного образа, такого как SystemRescueCd, который можно разместить на сменном носителе. Обычные действия по восстановлению системы заключаются в следующем:

• проверка файловых систем после сбоя;

• переустановка забытого пароля для корневого пользователя;

• устранение ошибок в важных файлах, таких как /etc/fstab и /etc/passwd;

• восстановление с помощью резервных копий после сбоя системы.

Еще одним вариантом быстрой загрузки до рабочего состояния является режим одиночного пользователя. Идея заключается в том, что система быстро загружается до корневой оболочки вместо тщательного запуска всех служб. В версии System V init режиму одиночного пользователя обычно соответствует уровень запуска 1; можно также указать этот режим загрузчику системы с помощью флага — s. Чтобы войти в режим одиночного пользователя, вам может потребоваться ввести пароль корневого пользователя.

Самой большой проблемой режима одиночного пользователя является то, что он не слишком комфортен для работы. Почти наверняка не будет доступна сеть (а если и будет, то воспользоваться ею сложно), графический интерфейс пользователя будет отключен, и даже терминал может работать некорректно. По этой причине практически всегда предпочтительнее использовать «живые» образы.

7. Конфигурация системы: журнал, системное время, пакетные задания и пользователи

Когда вы в первый раз заглянете в каталог /etc, вы испытаете потрясение. Практически все файлы в определенной степени влияют на работу системы, а часть из них являются фундаментальными.

Основной материал этой главы охватывает те части системы, которые делают доступной инфраструктуру, описанную в главе 4, для инструментов уровня пользователя, рассмотренных в главе 2. В частности, мы будем исследовать следующее:

• конфигурационные файлы, к которым обращаются системные библиотеки для получения информации о сервере и пользователе;

• серверные приложения (иногда называемые демонами), запускающиеся при загрузке системы;

• конфигурационные утилиты, которые можно использовать для изменения настроек серверных приложений и файлов конфигурации;

• утилиты администрирования.

Как и в предыдущих главах, здесь практически нет материала о сети, поскольку сеть является отдельным «строительным блоком» системы. В главе 9 вы увидите, куда встраивается сеть.

7.1. Структура каталога /etc

Большинство файлов конфигурации Linux располагается в каталоге /etc. Исторически сложилось так, что для каждого приложения здесь один или несколько файлов конфигурации, а поскольку пакетов программ в системе Unix довольно много, каталог /etc быстро наполняется файлами.

Такой подход сталкивается с двумя проблемами: в работающей системе сложно найти конкретные файлы конфигурации и выполнять обслуживание системы, сконфигурированной подобным образом. Если, например, вы желаете изменить конфигурацию системного журнала, необходимо отредактировать файл /etc/syslog.conf. Однако после этого, когда произойдет обновление системы, ваши пользовательские настройки могут быть утрачены.

Основной тенденцией последних лет является размещение файлов системной конфигурации в подкаталогах каталога /etc, как вы уже видели на примере каталогов загрузки системы (/etc/init для варианта Upstart и /etc/systemd для systemd). В каталоге /etc по-прежнему есть несколько отдельных файлов конфигурации, но если вы запустите команду ls — F /etc, вы увидите, что эти элементы теперь в основном являются подкаталогами.

Чтобы справиться с проблемой перезаписывания файлов конфигурации, можно поместить пользовательские настройки в отдельных файлах внутри подкаталогов конфигурации вроде тех, которые присутствуют в каталоге /etc/grub.d.

Какие типы файлов конфигурации можно обнаружить в каталоге /etc? Основной принцип такой: настраиваемая конфигурация для одного компьютера, например информация о пользователе (/etc/passwd) и параметры сети (/etc/network), попадает в каталог /etc. Однако общие параметры приложений, например установки по умолчанию для пользовательского интерфейса, не располагаются в каталоге /etc. Зачастую файлы системной конфигурации, которые не подлежат настройке, находятся где-либо в другом месте, как это сделано для подготовленных файлов модулей systemd в каталоге /usr/lib/systemd.

Вы уже видели некоторые файлы конфигурации, которые имеют отношение к загрузке системы. Сейчас мы рассмотрим типичную системную службу и способы просмотра и настройки ее конфигурации.

7.2. Системный журнал

Большинство системных приложений передает свой диагностический вывод в службу syslog. Традиционный демон syslogd ожидает сообщения и в зависимости от типа полученного сообщения направляет вывод в файл, на экран, пользователям или в виде какой-либо комбинации перечисленного, но может и игнорировать сообщение.

7.2.1. Системный регистратор

Системный регистратор является одной из важнейших частей системы. Когда что-либо происходит не так и вы не знаете, с чего начать, загляните сначала в файлы системного журнала. Вот пример сообщения из него:

Aug 19 17:59:48 duplex sshd[484]: Server listening on 0.0.0.0 port 22.

В большинстве версий Linux используется новая версия службы syslogd под названием rsyslogd, которая выполняет намного больше, чем простая запись сообщений в файлы. Например, можно использовать ее для загрузки модуля, чтобы отправлять сообщения журнала в базу данных. Однако, приступая к изучению системных журналов, проще всего начать с файлов журналов, обычно хранящихся в каталоге /var/log. Просмотрите несколько таких файлов — когда вы будете знать, как они выглядят, вы будете готовы выяснить, как они здесь появились.

Многие из файлов в каталоге /var/log обслуживаются не с помощью системного регистратора. Единственный способ точно установить, какие из них принадлежат службе rsyslogd, — посмотреть ее файл конфигурации.

7.2.2. Файлы конфигурации

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

Традиционное правило состоит из селектора и действия, которые описывают, как перехватывать сообщения журнала и куда их направлять (пример 7.1).

Пример 7.1. Правила службы syslog

kern.* /dev/console