Стартовый сценарий системной службы linux записывается

С запуска init начинается загрузка самой системы. В давние времена, во времена молодости Linux и ранее, в этом месте никаких подводных камней не наблюдалось. Если ядро содержало подпрограммы для работы со всеми необходимыми устройствами (т. н. «драйверы»), оно загружалось и запускало init. Если ядру недоставало каких-то важных драйверов (например, поддержки дискового массива, с которого и шла загрузка) — не загружалось и не запускало. Из положения выходили просто: в ядро старались включить как можно больше драйверов. Такое ядро называлось базовым (generic), и имело довольно внушительный размер. Загрузивши систему с базовым ядром, администратор обычно пересобирал его: выбрасывал из специального файла-профиля драйверы всех отстутствующих в системе устройств, быть может, добавлял новые (те, что не нужны для загрузки, но нужны для работы, например, звуковые), и компилировал из исходных текстов новое, профильное ядро.

Стартовый виртуальный диск и модули ядра

Пересборка ядра нынче требуется очень редко. Во-первых, в Linux поддерживается несметное число различных внешних устройств, драйверы которых (особенно похожих, но разных) вполне могут помешать друг другу работать, если их использовать одновременно. Пришлось бы собирать множество разных ядер, без возможности указать пользователю, какое из них годится. Во-вторых, выяснением того, какой именно драйвер необходим найденному устройству, занимаются сейчас специальные программы, в распоряжении которых есть целые базы данных — ядру такую работу делать неудобно, да и незачем. Это делает процедуру пересборки ядра почти что обязательной (пока не загруженио базовое ядро, непонятно, какие драйверы добавлять в профильное). А в-третьих, пресборка ядра требует весьма высокой квалификации того, кто его пересобирает. Этот процесс нельзя ни автоматизировать, ни упростить. Утилита linuxconf, устроенная именно для этого на основе окон и меню, даёт на выходе работоспособное ядро в трёх случаях: (1) в руках профессионала, (2) при чётком следовании полной инструкции и (3) по случайности.

Не надо вручную пересобирать ядро, даже если учебник по Linux это советует!

Совсем другие времена настали, когда изобрели и активно внедрили в Linux загружаемые модули ядра. Модуль ядра — это часть ядра Linux, которую можно добавлять и удалять во время работы системы. Модуль ядра — не процесс, он работает в режиме супервизора и в таблице процессов не регистрируется: это набор подпрограмм для работы с определённым устройством, которые добавляются к возможностям ядра.

Этим он скорее похож на динамическую библиотеку.

При загрузке в память модуль компонуется с ядром, образуя с ним одно целое. Просмотреть список загруженных модулей можно командой lsmod, а подгрузить модуль в память, добавив его к ядру, и удалить его оттуда — командами insmod и rmmod соответственно.

# lsmod
Module                  Size  Used by    Not tainted
usb-uhci               21676   0  (unused)
usbcore                58464   1  [usb-uhci]
af_packet              12392   1  (autoclean)
pcnet32                15140   1  (autoclean)
mii                     2544   0  (autoclean) [pcnet32]
crc32                   2880   0  (autoclean) [pcnet32]
floppy                 48568   0  (autoclean)
subfs                   4296   4  (autoclean)
ac                      1792   0 
rtc                     6236   0  (autoclean)
ext3                   62288   2 
jbd                    37852   2  [ext3]

Пример 4. Получение списка загруженных модулей

Изменилось и базовое ядро: теперь оно включает в себя только устройства, необходимые для загрузки системы: главным образом диски и графическую консоль. Остальные устройства определятся уже самой системой, тогда можно будет и распознать экзотическую аппаратуру, и модуль для неё подгрузить. Однако полностью перевести драйверы всех внешних устройств в модули мешает вот какое соображение: что, если загрузка системы происходит именно с того устройства, чей модуль ещё не загружен в ядро, например, с дискового массива (RAID). Вторичный загрузчик и ядро можно, недолго думая, разместить на другом носителе (например, на лазерном диске) или добыть с дискового массива средствами BIOS (карты размещения позволяют не обращать внимания на логическую структуру RAID). Но как добыть модуль работы с RAID, тот самый, что распознает эту логическую структуру?

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

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

Вдумаемся. Для того, чтобы средствами Linux подключить модуль ядра, работающий с дисковым устройством, необходимо загрузить Linux с этого же устройства. Так ли это невозможно? Ведь если можно прочесть оттуда «ядро», то, наверное, можно прочесть и «Linux»? Более точно, вдобавок к одной области данных, соответствущей ядру, надо прочитать вторую, соответствующую некоторой уменьшенной до предела установке Linux, в которой содержатся только нужные программы и модули, загрузить оттуда «маленький Linux», который настроит и подключит злополучный RAID и запустит процесс загрузки полноценной системы оттуда.

Предельно сжатый вариант Linux есть, это проект busybox, используемый во встроенных системах, где дорог каждый байт. Разместить файловую систему в памяти тоже легко, этим, например, занимается модуль tmpfs, который можно включить в базовое ядро (подробнее о типах файловых систем рассказано в лекции Работа с внешними устройствами). Осталось только обучить подсистемы загрузки GRUB и LILO считывать не одну, а две области данных — ядро и образ файловой системы. Ядру при этом передаётся параметр «пользуйся виртуальным диском», чтобы оно подключило загруженный образ в качестве временной корневой файловой системы. Можно также потребовать, чтобы память, занимаемая временной файловой системой, освобождалась в процессе дальнейшей загрузки.

Такой механизм называется initrd (initial ram ddisk, где «ram» — это не «баран», а random access memory, то есть оперативная память) или стартовым виртуальным диском. Стартовый виртуальный диск собирается по команде mkinitrd в соответствии с профилем компьютера, и записывается на диск по тем же правилам, что и ядро. В примере двухсистемной машины, за которой работал Мефодий, также был стартовый виртуальный диск, причём довольно маленький:

[root@localhost root]# ls -lg /boot
drwxr-xr-x  2 root   4096 Nov 20 21:08 grub
-rw-------  1 root 205374 Nov  9 01:33 initrd-2.4.26-std-up.img
lrwxrwxrwx  1 root     29 Nov  9 01:33 initrd-up.img -> initrd-2.4.26-std-up.img
-rw-------  1 root  45056 Nov 20 19:07 map
-rw-r--r--  1 root 935892 Aug  3 21:59 vmlinuz-2.4.26-std-up
lrwxrwxrwx  1 root     26 Nov  9 01:33 vmlinuz-up -> vmlinuz-2.4.26-std-up

Пример 5. Размеры и наименование файлов с ядром и стартовым виртуальным диском

Как видно из примера, ядро в четыре раза превосходит размером стартовый виртуальный диск. Стоит заметить, что и ядро, и образ диска упакованы с помощью утилиты gzip (причём ядро умеет распаковываться в памяти самостоятельно), поэтому их действительный размер больше. В файле map хранится карта размещения LILO, а упомянутые в lilo.conf и menu.lst файлы vmlinuz-up и initrd-up.img оказались символьными ссылками на файлы с более говорящими именами. Никаких требований к названиям ядер в Linux нет, это дело авторов дистрибутива. В этом случае в имени ядра и образа диска встречается версия ядра (2.4.26), тип сборки std (по-видимому, «standard») и тип архитектуры up (uniprocessor, т. е. однопроцессорная).

стартовый виртуальный диск: Минимальный набор программ и модулей Linux, необходимый для обеспечения загрузки системы. Представляет собой виртуальную файловую систему в оперативной памяти. Загружается вторичным загрузчиком вместе с ядром.

Отец всех процессов

Если в параметрах не сказано иного, ядро считает, что init называется /sbin/init. В стартовом виртуальном диске это обычно некоторый простейший сценарий, а в полноценной системе у init другая задача: он запускает все процессы. Если не он сам, то его потомки, так что все процессы Linux, кроме ядерных, происходят от init, как весь род людской — от Адама.

Первым делом init разбирает собственный конфигурационный файл — /etc/inittab. Файл этот имеет довольно простую структуру: каждая строка (если она не комментарий) имеет вид «id: уровни: действие: процесс», где id — это некоторая двух- или однобуквенная метка, уровни — это слово, каждая буква которого соответствует уровню выполнения, (об уровнях выполнения будет рассказано далее), действие — это способ запуска процесса. Например, запись 4:2345:respawn:/sbin/mingetty tty4 означает, что меткой «4» помечен запуск /sbin/mingetty tty4 на уровнях выполнения 2, 3, 4 и 5 по алгоритму «respawn» (запустить в фоне, а когда процесс завершится, запустить заново).

mingetty — упрощённый аналог getty, работающий только на виртуальных консолях.

Помимо «respawn» существуют методы «once» (запустить в фоне однократно), «wait» (запустить интерактивно, при этом никаких других действий не выполняется, пока процесс не завершится) и множество других, включая даже «ctrlaltdel» — процесс, запускаемый, когда пользователь нажимает на консоли Ctrl+Alt+Del.

Понятно, что Ctrl+Alt+Del — это не reset, а обычное сочетание клавиш. Для удобства пользователя его специально распознаёт клавиатурный драйвер, а ядро сообщает об этом init-у.

Наконец-то Мефодий до конца понял, отчего getty ведёт себя так непохоже на остальные процессы: не просто запускает из-под себя login, а дожидается окончания его работы, отсутствуя при этом в таблице процессов. На самом деле дожидается не getty, а init, используя метод «respawn»: порождается (в фоне) процесс getty с определённым PID, а init бездействует до тех пор, пока существует процесс с этим PID getty, login, стартовый командный интерпретатор или программа, запущенная из него с помощью exec); когда же процесс, наконец, умирает, порождается новый getty.

Запуск системных служб

Полноценно загруженная Linux-система — не только login на виртуальной консоли. Системе есть чем заняться и помимо идентификации пользователей. Даже если компьютер не работает WWW-, FTP- или почтовым сервером для «внешнего мира», себе самой и своим пользователям система предоставляет множество услуг: отсылка заданий на печать и обеспечения их очереди, запуск заданий по расписанию, проверка целостности и т. п. Набор утилит и системных программ, предназначенных для предоставления таких услуг, принято называть подсистемами или службами.

Чему служат демоны?

Как правило, системная служба организована так. Во время начальной загрузки запускается в фоновом режиме программа, которая всё время работы системы находится в таблице процессов, однако большей частью бездействует, ожидая, когда её о чем-нибудь попросят. Для того, чтобы попросить эту программу об услуге, которую она предоставляет, используются утилиты, взаимодействующие с ней по специальному протоколу. По аналогии с сократовским «даймонионом», который незримо присутствует, по своей инициативе не делает ничего, не даёт совершать плохое и потворствует хорошему, такую программу стали называть «daemon». Не знакомые с творчеством Платона программисты-любители частенько переименовывали её в «demon» (демон); к сожалению, именно в такой, слегка инфернальной форме, daemon и вошёл в русскоязычную терминологию. Выходит, что в Linux услуги пользователям предоставляют… демоны!

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

В ранних версиях UNIX всё, что нужно было запускать при старте системы, вписывалось в inittab. Было довольно удобно в одном файле указывать, какие именно демоны должны работать в системе, и в каком порядке их запускать. Само поведение демона при запуске явно рассчитано на использование в inittab по методу «wait»: классический демон запускается интерактивно, проверяя правильность конфигурационных файлов и прочие условия работы, а затем самостоятельно уходит в фон (попросту делая fork() и завершая родительский процесс). Таким образом, init ждёт, пока демон работает интерактивно, а когда служба, возглавляемая этим демоном, готова к работе, переходит к следующей строке inittab. Однако часто бывает так, что автор демона знать не знает, какие именно условия разработчики той или иной версии Linux сочтут пригодными для запуска. Для этого ими создаётся стартовый сценарий, в котором запрограммирована логика запуска и останова службы. Кроме того, если на каждом из уровней выполения запускается много различных служб, попытка записывать их запуск в inittab делает его громоздким и совсем неочевидным.

Гуревич посоветовал Мефодию отложить на время изучение загрузки системы, а сначала посмотреть, как управлять стартовыми сценариями.

Стартовый сценарий системной службы

Стартовый сценарий — программа (обычно написанная на shell), управляющая включением или выключением какого-нибудь свойства системы. Это может быть запуск и остановка HTTP-сервера, активизация и деактивизация сетевых настроек, загрузки модулей и настройка звуковой подсистемы и т. п. Простейший стартовый сценарий обязан принимать один параметр, значение которого может быть словом «start» для запуска (включения) и «stop» для остановки (выключения). Если в определённом дистрибутиве Linux принято решение, что стартовые сценарии должны понимать и другие параметры, например «restart» (обычно «stop» + «start», но не всегда) и «status» (для опроса состояния), это требование распространяется на все стартовые сценарии. Единообразие позволяет, например, легко запускать и останавливать демоны, не выясняя, каков PID останавливаемого процесса и какой именно сигнал ему следует послать. Достаточно запуск написать так, чтобы PID процесса откладывался в специальный файл (обычно /var/run/имя_службы), а в остановку вписать что-то вроде kill -правильный_сигнал `cat /var/run/имя_службы`.

Все стартовые сценарии служб, которыми может воспользоваться система, принято хранить в каталоге /etc/rc.d/init.d (в некоторых дистрибутивах, для совместимости со старыми версиями UNIX, используется /etc/init.d, иногда это — просто символьная ссылка на /etc/rc.d/init.d). Запустить или остановить службу можно, просто вызвав соответствующий сценарий с параметром «start» или «stop». Часто ту же самую задачу выполняет и специальная команда service — которая проверяет, есть ли указанный стартовый сценарий, и запускает его.

В некоторых дистрибутивах Linux такая команда может называться invoke-rc.d, а команда, аналогичная описанному ниже chkconfig — update-rc.d.

[root@localhost root]# lsmod > old
[root@localhost root]# /etc/rc.d/init.d/sound stop
 Saving OSS mixer settings: [ DONE ]
 Unloading sound module (es1371): [ DONE ]
[root@localhost root]# lsmod > nosound
[root@localhost root]# service sound start
 Loading sound module (es1371): [ DONE ]
 Loading OSS mixer settings: [ DONE ]
[root@localhost root]# lsmod > new
[root@localhost root]# diff3 old new nosound
 ====3
 1:2,5c
 2:2,5c
  es1371                 25608   0 
  ac97_codec             11880   0  [es1371]
  soundcore               3652   4  [es1371]
  gameport                1628   0  [es1371]
 3:1a

Пример 6. Перезапуск звуковой подсистемы

Здесь Мефодий сначала остановил, а потом снова активизировал звуковую подсистему. Остановка привела к выгрузке звуковых модулей, а повторный запуск — к загрузке, полностью аналогичной исходной. В этом Мефодий убедился, сравнив с помощью утилиты diff3 три списка модулей: old (до остановки звуковой подсистемы), new (после повторного запуска) и nosound (между остановкой и повторным запуском). Файлы old и new полностью одинаковы, а от nosound оба отличаются тем, что со второй строки по пятую содержат названия тех самых модулей ядра (среди которых затесался gameport, отвечающий за джойстик).

Схема «. d»

Итак, имеется способ единообразно и гибко управлять запуском и остановкой каждой системной службы в отдельности (или включением и выключением одного свойства системы). Однако задача целиком огранизовать загрузку системы, от запуска init до полноценной работы, этим ещё не решается. Первая из возникающих задач такова: чаще всего нужно загружать не все из размещённых в /etc/rc.d/init.d сценариев, потому что некоторые из установленных в системе служб администратор решил не использовать. Удалять оттуда не используемые при загрузке сценарии — значит, лишать администратора возможности запускать эти сценарии вручную.

Создателям ранних версий UNIX пришла в голову простая мысль: написать один большой сценарий по имени /etc/rc, в который и заносить только нужные для запуска команды вида /etc/init.d/сценарий start. Можно даже занести туда все имеющиеся стартовые сценарии, но строки, запускающие те, что не используются, закомментировать. Такая (монолитная) схема имела существенный недостаток: добавление и удаление службы в систему (например, добавление и удаление пакета, содержащего исполняемые файлы службы) требовало редактирования этого файла. Если учесть, что порядок запуска служб весьма важен (например, бессмысленно запускать сетевые демоны до активизации сетевых настроек), становится ясно, что автоматическое изменение такого файла не может гарантировать нормальную загрузку системы, а значит, недопустимо.

На помощь пришла тактика, известная под именем «схема. d». Суть её в следующем. Пусть некоторый процесс управляется конфигурационным файлом, содержимое которого зависит от наличия и активации других служб системы (таким процессом может быть демон централизованной журнализации syslogd, ведущий журнал всех событий системы, или сетевой метадемон inetd, принимающий сетевые запросы и превращающий сетевой поток данных в обыкновенный посимвольный ввод-вывод). Тогда, чтобы избежать постоянного редактирования конфигурационного файла, его превращают в каталог (например, вдобавок к файлу /etc/syslog.conf заводится каталог /etc/syslog.d). Каждый файл в таком каталоге соответствует настройке одной службы: при добавлении её в систему файл появляется, при удалении — исчезает. Остаётся только обучить тот же syslog читать настройки не из одного syslog.conf, но и из всех файлов в syslog.d, и задача решена.

На случай запускаемых сценариев схема «. d» распространяется с двумя дополнениями. Во-первых, как уже было сказано, стартовые сценарии можно запускать, а можно и не запускать. Поэтому сам init.d не годится на роль «. d»-каталога. Впрочем, достаточно организовать ещё один каталог, скажем, rc.d, и создать там ссылки (для наглядности лучше символьные) на те сценарии из init.d, которые планируется запускать при старте системы. Общий стартовый сценарий rc как раз и будет заниматься запуском стартовых сценариев из rc.d.

Во-вторых, необходимо обеспечить строгий порядок запуска этих сценариев. Теоретически это совсем просто: отсортировать их по алфавиту, как это делает ls и запускать подряд. Практически же такое требование накладывает ограничение на имя ссылки в «. d»-каталоге, поэтому принято, чтобы в начале имени стояло двузначное число. Тогда, запуская подряд все сценарии, отсортированные алфавитно, rc будет в первую очередь руководствоваться этим номером, а уж потом — названием службы, которое после него стоит.

Уровни выполнения

В Linux схема начальной загрузки слегка сложнее, чем обычная «. d». Связано это с тем, что одну и ту же систему в разных случаях бывает необходимо загружать с разным набором служб. Если, скажем, использование сети нежелательно, удобнее сказать что-то вреде «Система! Загружайся без сети!», чем вручную удалять стартовые сценарии всех предположительно сетевых служб их «. d»-каталога. Необходимость выбора возникает также, если компьютер используется в качестве рабочей станции с запуском графической среды и всего с нею связанного или в качестве стоечного сервера, управлять которым лучше с системной консоли.

Поэтому в Linux предустотрено несколько вариантов начальной загрузки, называемых уровни выполнения (run levels). Уровни выполнения нумеруются с 0 до 9:

Уровень 1 соответствует однопользовательскому режиму загрузки системы. При загрузке на уровень 1 не запускается никаких служб, и даже системная консоль, как правило, бывает доступна только одна, так что в системе может работать не более одного пользователя. В однопользовательском режиме изредка работает администратор — исправляет неполадки системы, изменяет ключевые настройки, обслуживает файловые системы.
Уровень 2 соответствует многопользовательскому режиму загрузки системы с отключённой сетью. В этом режиме не запускаются никакие сетевые службы, что, с одной стороны, соответствует строгим требованиям безопасности, а с другой стороны, позволяет запускать службы и настраивать сеть вручную.
Уровень 3 соответствует многопользовательскому сетевому режиму загрузки системы. Сеть при загрузке на этот уровень настроена, и все необходимые сетевые службы запущены. На этом уровне обычно работают компьютеры-серверы.
Уровень 5 соответствует многопользовательскому графическому режиму загрузки системы. На этом уровне обычно работают рабочие станции, предоставляя пользователям возможность работать с графической подсистемой X11. Сеть на этом уровне настроена, а вот список запущенных сетевых служб может быть меньше, так как рабочая станция не всегда выполняет серверные функции (хотя, безусловно, может).
Уровни 0 и 6 — специальные. Они соответствуют останову и перезагрузке системы. В сущности, это удобные упрощения для действий, обратных загрузке на уровень: все службы останавливаются, диски размонтируются. В случае останова даже электропитание можно отключать программно, если аппаратура позволяет, а в случае перезагрузки система идёт на повторную загрузку.

Остальные уровни никак специально в Linux не описаны, однако администратор может использовать и их, определяя особый профиль работы системы. Переход с уровня на уровень происходит очень просто: по команде init номер_уровня. На какой уровень загружаться при старте ситемы, написано в inittab (в поле действие должно быть написано «initdefault», а в поле уровни — только одна цифра). Узнать текущий уровень выполнения можно с помощью команды runlevel:

[root@localhost root]# grep initdefault /etc/inittab 
 id:3:initdefault:
[root@localhost root]# runlevel
 N 3

Пример 7. Задание и просмотр уровня выполнения

уровень выполнения: Сохранённый профиль загрузки системы. В Linux реализован выполнением всех сценариев остановки и запуска служб из подкаталога rc.уровеньd каталога /etc или /etc/rc.d

Схема «. d» легко учитывает уровни выполнения. В каталоге /etc/rc.d заводится несколько «. d»-подкаталогов, соответствующих каждому уровню выполнения: /etc/rc.d/rcуровень.d.

В некоторых дистрибутивах — в каталоге /etc/

Именно оттуда их запускает стартовый сценарий /etc/rc.d/rc.

[root@localhost root]# ls -F /etc/rc.d
 init.d/  rc.powerfail*  rc0.d/  rc2.d/  rc4.d/  rc6.d/
 rc*      rc.sysinit*    rc1.d/  rc3.d/  rc5.d/  scripts/
[root@localhost root]# ls /etc/rc2.d
 K10power       K75netfs    S15random   S31klogd     S37gpm      S54sshd
 K44rawdevices  K95kudzu    S30sound    S32hotplug   S40crond    S98splash
 K50xinetd      S10network  S30syslogd  S35keytable  S41anacron  S99local
[root@localhost root]# ls -l /etc/rc2.d/ K75netfs
 lrwxrwxrwx  1 root root 15 Nov  9 01:16 /etc/rc2.d/K75netfs -> ../init.d/netfs

Пример 8. Содержимое каталогов /etc/rc.d и /etc/rc.d/rc2.d

Переход с уровня на уровень должен сопровождаться не только запуском, но и остановкой служб. Это касается не только уровней 0 и 6, но и любых других. Например, при переходе с уровня 3 на уровень 2 необходимо остановить все сетевые службы. Поэтому схема «. d» была расширена: сначала с параметром «stop» запускаются сценарии, имена которых начинаются на «K» (Kill), а затем, с параметром «start» — те, имена которых начинаются на «S» (Start). В приведенном примере при переходе на уровень 2 останавливаются несколько служб, в том числе сетевой метадемон (K50xinetd) и монтирование по сети удалённых файловых систем (K75netfs). Если при переходе с уровня на уровень некой службе не требуется менять своего состояния, сценарий не запускается вовсе. Так, при переходе с уровня 3 на уровень 2 сетевые настройки остаются активными, поэтому соответствующий сценарий (S10network), скорее всего, запущен не будет.

Долгое время считалось, что определение порядка загрузки — дело системного администратора, поэтому расставлять символьные ссылки в каталоги rc*.d приходилось вручную. Однако одно из другого не следует: можно предусмотреть и более лёгкий способ наполнения этих каталогов ссылками. Один из способов такой: поставить в стартовый сценарий комментарий особого вида, в котором и описать, на каких уровнях служба должна быть активизирована, и какой по порядку должна быть запущена и остановлена:

[root@localhost root]# grep chkconfig /etc/init.d/netfs
 # chkconfig: 345 25 75
[root@localhost root]# chkconfig --list netfs
 netfs           0:off   1:off   2:off   3:on    4:on    5:on    6:off
[root@localhost root]# ls /etc/rc.d/rc*.d/*netfs
 /etc/rc.d/rc0.d/K75netfs  /etc/rc.d/rc3.d/S25netfs  /etc/rc.d/rc6.d/K75netfs
 /etc/rc.d/rc1.d/K75netfs  /etc/rc.d/rc4.d/S25netfs
 /etc/rc.d/rc2.d/K75netfs  /etc/rc.d/rc5.d/S25netfs

Пример 9. Управление порядком выполнения стартовых сценариев

Здесь Мефодий использовал утилиту chkconfig, которая ищет в стартовом сценарии комментарий вида chkconfig: уровни вкл выкл, и самостоятельно проставляет ссылки в соответствии с этими полями: во всех каталогах, упомянутых в уровнях соответствующий netfs сценарий имеет вид Sвклnetfs, а во всех остальных — Kвыклnetfs. Эта же утилита позволяет добавлять и удалять службу на каждом уровне в отдельности или запрещать её вовсе.

Загрузка типичной системы на уровень выполнения 5

Итак, что же происходит после запуска init?

[root@localhost root]# grep rc /etc/inittab
 si::sysinit:/etc/rc.d/rc.sysinit
 l0:0:wait:/etc/rc.d/rc 0
 l1:1:wait:/etc/rc.d/rc 1
 l2:2:wait:/etc/rc.d/rc 2
 l3:3:wait:/etc/rc.d/rc 3
 l4:4:wait:/etc/rc.d/rc 4
 l5:5:wait:/etc/rc.d/rc 5
 l6:6:wait:/etc/rc.d/rc 6
[root@localhost root]# grep initdefault /etc/inittab 
 id:5:initdefault:

Пример 10. Стартовые сценарии в /etc/inittab

Метод «sysinit» в inittab означает, что процесс запускается во время начальной загрузки системы, до перехода на какой-нибудь уровень выполнения. Следовательно, первым запускается сценарий /etc/rc.d/rc.sysinit. Он настраивает аппаратуру дисковых массивов, проверяет и монтирует дисковые файловые системы, инициализирует область подкачки, межсетевой экран — словом, делает всё, без чего дальнейшая полноценная загрузка системы невозможна. Далее из строчки с «initdefault» init узнаёт, что уровень выполнения по умолчанию — пятый (многопользовательский графический), и выполняет все строки из inittab, в поле уровни которых есть 5. В частности, запускается сценарий rc с параметром 5 (l5:5:wait:/etc/rc.d/rc 5), который и выполняет необходимые действия из «. d»-каталога /etc/rc.d/rc5.d. Метод запуска rc — «wait», так что init ждёт, пока не выполнятся все стартовые сценарии, а потом продолжает разбор inittab.

[root@localhost root]# ls /etc/rc.d/rc5.d/
 K10acpid    S10network  S30syslogd     S37gpm      S50xinetd
 K20nfs      S13portmap  S31klogd       S40crond    S54sshd
 K65apmd     S15random   S32hotplug     S41anacron  S56rawdevices
 K86nfslock  S25netfs    S35keytable    S44xfs      S64power
 S05kudzu    S30sound    S36update_wms  S45dm       S98splash

Пример 11. Профиль системы на уровне выполнения 5

Мефодий заметил, сценарий K20nfs (с параметром «stop») не выполнился: соответствующего сообщения на системной консоли не появилось. Беглый просмотр /etc/rc.d/init.d/nfs показал, что этот сценарий предназначен для запуска и остановки сервера сетевой файловой системы (NFS). Сервер используется на уровне 3, а на уровне 5 — нет, поэтому при переходе с 3 на 5 его следует останавливать. Поскольку во время начальной загузки останавливать нечего, сценарий не выполнился.

Из служб, запускаемых именно на пятом уровне, примечателен шрифтовый сервер, под номером 44, (the Xfont server, xfs) — программа, у которой графическая подсистема получает шрифты (нередко по сети, тогда такой сервер может быть один на несколько рабочих станций), и экранный диспетчер, под номером 45, (the Xdisplay manager, xdm) — программа, регистрирующая пользователя на манер login, с той разницей, что регистрация и запуск графических приложений могут происходить по сети с удалённого компьютера.

Не путать с диспетчером окон, описанным в лекции Графический интерфейс (X11).

Тут разрешилась ещё одна загадка: вместо обычной виртуальной консоли и login-а, Мефодий нередко наблюдал окно графической подсистемы с надписью «Login:» и «Password:», а кое-где даже «Логин:», «Пароль:» и портрет самого пользователя! Оказывается, это были различные версии xdm. Дабы не забивать себе голову разрозненными сведениями, Мефодий решил до поры (до лекции Графический интерфейс (X11)) не использовать графическую среду и нажал Ctrl+Alt+F1, переключившись в текстовую консоль.

Текстовая консоль на пятом уровне доступна: записи вида 1:2345:respawn:/sbin/mingetty tty1 обычно включают 5 в поле уровни.

Источник

Запуск системных служб

Полноценно загруженная Linux-система — не только login на виртуальной консоли. Системе есть чем заняться и помимо идентификации пользователей. Даже если компьютер не работает WWW-, FTP- или почтовым сервером для «внешнего мира», себе самой и своим пользователям система предоставляет множество услуг: отсылка заданий на печать и обеспечение их очереди, запуск заданий по расписанию, проверка целостности и т.п. Набор утилит и системных программ, предназначенных для предоставления таких услуг, принято называть подсистемами или службами.

Чему служат демоны?

Как правило, системная служба организована так. Во время начальной загрузки запускается в фоновом режиме программа, которая на протяжении работы системы находится в таблице процессов, однако большей частью бездействует, ожидая, когда ее о чем-нибудь попросят. Для того чтобы попросить эту программу об услуге, которую она предоставляет, используются утилиты, взаимодействующие с ней по специальному протоколу. По аналогии с сократовским «даймонионом», который незримо присутствует, по своей инициативе не делает ничего, не дает совершать плохое и способствует хорошему, такую программу стали называть » daemon «. Не знакомые с творчеством Платона программисты-любители частенько переименовывали ее в » demon » ( демон ); к сожалению, именно в такой, слегка инфернальной форме, daemon и вошел в русскоязычную терминологию. Выходит, что в Linux услуги пользователям предоставляют… демоны!

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

В ранних версиях UNIX все, что нужно было запускать при старте системы, вписывалось в inittab. Было довольно удобно в одном файле указывать, какие именно демоны должны работать в системе, и в каком порядке их запускать. Само поведение демона при запуске явно рассчитано на использование в inittab по методу » wait «: классический демон запускается интерактивно, проверяя правильность конфигурационных файлов и прочие условия работы, а затем самостоятельно уходит в фон (попросту делая fork() и завершая родительский процесс). Таким образом, init ждет, пока демон работает интерактивно, а когда служба, возглавляемая этим демоном, готова к работе, переходит к следующей строке inittab. Однако часто бывает так, что автор демона знать не знает, какие именно условия разработчики той или иной версии Linux сочтут пригодными для запуска. Для этого ими создается стартовый сценарий, в котором запрограммирована логика запуска и останова службы. Кроме того, если на каждом из уровней выполнения запускается много различных служб, попытка записывать их запуск в inittab делает его громоздким и совсем неочевидным.

Гуревич посоветовал Мефодию отложить на время изучение загрузки системы, а сначала посмотреть, как управлять стартовыми сценариями.

Стартовый сценарий системной службы

Стартовый сценарий — программа (обычно написанная на shell), управляющая включением или выключением какого-нибудь свойства системы. Это может быть запуск и остановка HTTP-сервера, активизация и деактивизация сетевых настроек, загрузка модулей и настройка звуковой подсистемы и т.п. Простейший стартовый сценарий обязан принимать один параметр, значение которого может быть словом «start» для запуска (включения) и «stop» для остановки (выключения). Если в определенном дистрибутиве Linux принято решение, что стартовые сценарии должны понимать и другие параметры, например «restart» (обычно «stop»+»start», но не всегда) и «status» (для опроса состояния), это требование распространяется на все стартовые сценарии. Единообразие позволяет, например, без труда запускать и останавливать демоны, не выясняя, каков PID останавливаемого процесса и какой именно сигнал ему следует послать. Достаточно запуск написать так, чтобы PID процесса откладывался в специальный файл (обычно /var/run/имя_службы ), а в остановку вписать что-то вроде kill -правильный_сигнал `cat /var/run/имя_службы`.

Все стартовые сценарии служб, которыми может воспользоваться система, принято хранить в каталоге /etc/rc.d/init.d (в некоторых дистрибутивах, для совместимости со старыми версиями UNIX, используется /etc/init.d, иногда это просто символьная ссылка на /etc/rc.d/init.d ). Запустить или остановить службу можно, просто вызвав соответствующий сценарий с параметром «start» или «stop». Часто ту же самую задачу выполняет и специальная команда service, которая проверяет, есть ли указанный стартовый сценарий, и запускает его^{9В некоторых дистрибутивах Linux такая команда может называться invoke-rc.d, а команда, аналогичная описанному ниже chkconfig — update-rc.d .}:

[root@localhost root]# lsmod > old
[root@localhost root]# /etc/rc.d/init.d/sound stop
 Saving OSS mixer settings: [ DONE ]
 Unloading sound module (es1371): [ DONE ]
[root@localhost root]# lsmod > nosound
[root@localhost root]# service sound start
 Loading sound module (es1371): [ DONE ]
 Loading OSS mixer settings: [ DONE ]
[root@localhost root]# lsmod > new
[root@localhost root]# diff3 old new nosound
 ====3
 1:2,5c
 2:2,5c
 es1371           25608   0
 ac97_codec       11880   0 [es1371]
 soundcore         3652   4 [es1371]
 gameport          1628   0 [es1371]
 3:1a

Пример
10.6.
Перезапуск звуковой подсистемы

Здесь Мефодий сначала остановил, а потом снова активизировал звуковую подсистему. Остановка привела к выгрузке звуковых модулей, а повторный запуск — к загрузке, полностью аналогичной исходной. В этом Мефодий убедился, сравнив с помощью утилиты diff3 три списка модулей: old (до остановки звуковой подсистемы), new (после повторного запуска) и nosound (между остановкой и повторным запуском). Файлы old и new одинаковы, а от nosound оба отличаются тем, что со второй строки по пятую содержат названия тех самых модулей ядра (в том числе gameport, отвечающий за джойстик).

Схема «.d»

Итак, существует способ единообразно и гибко управлять запуском и остановкой каждой системной службы в отдельности (или включением и выключением одного свойства системы). Однако задача целиком организовать загрузку системы, от запуска init до полноценной работы, этим еще не исчерпывается. Первая из возникающих задач такова: чаще всего нужно загружать не все из размещенных в /etc/rc.d/init.d сценариев, потому что некоторые из установленных в системе служб администратор решил не использовать. Удалять оттуда не используемые при загрузке сценарии — значит, лишать администратора возможности запускать эти сценарии вручную.

Создателям ранних версий UNIX пришла в голову простая мысль: написать один большой сценарий по имени /etc/rc, в который и заносить только нужные для запуска команды вида /etc/init.d/сценарий start. Можно даже занести туда все имеющиеся стартовые сценарии, но строки, запускающие те, что не используются, закомментировать. Такая (монолитная) схема имела существенный недостаток: добавление и удаление службы в систему (например, добавление и удаление пакета, содержащего исполняемые файлы службы) требовало редактирования этого файла. Если учесть, что порядок запуска служб весьма важен (например, бессмысленно запускать сетевые демоны до активизации сетевых настроек), становится ясно, что автоматическое изменение такого файла не может гарантировать нормальную загрузку системы, а значит, недопустимо.

На помощь пришла тактика, известная как «схема .d «. Суть ее в следующем. Пусть некоторый процесс управляется конфигурационным файлом, содержимое которого зависит от наличия и активации других служб системы (таким процессом может быть демон централизованного журналирования syslogd, ведущий журнал всех событий системы, или сетевой метадемон inetd, принимающий сетевые запросы и превращающий сетевой поток данных в обыкновенный посимвольный ввод-вывод). Тогда, чтобы избежать постоянного редактирования конфигурационного файла, его превращают в каталог (например, вдобавок к файлу /etc/syslog.conf заводится каталог /etc/syslog.d ). Каждый файл в таком каталоге соответствует настройке одной службы: при добавлении ее в систему файл появляется, при удалении — исчезает. Остается только обучить тот же syslog читать настройки не только из одного syslog.conf, но и из всех файлов в syslog.d, и задача решена.

На случай запускаемых сценариев схема » .d » распространяется с двумя дополнениями. Во-первых, как уже было сказано, стартовые сценарии можно запускать, а можно и не запускать. Поэтому сам init.d на роль » .d «-каталога не годится. Впрочем, достаточно организовать еще один каталог, скажем, rc.d, и создать там ссылки (для наглядности лучше символьные) на те сценарии из init.d, которые планируется запускать при старте системы. Общий стартовый сценарий rc как раз и будет заниматься запуском стартовых сценариев из rc.d.

Во-вторых, необходимо обеспечить строгий порядок запуска этих сценариев. Теоретически это совсем просто: отсортировать их по алфавиту, как это делает ls, и запускать подряд. Практически же такое требование накладывает ограничение на имя ссылки в » .d «-каталоге, поэтому принято, чтобы в начале имени стояло двузначное число. Тогда, запуская подряд все сценарии, отсортированные по алфавиту, rc будет в первую очередь руководствоваться этим номером, а уж потом — названием службы, которое после него стоит.

Источник

Стартовый сценарий системной службы

Стартовый сценарий — программа (обычно написанная на shell), управляющая включением или выключением какого-нибудь свойства системы. Это может быть запуск и остановка HTTP-сервера, активизация и деактивизация сетевых настроек, загрузка модулей и настройка звуковой подсистемы и т.п. Простейший стартовый сценарий обязан принимать один параметр, значение которого может быть словом start для запуска (включения) и stop для остановки (выключения). Если в определенном дистрибутиве Linux принято решение, что стартовые сценарии должны понимать и другие параметры, например restart (обычно stop+start, но не всегда) и status (для опроса состояния), это требование распространяется на все стартовые сценарии. Единообразие позволяет, например, без труда запускать и останавливать демоны, не выясняя, каков PID останавливаемого процесса и какой именно сигнал ему следует послать. Достаточно запуск написать так, чтобы PID процесса откладывался в специальный файл (обычно /var/run/имя_службы), а в остановку вписать что-то вроде kill — правильный_сигнал cat /var/run/имя_службы.

Все стартовые сценарии служб, которыми может воспользоваться система, принято хранить в каталоге /etc/rc.d/init.d (в некоторых дистрибутивах, для совместимости со старыми версиями UNIX, используется /etc/init.d, иногда это просто символьная ссылка на /etc/rc.d/init.d). Запустить или остановить службу можно, просто вызвав соответствующий сценарий с параметром start или stop. Часто ту же самую задачу выполняет и специальная команда service, которая проверяет, есть ли указанный стартовый сценарий, и запускает его:

[root@localhost root]# lsmod > old
[root@localhost root]# /etc/rc.d/init.d/sound stop
 Saving OSS mixer settings: [ DONE ]
 Unloading sound module (es1371): [ DONE ]
[root@localhost root]# lsmod > nosound
[root@localhost root]# service sound start
 Loading sound module (es1371): [ DONE ]
 Loading OSS mixer settings: [ DONE ]
[root@localhost root]# lsmod > new
[root@localhost root]# diff3 old new nosound
 ====3
 1:2,5c
 2:2,5c
 es1371           25608   0
 ac97_codec       11880   0 [es1371]
 soundcore         3652   4 [es1371]
 gameport          1628   0 [es1371]
 3:1a

Пример 10.6. Перезапуск звуковой подсистемы

Здесь Иван сначала остановил, а потом снова активизировал звуковую подсистему. Остановка привела к выгрузке звуковых модулей, а повторный запуск — к загрузке, полностью аналогичной исходной. В этом Иван убедился, сравнив с помощью утилиты diff3 три списка модулей: old (до остановки звуковой подсистемы), new (после повторного запуска) и nosound (между остановкой и повторным запуском). Файлы old и new одинаковы, а от nosound оба отличаются тем, что со второй строки по пятую содержат названия тех самых модулей ядра (в том числе gameport, отвечающий за джойстик).

Источник

Текущий каталог определён для:

каждой командной оболочки пользователя
каждого пользователя, зарегистрированного в системе
(Правильный ответ) каждой выполняемой программы (процесса)
каждого каталога файловой системы

Пользователь root — это

(Правильный ответ) учётная запись, гарантированно дающая пользователю исключительные права работы в системе
учётная запись, которую рекомендуется использовать администратору системы, даже если у него имеется персональная учётная запись
единственная учётная запись, принадлежащая администратору системы

Репозиторий пакетов — это

любой комплект пакетов на CD или DVD
набор пакетов в одном формате, размещённых в одном каталоге
любой набор пакетов
(Правильный ответ) организованное по специальным правилам хранилище пакетов, используемое менеджерами пакетов в качестве источника

Программа last выводит:

(Правильный ответ) список последних работавших пользователей
идентификатор последнего зарегистрировавшегося в системе пользователя
последнюю команду, выполненную пользователем
список команд, введённых пользователем

Какой результат выведет на терминал команда cd; echo $??

сообщение об ошибке
(Правильный ответ) 0
1
название домашнего каталога

Предоставляются только пакетами OpenOffice.org и KOffice
Предоставляется только различными программными продуктами, имеющими принципиально различную структуру меню и формат документов
(Правильный ответ) Предоставляются пакетами OpenOffice.org и KOffice, а также различными отдельными программными продуктами
Предоставляются только пакетом OpenOffice.org

В оконном интерфейсе субъектом с точки зрения системы является

окно
любая программа
(Правильный ответ) задача, выводящая и вводящая данные в рамках окна
пользователь, управляющий окнами

Как, редактируя текст в Emacs, вырезать текущий абзац (в котором находится точка) и вставить его в самый конец текста?

M-{ M-Пробел M-} M-> M-y
M-{ M-@ M-} M-> C-w
(Правильный ответ) M-h C-w M-> C-y
M-h M-> C-y

Термином «подстановка» в shell обозначается

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

Что входит в ярлык объекта файловой системы?

UID и GID объекта
UID и GID объекта, список GID, членом которых является хозяин объекта, тип объекта и его атрибуты
(Правильный ответ) UID и GID объекта, его тип и атрибуты

Каталог /var предназначен для

(Правильный ответ) хранения данных, которые создаются в процессе работы разными программами и предназначены для передачи другим программам и системам
хранения файлов, которые, согласно классификации, не могут быть помещены в другие каталоги системы — /etc, /bin, /lib и т. п.
хранения конфигурационных файлов в формате переменная=значение
хранения файлов, назначение которых может меняться в процессе работы системы или не определено

Процесс, которому передан сигнал INT (“^C”)

немедленно прекратит исполняться и будет переведён в фон
немедленно прекратит исполняться, но не будет удалён из таблицы процессов, ожидая сигнала к продолжению работы
немедленно прекратит исполняться и будет удалён из таблицы процессов
(Правильный ответ) немедленно запустит подпрограмму-обработчик данного сигнала, а если обработчика нет, то система сама обработает сигнал (завершит процесс)

Монтирование файловых систем не позволяет

Использовать различные по скорости и надёжности способы доступа к различным подкаталогам
Собирать файловые системы различных разделов в одно дерево каталогов
Подключать к дереву каталогов содержимое файлов, данные ядра, каталоги на других компьютерах
(Правильный ответ) Использовать журналирование с файловыми системами, в которых оно не предусмотрено

Какая из перечисленных команд не имеет отношения к справочной подсистеме Linux?

man
whatis
info
(Правильный ответ) showhelp

Какой список файлов может сгенерировать shell по шаблону

?r*[cC]

bash.rc .bashrc BarC rrrc
(Правильный ответ) *rcC CrooC crc or..c
oroc ir/ac arc r@C
tric rC r.C mail.rc

Назначать маршрутизатор по умолчанию следует при помощи

утилиты ifconfig
(Правильный ответ) утилиты route
редактирования файла /etc/resolv.conf
редактирования файла ifcfg-eth0

Система подготовки печатной документации LaTeX

Обладает простым и интуитивно понятным интерфейсом, позволяющим новичку создавать высококачественные документы
Представляет собой только соглашение о формате файлов и набор утилит, а основную работу по форматированию производят текстовые редакторы, такие как LyX и emacs
(Правильный ответ) Высокоуровневая надстройка над TeX, ориентированная на решение типичных задач оформления. Формат LaTeX используется редактором LyX, предоставляющим визуальные средства редактирования документа
Рассчитана на профессионального пользователя, поэтому никаких средств, позволяющих работать в ней новичку, не предусмотрено

Сколько ключей передано утилите в команде

grep -l —max-count=3 «»key switch»» option

ни одного
1
(Правильный ответ) 2
3

При запуске процесс получает

один открытый дескриптор
(Правильный ответ) три открытых дескриптора
два открытых дескриптора
ни одного открытого дескриптора

Пусть

[methody@localhost methody]$ ls -ld examplesdrwxr-xr-x 3 methody methody 4096 Окт 29 12:10 examples[methody@localhost methody]$ ls -l examples-rw-r—r— 1 methody methody 84718 Окт 6 10:31 -filename-with-

К чему приведёт выполнение команды rmdir examples?

к удалению файла “-filename-with-”
(Правильный ответ) к сообщению об ошибке
к удалению каталога “examples” и файла “-filename-with-”
к удалению каталога “examples”

Каков адрес сети, в которую входит компьютер с IP-адресом 192.168.0.13 и сетевой маской 255.255.255.0?

(Правильный ответ) 192.168.0.0/24
192.168.0.0
192.168.1.0/16
192.168.0.0/16

Основное средство взаимодействия пользователя и ОС Linux

Клавиатура, мышь, монитор
Виртуальная консоль
Любое устройство ввода-вывода
(Правильный ответ) Любой терминал

Могут ли в Linux существовать устройства, доступные на запись любому пользователю?

Обычно нет, но суперпользователь может вручную сменить права доступа
Это запрещено
Устройств, доступных на запись всем пользователям одновременно, не существует, однако права доступа к целой группе устройств передаются любому пользователю, зарегистрированному в системе первым
(Правильный ответ) Такие устройства существуют всегда

“/home/methody/examples” — это:

домашний каталог
(Правильный ответ) полный путь
относительный путь
корневой каталог

На жёстком диске, соответствующем файлу-дырке /dev/hda, три основных раздела и один расширенный, в котором содержится один дополнительный. Какой файл-дырка соответствует дополнительному разделу?

/dev/hda4
(Правильный ответ) /dev/hda5
/dev/hda3
/dev/hda2

Стартовый сценарий системной службы

Записывается в каталоги /etc/rc.d и /etc/rc.d/rc*.d
Записывается в каталог /etc/rc.d, а в каталогах /etc/rc.d/init.d и /etc/rc.d/rc*.d помещаются символьные ссылки на него
(Правильный ответ) Записывается в /etc/rc.d/init.d, а в каталогах /etc/rc.d/rc*.d помещаются символьные ссылки на него
Записывается в /etc/init.d

Файлу какого типа соответствует строка атрибутов “crw-rw—-”?

обычному файлу
именованному каналу
файлу-дырке, соответствующему устройству, из которого можно считывать и записывать информацию поблочно
(Правильный ответ) файлу-дырке, соответствующему устройству, из которого можно считывать и записывать информацию посимвольно

Большинство фильтров Linux работают с

Файлами любого заранее описанного формата
(Правильный ответ) Файлами, разбитыми на строки, каждая из которых может разделяться на поля
Файлами, поделёнными на строки равной длины
Файлами, разбитыми на записи при помощи разделителей

Мефодий неудачно попытался запустить программу xterm, получив сообщение “cannot open display:”. В чём, скорее всего, была причина ошибки?

Не запущен X-сервер
(Правильный ответ) Не установлена переменная окружения DISPLAY
Не установлена переменная окружения display
К компьютеру не подключён дисплей

В какой кодировке могут быть записаны русские имена файлов в Linux:

(Правильный ответ) в любой кодировке, подходящей для записи русских имён
CP-1251
KOI8-R
CP-866

Первым широко распространённым некоммерческим дистрибутивом Linux стал

RedHat
Gentoo
(Правильный ответ) Slackware
Debian

Название утилиты gimp расшифровывается как

GNU Instant Messaging Program
(Правильный ответ) GNU Image Manipulation Program
Graphic Interformat Multimedia Player
Geographic International Map Project

Команда who предназначена для

(Правильный ответ) Вывода списка зарегистрированных в настоящее время пользователей системы
Вывода статистики использования указанным пользователем ресурсов системы
Вывода детальной информации из учётной записи указанного пользователя
Вывода списка пользователей, регистрировавшихся в системе за последнее время

Пользователь может получить список содержащихся в каталоге dir файлов и просмотреть их содержимое, но не может создать или удалить файл в каталоге dir. Каков режим доступа к этому каталогу?

доступен только на чтение и запись
доступен только на чтение
доступен только на использование
(Правильный ответ) доступен только на чтение и использование

В файловой системе Linux

не более двух корневых каталогов
не более 15 корневых каталогов
по одному корневому каталогу на каждый диск
(Правильный ответ) один корневой каталог

Как в bash узнать, является ли команда cmd сокращением, и если да, то во что она будет раскрыта?

(Правильный ответ) alias
(Правильный ответ) type cmd
(Правильный ответ) alias cmd

Для того, чтобы запустить несколько приложений с текстовым интерфейсом на удалённом компьютере, необходимо

Запустить несколько эмуляторов терминала на рабочей станции, и в каждом из них воспользоваться клиентом Secure Shell
(Правильный ответ) Подходит любой из перечисленных выше способов, однако первый не требует наличия графической подсистемы ни на рабочей станции, ни на удалённой машине
Воспользоваться клиентом Secure Shell на рабочей станции и утилитой screen на удалённом компьютере
Воспользоваться клиентом Secure Shell на рабочей станции с предоставлением виртуального X-сервера на удалённой машине, после чего запустить с удалённой машины несколько эмуляторов терминала

Программа k3b предназначена для

Просмотра роликов в формате DVD и MPEG, а также прослушивания музыки с аудио дисков и из файлов в формате OGG
(Правильный ответ) Записи дисков в формате CD и DVD
Прослушивания аудио CD
Просмотра DVD

Запуском исполняемых программ в Linux занимается

Сам пользователь, при помощи терминала
(Правильный ответ) Интерпретатор командной строки, на основе разбора команды пользователя
Программа-загрузчик, вследствие команды от shell или системы
Система, под воздействием управляющих символов

Менеджер пакетов занимается

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

Если в X Window System окно получило фокус, это означает, что

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

В файле /etc/services содержится

(Правильный ответ) соответствия названий сетевых протоколов номерам постоянно закреплённых за ними портов
список серверов DNS, которые следует использовать при подключении к Internet
список активных сетевых подключений
соответствия IP-адресов именам компьютеров в сети

Команда tr предназначена для

Изменения порядка полей в потоке данных
(Правильный ответ) Замены одних символов в потоке данных на другие
Перевода с одного естественного языка на другой
Трансляции командных сценариев

Программа inkscape предназначена для

Удобного просмотра каталoгов с изображениями
(Правильный ответ) Редактирования векторной графики
Редактирования диаграмм
Редактирования растровой графики

Зависимость одного rpm-пакета от другого означает, что

(Правильный ответ) Зависимый пакет не может быть успешно установлен без того, от которого он зависит
Ни один из двух пакетов не может быть установлен без другого
Информацию об первом пакете нельзя получить, не зная информации о втором
Программное обеспечение первого пакета не может работать без содержимого второго

Какой список файлов может сгенерировать shell по шаблону r[cC]

oroc ir/ac arc r@C
(Правильный ответ) *rcC CrooC crc or..c
tric rcC] r.C mail.rc
bash.rc .bashrc BarC rrrc

Для определения прав доступа процесса к объекту файловой системы не требуется

полный список групп, в которые входит пользователь-владелец процесса
(Правильный ответ) тип объекта (файл, каталог, файл-дырка и т. д.)
ярлык объекта файловой системы
UID пользователя-владельца процесса

При редактировании конфигурационных файлов

Может применяться текстовый редактор, но в некоторых случаях, для обеспечения атомарности, необходимо использовать редактор Vim
(Правильный ответ) Может применяться текстовый редактор, но в некоторых случаях необходимо использовать специальные утилиты
Всегда применяются специальные утилиты (возможно, запускающие текстовый редактор из переменной окружения EDITOR)
Всегда используется текстовый редактор

Альтернативы пакетов применяются, когда необходимо, чтобы

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

Какие пакеты можно успешно передавать через сервер подмены сетевых адресов (NAT)?

Только TCP и UDP-пакеты
(Правильный ответ) Любые пакеты, которые можно гарантированно отличить друг от друга, не используя поле «IP-адрес отправителя». Если протокол требует ответа на передаваемый пакет, ответные пакеты также должны быть однозначно идентифицируемы по полям, отличным от IP-адреса отправителя
Любые пакеты, предусматривающие не только поле «адрес отправителя», но также поля «адрес получателя» и «порт».
Любые пакеты, которые можно гарантированно отличить друг от друга, не используя поле «IP-адрес отправителя».

Текстовый редактор нужен, чтобы

редактировать любые файлы
редактировать конфигурационные файлы
редактировать любые файлы в формате «plain text»
(Правильный ответ) редактировать любые файлы в текстовом формате

Стандарт FHS рекомендует размещать домашние каталоги пользователей:

(Правильный ответ) в подкаталогах /home
размещение домашних каталогов пользователей, отличных от root, не предусмотрено стандартом FHS, так как их названия зависят от входных имён пользователей, на которые этот стандарт не распространяется
в подкаталогах /user
в подкаталогах /usr

Многопользовательская организация системы не позволяет

Производить учёт потребления ресурсов каждым пользователем
(Правильный ответ) Одновременно использовать два или более вариантов настройки основных системных служб
Вводить различные права доступа для разных пользователей системы
Работать нескольким пользователям одновременно

Необходимость в дистрибутивах Linux возникла, когда

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

Мефодий «ухватил» окно xterm за уголок и увеличил его. Какие программы, помимо xterm, были в этом задействованы.

только xterm
(Правильный ответ) диспетчер окон и X-сервер
только диспетчер окон
только X-сервер

Какую из перечисленных задач не выполняет X-сервер?

передача данных, вводимых с клавиатуры, X-клиентам
выдача окон X-клиентам по запросу
(Правильный ответ) отправка X-запросов на открытие окна X-клиентам
вывод на графическое устройство

Каковы обязанности метадемона inetd?

Отслеживать сетевую активность только на зарегистрированных портах и сообщать постоянно находящимся в памяти обработчикам-демонам о том, что необходимо принять подключение
Принимать подключение по указанному порту и запускать различные обработчики-фильтры в зависимости от протокола, указанного при подключении
(Правильный ответ) Принимать подключения сразу по нескольким портам и запускать указанные обработчики-фильтры
Отслеживать сетевую активность на всех портах системы и запускать обработчики, которые будут принимать подключения по зарегистрированным портам и обрабатывать их

Конфликт двух пакетов происходит в случае, когда

Два разных пакета содержат хотя бы по одному файлу, полные пути которых совпадают, а содержимое различно
(Правильный ответ) Два разных пакета содержат хотя бы по одному файлу, полные пути которых совпадают
Два разных пакета имеют одно и то же название
Два одинаковых пакета называются по-разному

Как связаны символьная ссылка и файл, на который она указывает?

они представляют собой один и тот же файл
(Правильный ответ) символьная ссылка — это специальный файл, содержащий имя другого файла (на который она указывает)
символьная ссылка указывает на область диска, где расположен файл
символьная ссылка — другое имя того же индексного дескриптора

Что такое «подмена идентификатора»?

наименование способа, которым достигается несанкционированный доступ к неаккуратно настроенным Linux-системам
(Правильный ответ) механизм наследования процессом соответствующего идентификатора не от родительского процесса, а из ярлыка запускаемого файла
механизм временной смены процессом соответствующего идентификатора на основании содержимого таблиц su или sudo
механизм выполнения пользователем действий с чужими правами доступа, управляемый командой umask

Целостная система может содержать

несколько версий одного и того же пакета
пакеты с неудовлетворёнными зависимостями
конфликтующие пакеты
(Правильный ответ) необновлённые пакеты

Процесс, которому передан сигнал STOP (“^Z”)

немедленно запустит подпрограмму-обработчик данного сигнала, а если обработчика нет, то система сама обработает сигнал (завершит процесс)
(Правильный ответ) немедленно прекратит исполняться, но не будет удалён из таблицы процессов, ожидая сигнала к продолжению работы
немедленно прекратит исполняться и будет удалён из таблицы процессов

Виртуальный X-сервер отличается от обычного X-сервера

тем, что не принимает запросы от X-клиентов
адресом
(Правильный ответ) тем, что не связан с устройством графического вывода
тем, что запускается всегда на удалённой машине

Старший и младший номера устройства определяют

Начало и конец описателя устройства в таблицах ядра
(Правильный ответ) Какой драйвер системы и каким способом выполняет операции с этим устройством
Числа, которые программа должна использовать вместо дескриптора файла при операциях записи и чтения
Порядок, в котором устройства распознавались ядром

Идентификатор администратора системы (пользователя root) равен:

500
1
любой
(Правильный ответ) 0

Какая из перечисленных строк не может быть именем файла:

«{arch}«
(Правильный ответ) «year2001/April«
«…«

Чем отличается «таблица» межсетевого экрана iptables от «цепочки»?

(Правильный ответ) Цепочки iptables состоят из нескольких таблиц; покидая одну таблицу, пакет направляется в другую
Понятие «цепочка» использовалось только в предыдущей версии межсетевого экрана Linux — ipchains. В iptables его заменили более общим понятием «таблица»
Таблицы и цепочки следуют попеременно в произвольном порядке; по действию ACCEPT пакет может покинуть таблицу, но не цепочку
Таблицы iptables состоят из нескольких цепочек; покидая одну цепочку, пакет направляется в другую

В ответ на приглашение login: нужно ввести:

(Правильный ответ) входное имя
своё имя
числовой идентификатор пользователя

Пусть

$ ls -l -r—rw—w- 1 lead zinc 31244 Ноя 1 12:59 tin

Кто имеет доступ к файлу?

Пользователь lead — на чтение (при условии, что он не является членом группы zinc), члены группы zinc — на чтение и запись, все остальные — на запись
Пользователь lead — на чтение, пользователь zinc — на чтение и запись, пользователь tin — на запись
(Правильный ответ) Пользователь lead — на чтение, члены группы zinc (кроме пользователя lead) — на чтение и запись, все остальные — на запись
Пользователи lead и zinc — на чтение и запись (при условии, что они принадлежат группе tin, в противном случае — на запись), все остальные — на чтение

В момент исполнения команды

[methody@localhost methody]$ whomethody tty1 Sep 23 16:31 (localhost)methody2 tty2 Sep 23 17:12 (localhost)

в системе было зарегистрировано:

3 пользователя
(Правильный ответ) 2 пользователя
нельзя точно сказать, сколько пользователей
1 пользователь

Пусть

[methody@localhost methody]$ ls -li examples/text text-hardlink text-symlink127705 -rw-r—r— 2 methody methody 653 Сен 30 10:04 examples/text127705 -rw-r—r— 2 methody methody 653 Сен 30 10:04 text-hardlink 3621 lrwxrwxrwx 1 methody methody 13 Окт 4 18:05 text-symlink -> examples/text

К чему приведёт выполнение команды rm examples/text?

к удалению всех трёх файлов
к удалению файлов examples/text и text-hardlink
(Правильный ответ) к удалению файла examples/text
к удалению файлов examples/text и text-symlink

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

(Правильный ответ) /usr
/tmp
/home
/var

Ричард Столлман

Автор первой операционой системы, основанной на ядре Linux
Автор первого дистрибутива Linux
Автор первой версии ядра Linux
(Правильный ответ) Автор первого варианта GPL

Наличие в системе нескольких уровней выполнения позволяет

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

Чтобы на стандартный ввод команды cat, запущенной без параметров и дополнительных операций shell, попал символ “^V”

надо перенаправить стандартный ввод на файл, содержащий “^V”
(Правильный ответ) надо нажать его дважды
надо экранировать его с помощью “”
надо заключить строку в одинарные кавычки

Команда ifconfig выдаёт

Список MAC-адресов, однозначно идентифицирующих сетевые интерфейсы системы и связанную с ними информацию
Список ethernet-карт компьютера и их настроек
Список IP-адресов к

Источник

�� UNIX, ��
�� , ��
�� . � ��
��, ��
UNIX-��ٚ— ��
�� .

��

� �� UNIX-��
��. �� , �� �� 
�� �� , �� .

��

�� 7-01: ��

�� . ��
�� , ��
��, ��
��. �� , ��
��̣�� , ��
�� .

�� UNIX ��
�� (��˚3.1, «�� UNIX»):

�� 3.1. �� UNIX

�� ��

�� , ��
�� BIOS �� , ��
�� .

�� — �� (��, � ��
��), � �� , ��
�� -�� ţ. ��, ��, ��
�� ɚ— �� , ��
�� , ��
�� .

�� ��

��
�� — � �� . ��
�� (Master Boot Record)�— ��
��, � �� .

�� ՚—
� ��, � �� ; ��
� �� , ��
�� (��, �� , ��
�� ). �� , ��
�� — ��, ��
�� , ��
��.

�� ��

�� ˚— ��
��, ��
�� . �� , ��
��, ��
��. ��
�� , � ��
�� .

� �� ̣��
�� .

��
�� . ��
��, ��
�� , �� GRUB.

�� 

�� , ��Ϛ— �� ,
�� , ��, ��
�� , �� .

�� . � UNIX-��
��
�� .

��
�� : ��
��, �� , �� -��;
��
��.

��
�� : ��
�� (��), �� , ��
��, �� ך— ��
��-��, �� , �� , ��
�� .��.

�� , ��
��, �� ̚— �� , ��
�� / � �� (��
��
/etc, /bin,
� /sbin). ��
�� �� �
�� /. ��
�� Ӛ— init (��
��, /sbin/init).

�� init

� ��
�� . � UNIX ��
�� init, � �� .

�� init

�� 7-02: �� init

�� init ��
�� , �� : �� PID
�� 1, � �� ӣ ��, ��
�� .

� UNIX-�� init �� :

�� ٚ— �� , ��
�� , �� ,
�� , �� .��.;
�� Ś— ��
�� , �� UNIX ��
�� .

�� 3.2. �� UNIX

�� , �� UNIX ��
�� (��
fork()), � ��
�� init.

�� , �� init ��
�� /sbin/init � ��
��
UNIX-��. �� UNIX
� �� .

�� init

�� init ��
�� /etc/inittab. �� ģ� �� .

�� 3.1. �� /etc/inittab

# Default runlevel.
id:3:initdefault:

# System initialization, mount local filesystems, etc.
si::sysinit:/sbin/rc sysinit

# Further system initialization, brings up the boot runlevel.
rc::bootwait:/sbin/rc boot

l0:0:wait:/sbin/rc shutdown 
l1:S1:wait:/sbin/rc single
l2:2:wait:/sbin/rc nonetwork
l3:3:wait:/sbin/rc default
l4:4:wait:/sbin/rc default
l5:5:wait:/sbin/rc default
l6:6:wait:/sbin/rc reboot

# TERMINALS
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:2345:respawn:/sbin/agetty 38400 tty2 linux
c3:2345:respawn:/sbin/agetty 38400 tty3 linux
c4:2345:respawn:/sbin/agetty 38400 tty4 linux
c5:2345:respawn:/sbin/agetty 38400 tty5 linux
c6:2345:respawn:/sbin/agetty 38400 tty6 linux

# What to do at the "Three Finger Salute".
ca:12345:ctrlaltdel:/sbin/shutdown -r now

# Used by /etc/init.d/xdm to control DM startup.
x:a:once:/etc/X11/startDM.sh

�� , �� , ��:

�� (�� initdefault)�—
�� , � ��
��;
�� њ— ��
�� (0�— 6) �� , ��
��
��;
�� ך— ��
�� , ��
��;
��
�� Ctrl+Alt+Del�— ��
�� ;
�� , �� UNIX.

�� UNIX-��

�� UNIX �� : ��
UNIX �� AT&T (�� System V) � BSD UNIX, ��
�� . � �� , ��
�� UNIX �� :

�� System V�— �� UNIX System Group
(USG-��): AIX, Solaris, UnixWare, Linux (��
Red Hat, Mandriva, ALT Linux);
�� BSD: �� BSD, Linux (Slackware);
�� : Linux (Debian, Gentoo).

��, �� System V

�� 7-03: ��

�� ��  (run
level)�— �� . ��
�� (�� 0 �� 6), ��
�� .
� ��
�� њ—
�� init
� ��, �� , ��
�� .

�� 0: ��  (halt)�— ��
�� ;
�� 1: �� 
��ٚ— ��
�� (�� , ��) ��
�� . �� , ��
�� ;
�� 2: �� �—
�� , ��
�� ;
�� 3: �� �—
�� , � ��
�� ;
�� 4: �� ;
�� 5: �� �— �
�� 3 ��
X11 (��. «��»).
�� ;
�� 6: �� �— ��
��
��.

�� , ��
�� ̣��
�� ̣�� ,
�� . ��
�� . ��
��
�� /etc/rc.d.

�� 3-�
�� , � ��Ț— 5-�.

��, �� BSD

� �� �� 
��. �� (��
�� , ��
��), ��
�� .

��
�� /etc/rc. � ��
��
��, �� .��. ��
�� /etc/rc.local, ��
�� �� �� ,
�� .

��
�� . �� ,
�� BSD-��
�� .

��

�� UNIX-�� (� ��, ��
Linux) �� , ��
�� .

�� , �� Linux Debian
� Gentoo. �� �� 
(software run levels), ��
�� .

�� , ��
�� . ��
�� њ— default.

�� ��:
� ��, ��, �� , ��
��, � �� . �� , �
�� , �� , �� (��,
�� ). ��, ��
�� , ��
�� , ��
�� ͚— ��
��; ��
�� � �� .

�� , ��
�� . ��
��
�� .

�� ɚ— ��
�� Ț— �� System V-��.

��

�� 7-04: ��

��
�� (system services)�— ��
��, �� «��»
(��) �� . �� ,
��
�� (udevd), �� , ��
��
�� . �� , ��
�� . ��
�� ��  (init script)�— ��
��, �� , ��
�� .

��

� System V-��
�� /etc/init.d � ��
��: start, stop
�� restart. ��
��, �� , ��, �� .

��, ��
/etc/init.d/syslogd restart.

�� 3.2. �� 

desktop ~ # /etc/init.d/syslogd restart
 * Stopping syslog-ng ...                                    [ ok ]
 * Starting syslog-ng ...                                    [ ok ]  
desktop ~ #

�� , �� .

��

�� UNIX-�� System V-��
�� . �� ,
�� .

� �� /etc/rc.d/ ��
�� rc0.d,
rc1.d � �.�.�— ��
�� . � ��
�� , ��
��
�� .

�� : ��,
/etc/rc.d/rc0.d/K60crond
� /etc/rc.d/rc3.d/S40crond, ��
�� /etc/init.d/crond ��
�� . �� ,
�� K, ��
�� ,
� S�— �� . ��, �� ,
�� �� �� . ��,
�� /etc/rc.d/rc3.d/S34syslogd ��
�� /etc/rc.d/rc3.d/S40crond, ��
�� /etc/rc.d/rc3.d/K60crond
�� /etc/rc.d/rc3.d/K66syslogd. �� , ��
�� «��» �
«��» ��
100�— ��
�� .

�� , ��
�� , ��
�� System V �� chkconfig.

��

�� 7-05: �� : ��

� �� UNIX-�� , ��
�� . �� —
�� , ��
�� . ��
�� , ��
�� . ��
�� (��
��), �� /��
�� . ��
�� -��
(��, �� ).

�� ,
�� UNIX-��:

cron: �� ʚ— ��, ��
��̣��
(�� . «�� »);
syslog: �� — ��, ��
��
(�� . «�� »);
network: �� ɚ— ��
�� , �� .��. (��. «�� »);
iptables: �� Linux;
sshd, xinetd,
ftpd: �� , �� (��
��. «�� »);
sendmail: �� Қ— ��, ��
�� SMTP;
modules: ��, �� ;
local: ��, ��
�� ;
checkroot: ��, �� (�
�� , �� ).

�� .

��

�� 7-06: ��

�� Σ�� -��
� ��̣�� . � UNIX ��
��
�� cron.

�� , ��
�� crond. ��
� �� Ț— ��
��
(/etc/crontab), � ��
�� (�� crontab) ��
��. ��
��
�� ; ��
�� (��, cron).

��

�� :

��, ��, ��, �� , � �� ;
�� — �� .

� �� /etc/crontab ��
��:

�� 3.3. �� /etc/crontab

0    * * * *      rm -f /var/spool/cron/lastrun/cron.hourly
1    3 * * *      rm -f /var/spool/cron/lastrun/cron.daily
15   4 * * 6      rm -f /var/spool/cron/lastrun/cron.weekly
30   5 1 * *      rm -f /var/spool/cron/lastrun/cron.monthly
*/10 * * * *      /usr/bin/test -x /usr/sbin/run-crons && /usr/sbin/run-crons
*/5  * * * *      /usr/bin/vnstat -u
58   * * * *      rdate -ncav ptbtime1.ptb.de

�� — �� . ��
�� (�� , �� ) ��
�� , � �� .

��
�� crontab, ��
��
�� -e: crontab
-e�— � ��
�� crontab.

� ��ģ�� /etc/crontab �� ,
�� UNIX-��Ț—
�� /etc/cron.*. � ��
�� , ��
�� , �� , �� .�. ��.
��
�� : ��
��
crontab, ��
��
�� . ��
crontab � �� ,
�� ��  �� .

��

�� crond � ��
��. �� /etc/crontab
�� , ��,
��̣�� ϣ� ��
��e crontab, ��
�� .

��
�� .

� �� UNIX-��
�� (��, dcron,
fcron, anacron � �.��.), ��
�� .

��

�� 7-07: ��

� �� UNIX-�� , ��
�� . �� , ��
�� .

�� sshd: ��
�� sshd, ��
�� ݣ�� ̣��
��. �� , ��
�� ̣�� .
�� sendmail �� postfix: sendmail�— ��
��Σ�� . �� Internet-��,
�� (� ��
�� SMTP) �� , ��
�� Internet. �� ,
�� sendmail ��
�� . �� Σ��
�� postfix.
�� inetd: inetd (� ��
�� xinetd)�— �� -��,
�� . ��
�� : �� , ��
��
�� tcp-��. �� , ��
�� , �� .�. ��
�� inetd � ��
�� .
�� nfs � portmap: �� NFS (Network File
System), �� UNIX-��. ��
portmap, �� NFS, ��
��̣�� (RPC).
�� ntpd: �� , ��
�� ̣��
�� .
�� samba: samba�— ��
��
�� CIFS, ��
�� MS Windows. �� UNIX-��
� �� Windows.
�� cups: CUPS�— �� UNIX-��. ��
�� .
�� bind: bind
(�� named)�— ��
��Σ�� ͣ� �� UNIX.

��

�� ǚ— ��
��— ��
��, �� . ��
�� UNIX. ��
��ʚ— �� , ��
UNIX �� .

��

�� 7-08: ��

��
�� :

�� syslog()

�� UNIX �� ,
��
� �� , � ��
�� (syslog()), � ��
��
��, �� :
��-�� , �� ,
�� . ��
�� syslog() � ��
��
POSIX. ��
�� , ��
��
�� UNIX-��.

�� syslogd

��
��, ��
��, �� (syslogd), ��
�� , ��
�� .
��
�� (�� ) ��
syslogd /etc/syslog.conf.

��, �� , ��
��
��
��. ��, �� , ��
�� (�� ),
��
maillog. ��
��
�� .

�� /etc/syslog.conf

��
��
�� , ��
UNIX-��. ��
��
�� «��–�� »,
�� — ��
(��, ��, � �.�.). � ��
�� , �� ,
�� .

�� :

�� ;
�� , �� ;
�� (��: AUTH, DAEMON, FTP � �.�.);
�� (ALERT, ERR, WARNING, INFO � �.�.);
�� .

�� :

�� 3.4. �� /etc/syslog.conf

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
kern.*                                                  /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;		                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  /var/log/maillog


# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 *

��
��, ��, �� , ��
/var/log/maillog, ��
��ʚ— � ��
/var/log/secure, ��
��ʚ— � �� /var/log/cron, ��
��
/var/log/messages.

� ��
��, �� UNIX ��
�� (��, grep) � ��
��.

��

�� 7-09: ��

� UNIX-��
�� /var/log � ��
��. �� UNIX-��
�� :

authlog / security: �� , �� ,
�� , �� .�. (��
�� AUTH);
daemon: �� (�� DAEMON);
dmesg: � Linux-�� .
maillog / mail: �� , �� ģ��
�� (�� MAIL);
messages: � �� , ��
��;
xferlog: �� , ��
(�� FTP-��).

�� (��
��-�� Apache) ��
��. �� /var/log
(��, /var/log/apache/).

��

�� 7-10: ��

�� , �
�� . �� , ��
��, �� —
��
��. �� , ��
�� , ��
��ģ�� .

��
�� �� �—
�� ך— ��
�� .

�� :

�� (�� );
�� ;
�� ;
��
��.

�� (��, �� ) ��
�� ߣ�� (��, �� 1��). ��
�� ��_��.0, � ��
�� (�� .�.) ��
�� . ��:

desktop ~ # ls -l /var/log/authlog*
-rw-r-----  1 root  wheel   47986 Feb  6 15:56 /var/log/authlog
-rw-r-----  1 root  wheel   77783 Feb  6 03:00 /var/log/authlog.0.gz
-rw-r-----  1 root  wheel   25395 Jan 30 03:00 /var/log/authlog.1.gz
-rw-r-----  1 root  wheel   46940 Jan 23 03:00 /var/log/authlog.2.gz
-rw-r-----  1 root  wheel  166844 Jan 16 03:00 /var/log/authlog.3.gz
-rw-r-----  1 root  wheel   68078 Jan  9 03:00 /var/log/authlog.4.gz
-rw-r-----  1 root  wheel   45941 Jan  2 03:00 /var/log/authlog.5.gz
-rw-r-----  1 root  wheel   95279 Dec 26 03:00 /var/log/authlog.6.gz
-rw-r-----  1 root  wheel   34083 Dec 19 03:00 /var/log/authlog.7.gz

� �� , ��
�� . ��
�� .

��
��. ��
�� .

� �� Linux ��
logrotate. � �� UNIX-��
��, �� .

��

�� 7-11: ��

�� ģ��
��, ��
��
�� /var/log. �
�� , � ��
�� , � �� .

wtmp: �� . ��
��
�� last.
lastlog: ��
�� (� IP-��
�� ). ��
�� lastlog. ��
��
�� , ��Σ�� .
faillog: ��
�� . ��
�� faillog.

�� , ��
�� .

��

�� 7-12: ��

�� , ��
�� . ��
�� UNIX �� (init), ��
�� (��, �� .�.).

�� init �� UNIX. �� init
UNIX-�� , �� AT&T
System V � BSD UNIX. �� — ��
�� , ��
�� System V.

��, ��
��
�� �� .
�� System V
��, ��
�� , �� .

�� : �� (cron), ��
��, �� .

� UNIX �� : ��
��, �� .�. ��
�� .

�� : ��
��, ��
��, �� , ��
��, init, �� , �� , �� , ��
��, �� , ��

��

�� .�. �� UNIX.�—
�.: ��.��, 2004.�— 292 �.: ��.

��

��
UNIX?
�� init � UNIX?
��
�� /etc/inittab?
�� ? ��
�� UNIX-��, �� System V?
�� ? ��
�� UNIX-��, �� UNIX System V?
��
UNIX-��, �� UNIX System V?
�� ? ��
�� ?
��
�� cron?
�� UNIX.
�� UNIX?
�� ?
��
��?
��
� UNIX? �� .

��

�� 3.3. �� 7-01: �� 

�� 3.4. �� 7-02: �� init

�� 3.5. �� 7-03: �� 

�� 3.6. �� 7-04: �� 

�� 3.7. �� 7-05: �� : ��

�� 3.8. �� 7-06: �� 

�� 3.9. �� 7-07: �� 

�� 3.10. �� 7-08: �� 

�� 3.11. �� 7-09: �� 

�� 3.12. �� 7-10: �� 

�� 3.13. �� 7-11: �� 

�� 3.14. �� 7-12: ��

Источник

На главную -> MyLDP ->
Тематический каталог ->
Процесс начальной загрузки системы

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.

Если вам понравилась статья, поделитесь ею с друзьями:

Источник

Приветствую всех посетителей моего родившегося блога!

В своей первой статье опишу свои первые познания в ОС Linux. Недавно поменял место работы и по служебной необходимости пришлось внедрять в свой мозг новую для себя операционную систему Linux. Ранее приходилось сталкиваться с Linux только как на рабочей станции, даже без привязки к локальной сети. Максимум до чего дошли руки — устанавливать rpm пакеты, читая пошаговый HOWTO, изъятый из просторов гугла и с использованием менеджера пакетов synaptic. При этом настройка занимала громадную уйму времени…

До настоящего времени приходилось администрировать только сети на основе просящего много денег мелкософта. Но с последними тенденциями в сфере лицензирования и обращения особого внимания органов на отсутствие заветных наклеечек на компьютерах организации, а так же желании руководства сэкономить на программном обеспечении (а что, программы продаются чтоли? О_о (с) ) пришлось «сесть собаку» на вопросах лицензий и тем самым подтолкнул себя к более глубокому изучению продуктов ОпенСорса. К тому же на новой работе стоит старенький ALT Linux Compact 3 с почтовиком qmail и pptp сервером для удаленного доступа, которых хочется скорей переустановить, ибо клиенты умирают от спама, места для почты практически не осталось + хочется какой-нибудь небольшой корпоративный Жаббер да и еще кучу пожеланий….

В общем начал я изучение с самых основ. В данной статье размещу, как можно более понятную последовательную схему загрузки ОС Linux. Данная схема, скажем так, плод моих умозаключений, буду рад вашим комментариям и дополнениям!

Итак:

Описание 1 этапа:

Не углубляясь в кучу терминов и определений, данный этап можно описать следующими словами: BIOS из MBR (первые 512 байт диска, выбранного для загрузки) загружает First Boot Loader. FSB находит вторичный загрузчик, используя таблицу разделов, просматривая ее, обнаруживает активный раздел, после обнаружения этого раздела — загружает SSB в оперативную память и запускает его. Для корректной загрузки, активный раздел должен содержать каталог /boot, который должен находиться в начале диска и содержать Second Stage Boot Loader. В целом, SSB — это программа, которая выводит список вариантов загрузки (меню выбора загрузки операционной системы). Загрузчиком может быть LILO (более старый) или GRUB. Загрузчик берет свои настройки из конфигурационного файла (/etc/lilo.conf — для LILO и /boot/grub/grub.conf или /boot/grub/menu.lst — для GRUB). Существуют и другие версии загрузчиков, такие как syslinux, PXElinux, Isolinux, uBoot, но для наглядности, в статье я затронул только LILO и GRUB. Хочу отметить, что исторически (до появления загрузчиков LILO, GRUB и др. и когда образ ядра занимал объем не боле 1,44 Мб) данного этапа не существовало и загрузка происходила с дискеты без файловой системы, на которую был записан образ ядра Linux, который (образ) содержал в себе MBR, то есть BIOS загружал сразу образ ядра и передавал ему управление.

Описание 2 этапа:

Второй этап можно характеризовать так: подготовка системы для запуска служб демонов. При подготовке, Загрузчик загружает в память образ ядра из каталога /boot. Давайте рассмотрим пример образа ядра на примере ОС Debian 6:

boot@debian:~# file /boot/vmlinuz-2.6.32-5-686
/boot/vmlinuz-2.6.32-5-686: Linux kernel x86 boot executable bzImage, 
     version 2.6.32-5-686 (unknown@Debian) #, RO-rootFS, swap_dev 0x2, Normal VGA

В приведенном листинге, видно, что команда file выводит информацию о файле образа ядра. В данной информации говориться, что это ядро линукс (Linux kernel), 32-битной архитектуры (x86), содержащий возможность загрузки (boot), исполняемый (executable), в формате bzImage (то есть сжатое, бывают образы не сжатые), далее указывается версия ядра и кое-какие другие параметры образа. Данных файлов может быть несколько (в зависимости от количества установленных версий ядра) и для загрузки выбирается тот, который указан в настройках загрузчика. Образ ядра, инициализирует и подготавливает память, процессор/ы, остальное оборудование, монтирует корневой раздел в режиме только для чтения для загрузки остальной системы (устройство и раздел на котором размещен корень системы должен быть указан в настройках загрузчика GRUB (/boor/grub.conf) или LILO (/boor/lilo.conf)) в виде параметра root=. При этом, выводится сообщение VFS: Mounted root (ext2 filesystem) readonly. Кроме того, ядро из конфигурационного файла загрузчика получает параметры загрузки, такие как корневая файловая система, отображать сообщения ядра или нет и т.п. Параметры, переданные текущему загруженному ядру можно посмотреть в файле /proc/cmdline. Вот пример параметров все того же Debian:

boot@debian:~# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=6852e86c-b8f1-49d0-b1eb-9d10171083c3 ro quiet

Т.к. ядро Linux является модульным, то при загрузке может возникнуть необходимость подключить модуль ядра, который находится на еще не примонтированной файловой системе. Для решения данной проблемы при загрузке подгружается архив файловой системы (он же инициализационный RAM диск или initrd), содержащий в себе необходимый для загрузки набор модулей ядра. Вот так он выглядит для указанного выше ядра:

root@debian:~# file /boot/initrd.img-2.6.32-5-686
/boot/initrd.img-2.6.32-5-686: gzip compressed data, from Unix, last modified: Thu Mar 17 09:44:39 2011

Какой архив initrd подгружать при загрузке, так же указывается в FSB GRUB или LILO:

boot@debian:~# grep initrd -B4 /boot/grub/menu.lst
title           Debian GNU/Linux, kernel 2.6.26-2-686
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.26-2-686 root=/dev/sda1 ro quiet
initrd          /boot/initrd.img-2.6.26-2-686

Т.к. стандартный вывод (вывод сообщений на экран) должен быть связан с каким-либо процессом, соответственно с идентификатором процесса, а у ядра нет идентификатора, оно оно помещает сообщения ядра (и модулей) в буфер кольца ядра и выводит на экран. Данный буфер еще называется dmesg. Его содержимое можно просмотреть, выполнив команду dmesg. После полной инициализации ядро передает управление процеcсу init (первому системному процессу с PID=1). На экран выводится сообщение INIT: version 2.76 booting. При этом, бинарный файл init последовательно ищется в корневом разделе в каталогах: /sbin/init, /etc/init, /bin/init, если в указанных местах не обнаружен файл, то ядро пытается запустить шелл /bin/sh (это, собственно, есть однопользовательский режим загрузки, он же режим восстановления). При этом, не запускается ни один демон. Если не найден и шелл, то вываливается ошибка Kernel panic: No init found. Try passing init= option. Данная ситуация может возникнуть скорее всего, потому что неверно смонтирован корневой раздел.

Описание 3 этапа:

До текущего момента процесс запуска любой UNIX системы практически не отличался. Третий этап загрузки может отличаться в зависимости от платформы, будь то Linux, BSD, MacOS и др. Я подробно рассмотрю процесс загрузки операционной системы Linux с реализацией процесса запуска с помощью пакета sysvinit (так же именуемого System V — «систем 5«). В Linux в последнее время активно внедряется разработанный «убунтологами» пакет upstart, который приходит на смену SysV, данный процесс я так же кратко опишу и немного расскажу о загрузке BSD-систем.

На третьем этапе загрузки System V происходит следующее:

После запуска, процесс init, согласно конфигурации в файле /etc/inittab (а точнее строке, начинающийся на si::sysinit:/etc/……) первым делом выполняет скрипт /etc/rc.d/rc.sysinit (для RedHat) или /etc/init.d/rcS (для Debian), которые выполняют базовое конфигурирование системы (загрузка модулей, проверка корневой ФС и монтирование не чтение/запись, установка имени хоста, времени, монтирование оставшихся разделов, запуск сети, монтирование сетевых ФС и др.), а так же данный скрипт с помощью утилиты initlog направляет сообщения о загрузке в /var/log/messages. На данном этапе, нет уровня выполнения. Далее, запускается скрипт инициализации /etc/rc.d/rc (для RedHat) или /etc/init.d/rc (для Debian), которому передается уровень запуска в виде параметра от 0 до 6 (в соответствии с настройками из файла /etc/inittab, в котором указан уровень загрузки (выполнения) ОС по умолчанию и каталог /etc/rc*.d, в котором расположены скрипты запуска демонов/служб для соответствующего уровня запуска), запускает скрипты из каталога, соответствующего текущему уровню запуска.

Далее, процесс init согласно уровню загрузки просматривает каталог /etc/rc.d/rc0.d/ (в данном примере, цифра 0(ноль) в имени rc0.d соответствует уровню загрузки — нулевому), в котором содержатся симлинки (ссылки) на скрипты запуска системных служб, которые, в свою очередь, расположены в /etc/rc.d/init.d/ (для Red Hat) или в /etc/init.d/ (для Debian). Ссылки имеют следующий формат:

<S|K><число><имя_службы>, в котором: S — запуск службы (Start), K — остановка службы (Kill), <число> — число, определяющее последовательность запуска служб (00 — самая первая), <имя_службы> -имя запускаемой службы.

Уровни выполнения бывают следующие:

0: полная остановка машины;
1: single-user (однопользовательский) режим; (используется в случае серьезных проблем или для восстановления системы)
2: multi-user (многопользовательский) режим, без поддержки сети;
3: Мulti-user (многопользовательский) режим с поддержкой сети; (используется преимущественно на серверных системах)
4: неиспользуемый;
5: Мulti-user (многопользовательский) режим с поддержкой сети + графический интерфейс для входа в систему (login);
6: перезагрузка.

При этом, в разных дистрибутивах, возможны вариации уровней загрузки. Дистрибутив Slackware использует уровень выполнения 4 вместо 5 для полного запуска системы X Window. Debian использует один уровень выполнения для любого многопользовательского режима, обычно это уровень 2.

После запуска всех демонов, содержащихся в каталоге /etc/rc.d/rc0.d/, процесс Init запускает сценарий /etc/rc.d/rc.local (для RedHat) или /etc/rc.local (для Debian). В данном сценарии можно разместить свои настройки, которые вступят в силу после запуска всех демонов.

Далее, процесс Init запускает процесс mingetty, который запрашивает имя пользователя (о расположении mingetty, также сказано в файл /etc/inittab). После ввода имени пользователя, mingetty передает введенную информацию процессу login. Процесс login просматривает файлы /etc/passwd и /etc/shadow на наличие указанного пользователя и выводит запрос пароля. После ввода пароля пользователя, процесс login сравнивает хеш пароля с данными в файле /etc/shadow и в случае совпадения, запускает шелл.

Указанный процесс актуален для входа в текстовую консоль, при входе в графическую оболочку, вместо mingetty, процесс init запускает процесс gdm (для GNOME) или kdm (для KDE), в зависимости от того, какой оконный менеджер установлен в системе. gdm (или kdm) запускает X-сервер и выводит окно аутентификации.

После успешной аутентификации, просматривается файл конфигурации /etc/group, который определяет принадлежность пользователя к группам. А так же запускается стартовый конфигурационный сценарий /etc/X11/gdm/PreSession (для X-сервера) и конфигурационные стартовые скрипты (/etc/profile и др.) для bash, которые устанавливают настройки окружения пользователя.

Уровнем выполнения можно управлять с помощью команд.

На третьем этапе загрузки Upstart происходит следующее:

Давайте немного затронем вопрос загрузки новой системы Upstart, которая введена в действие с Ubuntu 7.10 и старше, Fedora 9, RHEL 6, планируется в Debian, …? (если есть другие дистрибутивы с uppstart, буду рад комментариям об этом). Основное отличие upstart от system V в том, что работа upstart основана на обработке событий. К стати будет сказано, что одной из основных задач внедрения upstart была — уйти от последовательного запуска сервисов в SysV, тем самым ускорить загрузку ОС, сделав процесс запуска служб параллельным. Итак, система upstart при запуске, процессом init генерируется событие startup (запуск — одно из двух основных событий) — старт системы, а событие shutdown — при выключении системы. Другое ключевое событие — это ctrlaltdel, которое указывает, на то, что вы нажали клавиши Ctrl-Alt-Delete. В соответствии с событием генерируемым процессом init, обрабатываются конфигурационные фалы (*.conf) из каталога /etc/init/ (в более старых версиях upstart — каталог /etc/event.d/). В этом, собственно, и заключается вся работа upstart. Для обратной совместимости с System V существует файл /etc/init/rc.conf, который запускает демоны, согласно SysV.

Давайте рассмотрим содержимое файлов /etc/init/*.conf. Каждый из файлов должен содержать start on event (по какому (on) событию (event) осуществлять запуск (start) службы), stop on event (по какому событию останавливать запуск службы), exec либо script (что, собственно, запустить по указанному выше событию). Наиболее часто применяемые события в конфигурационных файлах — это startup, runlevel, stopped и started. startup — это событие запуска операционной системы, runlevel (с указанием уровня или нескольких уровней) — событие при смене уровня запуска, stopped — событие после остановки задания, started — событие после завершения старта задания. Просмотрев конфигурационные файлы в каталоге /etc/init/ можно найти и другие события, о которых можно почитать в man upstart-events (7). В дополнение к стандартным записям exec и script существуют записи pre-start и post-stop, реализующие выполнение подготовительных действия до выполнения exec и завершающие после завершения exec.

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

Для отключения автоматического запуска службы в Upstart, необходимо:

Переименовать конфигурационный файл запуска службы в каталоге /etc/init в файл без расширения «.conf».
Или закомментировать строку «start on» с помощью символа ‘#’.

На третьем этапе загрузки BSD происходит следующее:

Перед описанием 3 этапа загрузки BSD хочу отметить, что по-умолчанию на 1 этапе используется загрузчик BSD Loader, работа которого аналогична любому другому загрузчику и тоже разбита на подэтапы (загрузка FSB, SSB и т.д.). Файл конфигурации BSD Loader расположен в /boot/loader.conf. Соответственно, после запуска BSD Loader, происходит передача управления ядру и запуск процесса /sbin/init. Дальше запуск несколько отличается от Linux, т.к. в BSD нет понятия runlevel, то есть существует единый уровень исполнения. НО в BSD есть 2 режима загрузки — однопользовательский (режим восстановления) и многопользовательский.

В однопользовательском режиме загрузка происходит:

при выборе соответствующего пункта (Boot in single user mode) в меню начального загрузчика,
при задании команды boot -s в командной строке загрузчика (после выбора пункта его меню Escape to loader prompt),
при обнаружении серьезных (неустранимых автоматически) нарушений целостности файловой системы в ходе ее проверки на первой стадии инициализации.

При загрузке в однопользовательском режиме происходит запуск оболочки без пароля с правами суперпользователя и монтирование корневой ФС только на чтение. Запуска сценариев инициализации не происходит.

При загрузке в многопользовательском режиме, как и в Linux, выполняется 2 этап загрузки. На 3 этапе в BSD задача процесса init аналогична — это вызов и отработка сценариев инициализации, или стартовых скриптов, собранных в каталоге /etc и его подкаталогах и получение терминала (запуск процесса getty), установка его свойств и подготовка к аутентификации и авторизации (ввод логина/пароля) и последующее вытеснение getty процессом login. Отличие BSD в том, что в BSD имеет свои стартовые скрипты, отличные от Linux.

Основной стартовый скрипт -это /erc/rc, настройки применяемые по умолчанию для скрипта /etc/rc процесс init считывает, из файла /etc/defaults/rc.conf, а настройки, специфичные для текущей системы, из /etc/rc.conf, после чего осуществляется монтирование файловых систем, перечисленных в файле /etc/fstab, запуск сетевых служб, различных системных даемонов и, наконец, выполнение скриптов запуска дополнительно установленных пакаджей. Строки /etc/rc.conf имеют вид параметр=»значение» (точнее service_name_enable=»YES/NO»). Соответственно, service_name_enable — это имя службы, которое должно соответствовать имени скрипта запуска службы из каталога /etc/rc.d/* (/etc/rc.d/service_name_enable, например /etc/rc.d/sshd) или /usr/local/etc/rc.d/* — для ПО установленного из портов, значение yes или no соответственно включает или выключает службу.

Некоторые дополнительные системные сервисы могут быть не учтены в файле /etc/rc.conf. Тогда для их запуска нужно прописать соответствующую команду в /etc/rc.local

Не записывайте свои команды в /etc/rc.conf. Для запуска демонов, или для выполнения вашей команды во время запуска — запишите ваш скрипт в /usr/local/etc/rc.d.

Процесс остановки системы BSD

Во время контролируемого процесса остановки системы через утилиту shutdown программа init будет пытаться запустить скрипт /etc/rc.shutdown, после чего будет посылать всем процессам сигнал TERM, а затем и KILL тем процессам, которые не завершили работу.

Итого, в BSD процесс загрузки до ужоса прост — запуск скрипта /etc/rc согласно настроек /etc/rc.conf, в котором прописано, какие скрипты запуска демонов из /etc/rc.d/* необходимо запустить, а какие — нет и финалом загрузки является скрипт /etc/rc.local.

Маленький итог:

В данной статье я постарался, как можно прозрачней описать процесс запуска операционных систем UNIX, в том виде, в каком я его понял. Некоторые пособия/статьи разделяют загрузку на большее количество этапов. Я постарался изложить так, чтобы прочитав статью, можно было понять процесс загрузки UNIX не вчитываясь в кучу других материалов. Конечно, никто не запрещает углубиться в изучение процесса загрузки ОС, благо в интернете их достаточно. Жду комментариев и дополнений.

Что еще почитать:

Про Upstart:
1. http://help.ubuntu.ru/wiki/upstart
2. http://upstart.ubuntu.com/
Загрузка FreeBSD из официального руководства: http://www.freebsd.org.ru/handbook/boot.html
Перевод /etc/defaults/rc.conf: http://www.lissyara.su/articles/freebsd/tuning/rc.conf/
man init для FreeBSD: http://www.opennet.ru/man.shtml?topic=init&category=8
man rc для FreeBSD:http://www.opennet.ru/man.shtml?topic=rc&category=8
BSD-системы: загрузка и инициализация: http://alv.me/?p=354

upd 2011.01.21: переработано и дополнено описание 3 этапа загрузки
upd 2011.06.10: дополнено описание 1 и 2 этапа загрузки
upd 2011.06.12: переработка и дополнение всех этапов загрузки, добавление процесса загрузки upstart и ОС BSD.
upd 2011.06.27: Дополнение 1 и 2 этапа загрузки.

С Уважением, Mc.Sim!

Теги: GRUB, init, LILO, Linux, SysV, основы

Источник

Стартовый виртуальный диск и модули ядра

Отец всех процессов

Запуск системных служб

Чему служат демоны?

Стартовый сценарий системной службы

Схема «. d»

Уровни выполнения

Загрузка типичной системы на уровень выполнения 5

Запуск системных служб

Чему служат демоны?

Стартовый сценарий системной службы

Схема «.d»

Стартовый сценарий системной службы

Текущий каталог определён для:

Пользователь root — это

Репозиторий пакетов — это

Программа last выводит:

Какой результат выведет на терминал команда cd; echo $??

В оконном интерфейсе субъектом с точки зрения системы является

Как, редактируя текст в Emacs, вырезать текущий абзац (в котором находится точка) и вставить его в самый конец текста?

Термином «подстановка» в shell обозначается

Что входит в ярлык объекта файловой системы?

Каталог /var предназначен для

Процесс, которому передан сигнал INT (“^C”)

Монтирование файловых систем не позволяет

Какая из перечисленных команд не имеет отношения к справочной подсистеме Linux?

Какой список файлов может сгенерировать shell по шаблону

Назначать маршрутизатор по умолчанию следует при помощи

Система подготовки печатной документации LaTeX

Сколько ключей передано утилите в команде

При запуске процесс получает

Пусть

Каков адрес сети, в которую входит компьютер с IP-адресом 192.168.0.13 и сетевой маской 255.255.255.0?

Основное средство взаимодействия пользователя и ОС Linux

Могут ли в Linux существовать устройства, доступные на запись любому пользователю?

“/home/methody/examples” — это:

Стартовый сценарий системной службы

Файлу какого типа соответствует строка атрибутов “crw-rw—-”?

Большинство фильтров Linux работают с

Мефодий неудачно попытался запустить программу xterm, получив сообщение “cannot open display:”. В чём, скорее всего, была причина ошибки?

В какой кодировке могут быть записаны русские имена файлов в Linux:

Первым широко распространённым некоммерческим дистрибутивом Linux стал

Название утилиты gimp расшифровывается как

Команда who предназначена для

В файловой системе Linux

Как в bash узнать, является ли команда cmd сокращением, и если да, то во что она будет раскрыта?

Для того, чтобы запустить несколько приложений с текстовым интерфейсом на удалённом компьютере, необходимо

Программа k3b предназначена для

Запуском исполняемых программ в Linux занимается

Менеджер пакетов занимается

Если в X Window System окно получило фокус, это означает, что

В файле /etc/services содержится

Команда tr предназначена для

Программа inkscape предназначена для

Зависимость одного rpm-пакета от другого означает, что

Какой список файлов может сгенерировать shell по шаблону *r*[cC]

Для определения прав доступа процесса к объекту файловой системы не требуется

При редактировании конфигурационных файлов

Альтернативы пакетов применяются, когда необходимо, чтобы

Какие пакеты можно успешно передавать через сервер подмены сетевых адресов (NAT)?

Текстовый редактор нужен, чтобы

Стандарт FHS рекомендует размещать домашние каталоги пользователей:

Многопользовательская организация системы не позволяет

Необходимость в дистрибутивах Linux возникла, когда

Мефодий «ухватил» окно xterm за уголок и увеличил его. Какие программы, помимо xterm, были в этом задействованы.

Какую из перечисленных задач не выполняет X-сервер?

Каковы обязанности метадемона inetd?

Конфликт двух пакетов происходит в случае, когда

Как связаны символьная ссылка и файл, на который она указывает?

Что такое «подмена идентификатора»?

Целостная система может содержать

Процесс, которому передан сигнал STOP (“^Z”)

Виртуальный X-сервер отличается от обычного X-сервера

Старший и младший номера устройства определяют

Идентификатор администратора системы (пользователя root) равен:

Какая из перечисленных строк не может быть именем файла:

Чем отличается «таблица» межсетевого экрана iptables от «цепочки»?

В ответ на приглашение login: нужно ввести:

Пусть

В момент исполнения команды

Какой список файлов может сгенерировать shell по шаблону r[cC]

��

��

��

�� init

�� init

�� UNIX-��

��, �� System V

��, �� BSD

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��