Начальная загрузка ОС Unix

9. Начальная загрузка ОС Unix

Начальная загрузка. Этапы загрузки. Базовая инициализация ядра и создание "спонтанных" процессов. Командные файлы запуска Unix. Работа в многопользовательском режиме. Запуск процессов обслуживания терминалов.

Особенности загрузки BSD и ATT систем.

Командные файлы запуска BSD систем (командный файл загрузки /etc/rc, глобальный конфигурационный файл /etc/sysconfig; запуск сети - /etc/netstart; запуск локальных прикладных систем - /rc. local). Форматы командных и конфигурационных файлов.

Контроль за текущими процессами в Unix (команда ps).

Процессы-демоны (init, initd, portmap, pagedaemon, swapper, nfsd, ftpd, telnetd).

Остановка ОС Unix: команды shutdown, reboot.

9.1. Начальная загрузка

UNIX - сложная операционная система, и процедура ее загрузки и останова не сводится к простому нажатию кнопки питания.

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

Примечание. Далее мы будем говорить об операционной системе FreeBSD, работающей на компьютерах с процессорами х86 компании Intel.

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

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

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

Обычно процесс начальной загрузки состоит из шести этапов:

·  загрузка и инициализация ядра;

·  распознавание и инициализация аппаратных средств;

·  создание спонтанных (не с помощью системного вызова fork()) системных процессов;

·  выполнение командных файлов запуска системы.

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

9.1.1. Загрузка и инициализация ядра

При включении компьютера на нем автоматически запускается тест, который называется POST (Power On Self Test - Самотестирование при включении питания).

На этом этапе в проверке работы аппаратного обеспечения компьютера также принимает участие BIOS (Basic Input/Output Services - Базовые службы ввода/вывода), представляющий собой небольшое по объему программное обеспечение, которое зашито в микросхеме ПЗУ на системной плате компьютера. BIOS находит объем оперативной памяти и устройства РnР, чтобы определить, какие ресурсы они могут использовать.

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

Начальная загрузка - это многоэтапный процесс, который начинается с этапа boot0.

Этап boot0. BIOS считывает содержимое сектора 0 жесткого диска, с которого выполняется начальная загрузка. Сектор 0 называют также главной загрузочной записью (Master Boot Record, или MBR). Программа, расположенная в MBR, имеет длину всего 512 байтов. Она содержит информацию о диске, позволяющую вывести на экран меню разделов данного диска, с которых можно выполнить начальную загрузку. Вот пример информации программы boot0:

Fl DOS

F2 FreeBSD

F3 Drive 1

Default: F2

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

Этап bootl. Программа bootl находится в первом секторе загружаемого раздела. Как и программа boot0, она имеет в длину 512 байтов. Ее задача - найти и загрузить программу bootl.

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

Этап boot3. Обычно программа-загрузчик хранится в каталоге /boot/loader. Она позволяет изменять различные параметры запуска операционной системы FreeBSD, в частности, выбирать ядро, которое должно быть загружено. Стандартное ядро обычно находится в каталоге /boot/kernel. Итак, загрузчик находит и загружает ядро операционной системы и передает ему управление. На этом начальная загрузка заканчивается.

9.1.2. Распознавание и инициализация аппаратных средств компьютера

Стандартное ядро управляет всеми обращениями к аппаратным ресурсам со стороны программ и пользователей.

Сообщения, видимые на экране при запуске FreeBSD, представляют собой сообщения ядра, которые информируют о том, что ядро находит и инициализирует аппаратные средства компьютера. Большая часть этих сообщений пробегает по экрану слишком быстро. Но после регистрации и входа в систему можно воспользоваться командой dmesg | more и просмотреть эти сообщения; переход к следующей странице сообщений осуществляется нажатием клавиши "пробел". Ниже в качестве примера приводятся некоторые сообщения ядра системы.

Copyright The FreeBSD Project.

Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994

The Regents of the University of California. All rights reserved.

FreeBSD 5.0-CURRENT #0: Sun Apr 8 15:17:26 CDT 2001

*****@***samplenet. org:/usr/obj/usr/src/sys/SIM&A

Первые три строки в объяснениях не нуждаются. Это просто информация об авторских правах. В четвертой строке дается название операционной системы и версия ядра. В ней также указывается дата и время сборки ядра.

Первая часть пятой строки содержит имя и локальный электронный адрес пользователя, собравшего ядро.

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

CPU: AMD-K6(tm) 3D+ Processor (400.91-MHz 586-dass CPU)

Origin = AuthenticAMD Id = 0х591 Stepping = 1

Features=0x8021bf<FP0,VME, DE, PSE, TSC, MSR, MCE, CX8,PGE, MMX>

AMD Features=0x<SYSCALL,3DNow!>

Данные строки описывают тип процессора и содержат некоторую информацию о его возможностях.

psm0: <PS/2 Mouse> irq 12 on atkbdc0

psm0: model Generic PS/2 mouse, device ID 0

fdc0 <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq б drq 2 on isa0

fdc0: FIFO enabled, 8 bytes threshold

fd0: <1440-KB 3.5 drive> on fdc0 drive 0

Ядро обнаружило мышь типа PS/2. Мышь является устройством с именем psm0. Также были обнаружены контроллер накопителей на гибких дисках и накопитель на гибких дисках. Имя контроллера - fdc0, а имя самого накопителя - fd0.

sbc0: <Creative SB AWE64> at port 0x220-0x22f,0х330-0х331,0x388--0x38b

irq 5 drq 1,5 on isa0

pcml: <SB16 DSP 4.16> on sbc0

Ядро нашло звуковую плату SoundBlaster AWE 64 и выдало информацию об используемых этой платой ресурсах. Обратите внимание, что в данном случае sbc0 - это имя группы устройств, связанных с данной звуковой платой.

<PNP0303> can't assign resources

<PNP0f13> can't assign resources

<PNP0501> can't assign resources

<PNP0700> can't assign resources

<PNP0401> can't assign resources

<PNP0501> can't assign resources

Некоторые из этих сообщений можно увидеть на экране компьютера во время запуска FreeBSD. Они означают, что ядро обнаружило в системе некоторые устройства Plug and Play, но они ему неизвестны, поэтому оно не может выделить им ресурсы. Наличие этих сообщений не влияет на стабильность системы.

ad0: 19473MB <Maxtor 92049U6> [39566/16/63] at ata0-master UDMA33

ad1: 14664MB <IBM-DJKA-351520 [29795/16/63] at ata0-slave UDMA33

Ядро нашло накопители на жестких дисках и выдало информацию об имени накопителя, его объеме, производителе, модели, геометрии и о том, к какому контроллеру подключен накопитель. Оно также сообщает, какой режим доступа использует накопитель. В данном случае оба накопителя используют Ultra DMA 33.

Mounting root from ufs:/dev/ad0s1a

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

Примечание. Когда операционная система FreeBSD закрывается (останавливается) надлежащим образом, то она выполняет для каждого диска программу sync (запись блоков данных из кэша на диск), демонтирует файловые системы и устанавливает для этих файловых систем флажок clean (чисто). Если операционная система FreeBSD будет закрыта (остановлена) некорректно, то флажок clean установлен не будет.

Одно из первых действий, выполняемых процессом init, - это проверка того, установлен ли флажок clean. Если флажок установлен, процесс init монтирует файловую систему для использования. Если флажок не установлен, процесс init запускает программу fsck; она проверяет, не повреждена ли файловая система, и исправляет все ошибки, которые в состоянии исправить. Программа fsck подобна программе Scandisk из операционной системы Windows и данный процесс напоминает процедуру Your system was not properly shut down («Ваша система не была закрыта надлежащим образом») в Windows. Если программа fsck обнаруживает ошибку, которую не может исправить, она переводит систему в однопользовательский режим, чтобы это мог сделать системный администратор.

Если флажок clean был установлен, то процесс init приступает к монтированию всех перечисленных в файле /etc/fstab файловых систем, для которых установлен флажок mount at boot (монтировать во время загрузки).

9.1.3. Создание спонтанных процессов

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

Число и характер этих процессов зависит от типа операционной системы.

В FreeBSD создаётся три процесса:

swapper PID = 0

init PID = 1

pagedaemon PID = 2

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

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

9.1.4. Выполнение инициализационных командных файлов запуска Unix

По завершении загрузки ядра оно передает управление первому пользовательскому процессу - init, запускаемому одноименной программой, расположенной в каталоге /sbin.

Программа init во FreeBSD выполняет только один, главный сценарий - /etc/rc. Он, в свою очередь, запускает остальные сценарии, которые расположены в каталоге /etc и носят имена вида rc.имя. Эти файлы, по сути, представляют собой обычные командные файлы, и для их выполнения процесс init запускает интерпретатор команд sh.

Сценарий /etc/rc начинает свою работу с выполнения трех сценариев, определяющих конфигурационную информацию:

/etc/defaults/rc. conf

/etc/rc. conf

/etc/rc. conf. local.

В этих файлах задаются другие каталоги, в которых необходимо искать стартовые сценарии (имена каталогов заносятся в переменную local.startup). Кроме того, в них определяется ряд переменных интерпретатора shell, используемых последующими сценариями. Сценарий /etc/rc применяет команду source (точнее, ее оригинальный псевдоним '.'), чтобы преобразовать конфигурационные и все последующие сценарии в единый поток выполнения.

Чаще всего инициализационными командными файлами выполняются следующие задачи:

·  установка имени компьютера;

·  установка часового пояса;

·  проверка файловых систем командой fsck;

·  удаление файлов из каталога /tmp;

·  конфигурирование сетевых интерфейсов;

·  запуск процессов-демонов и сетевых служб;

·  включение учёта и контроля квот.

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

Примечание. Файл /etc/defaults/rc. conf содержит огромный перечень всех конфигурационных параметров и их стандартных значений. Его нельзя редактировать. Если требуется изменить значение какой-либо переменной, просто переопределите ее в файлах /etc/rc. conf и /etc/rc. conf. local.

Файл /etc/rc.conf, генерируемый в процессе установки программой /stand/sysinstall, описывает установленные пользователем отклонения от умолчаний, заданных в файле /etc/defaults/rc. conf. Изменения в нем могут быть сделаны в любой момент.

В каталоге /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 work rc. shutdown rc. suspend

Все эти сценарии могут быть вызваны из главного сценария /etc/rc.

Если какой-то сценария не определен, он просто пропускается.

Стандартный сценарий rc.serial ничего не делает, а лишь определяет набор функций, которые позволяют инициализировать последовательные порты и устройства на этапе загрузки.

Сценарий rc.network инициализирует сетевую среду компьютера. Он использует переменные, определенные в файлах rc. conf, для конфигурирования сетевых интерфейсов, протоколов DHCP и РРР, маршрутизаторов и брандмауэров. Редактировать этот сценарий нет необходимости, так как все параметры содержатся в файлах rc. conf. Он вызывает другие сетевые стартовые сценарии: rc. atm, rc. isdn и re. firewall.

До недавнего времени в конце работы сценария /etc/rc выполнялся сценарий /etc/rc/local, в котором запускались службы, характерные для данного узла. Однако сейчас поддерживается механизм запуска служб с помощью стартовых скриптов из каталога /usr/local/etc/rc. d.

Примечание. Если Вы привыкли использовать сценарий /etc/rc для запуска «локальных» служб, то им можно пользоваться и дальше. Работа с этим сценарием поддерживается наравне с механизмом запуска скриптов из каталога /usr/local/etc/rc. d.

Скрипты из каталога rc. d автоматически запускаются во время загрузки или останова Unix. Во время загрузки скрипты из каталога rc. d запускаются сразу же после завершения работы скрипта /etc/rc. local.

Условия выполнения скриптов из каталога /usr/local/etc/rc. d:

·  имя скрипта должно соответствовать шаблону *.sh и он должен быть «исполнимым».

Примечание. Скрипты, не соответствующие этим условиям, «тихо игнорируются».

·  когда скрипт выполняется во время загрузки, ему передается параметр “start”. Во время останова системы скрипту передается параметр “stop”.

·  скрипты выполняются в лексикографическом порядке. Если необходимо этот порядок изменить, то можно использовать в названии скрипта числа (скрипт 10example. sh будет выполняться перед скриптом 20 example. sh).

Примечание. По умолчанию каталог rc. d находится в каталоге /usr/local/etc. Имя этого каталога можно задать в переменной local_startup в файле /etc/rc. conf.

Ниже приводится пример шаблона скрипта запуска произвольной службы (example. sh):

#!/bin/sh -

#

# Пример скрипта для запуска/остановки произвольной службы

case "$1" in

start)

/usr/local/sbin/foo - d && echo - n ' foo'

;;

stop)

kill `cat /var/run/foo. pid` && echo - n ' foo'

;;

*)

echo "unknown option: $1 - should be 'start' \

or 'stop'" >&2

;;

esac

9.1.5. Запуск процессов обслуживания терминалов

После выполнения стартовых скриптов (сценариев) процесс init запускает программу консоли (и программы нескольких виртуальных терминалов). Как правило, это программа getty. Другая программа, часто используемая вместо getty, - это xdm, она сразу же после загрузки системы запускает графический сеанс X-Window.

В файле /etc/ttys задается, какая именно программа будет запускаться. Будем считать, что в нашем случае это getty.

Программа getty инициализирует терминал и устанавливает различные параметры, относящиеся к типу терминала и безопасности системы. Напомним еще раз, что эти параметры и их значения задаются в файле /etc/ttys. Затем getty запускает программу входа в систему - login, которая проверяет правильность регистрационного имени пользователя и пароля.

9.2. Вход во FreeBSD

Когда все процессы запуска операционной системы завершатся, вы увидите на экране следующую информацию:

FreeBSD/i386 (host1) (ttyp0)

login:

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

Введите регистрационное имя обычного пользователя, которое вы назначили себе во время установки. Нажмите Enter и при появлении приглашения введите пароль. Обратите внимание, что пароль не будет отображаться на экране.

После того как вы введете пароль, программа входа в систему сравнивает его с паролем, хранимым в базе данных. Если сравнение пройдет успешно, вы увидите на экране что-нибудь вроде:

Last login: Tue Apr 10 15:19:17 on ttyp0

Copyright 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994

The Regents of the University of California. All rights reserved.

FreeBSD 5.0-RELEASE (GENERIC) #0: Sun Apr 8 15:17:26 CDT 2001

bash$

Если это ваш первый вход в систему в качестве обычного пользователя, вы, по-видимому, не увидите первую строку с информацией о последнем входе в систему (Last Login). Однако при последующих подключениях к системе эта строка будет присутствовать всегда.

Предупреждение. Обязательно обращайте внимание на информацию о последнем входе в систему. Если, например, данная строка информирует вас о том, что время последнего подключения - это Sat Sept 15 14:05:29, а вы в этот день отдыхали за городом и наверняка не работали, это значит, что кто-то посторонний хозяйничал в системе, пользуясь вашими учетными данными. В этом случае НЕМЕДЛЕННО меняйте пароль (воспользуйтесь командой passwd) и поставьте в известность системного администратора о взломе защиты.

Остальная информация - это информацией об авторских правах и о ядре (когда оно было собрано). Последняя строка - это приглашение командного интерпретатора. Операционная система FreeBSD ждет от вас ввода команды.

Предупреждение. Обратите внимание на различие между нынешним приглашением и тем, что было в прошлый раз, когда вы регистрировались и входили в систему как пользователь root. У пользователя root приглашением является символ фунта - #. У обычного пользователя приглашением, как правило, является либо $ (в стиле командного интерпретатора Борна), либо % или > (в стиле командного интерпретатора С). Когда вы входите в систему как пользователь root, решеточка (#) постоянно напоминает вам о необходимости быть внимательным при вводе потенциально опасных команд.

Если вы неправильно введете регистрационное имя или пароль, операционная система выдает в ответ следующее сообщение:

Login incorrect

login:

В этом случае попытайтесь снова ввести свои регистрационные данные.

Совет. Если три раза подряд неправильно ввести регистрационное имя или пароль, то создается впечатление, что система зависла. На самом деле это не так. Эта задержка - средство защиты, помогающее резко снизить эффективность программ разгадывания паролей, пытающихся взломать защиту. С каждой последующей неудачной попыткой задержка может увеличиваться в определенной прогрессии. Так что подождите несколько секунд и приглашение login: появится снова.

9.3. Выход из FreeBSD

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

Чтобы выйти из FreeBSD, введите exit в командной строке.

На экране вновь появится приглашение на ввод регистрационного имени, которое вы видели при загрузке FreeBSD.

Совет. Перед выходом из системы неплохо было бы очистить экран. Для этого введите в командной строке clear. После этого выходите из системы, как было описано выше.

9.4. Останов FreeBSD

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

Команда shutdown

Правильный останов (закрытие) системы осуществляется с помощью команды shutdown. Синтаксис команды shutdown имеет следующий вид:

shutdown [действие] [когда] [широковещательное сообщение]

Первый параметр означает действие, которое должна выполнить команда shutdown, второй указывает время, когда это действие будет выполняться, а третий параметр представляет собой сообщение, которое будет послано всем пользователям, зарегистрированным в данный момент в системе. В таблице 9.1 перечислены все параметры, которые могут использоваться для обозначения действия, выполняемого командой shutdown:

таблица 9.1 Параметры команды shutdown

Действие	Что означает
не указано	Отключает всех пользователей и переводит систему в однопользовательский режим.
-h	Останавливает систему
-p	Останавливает систему и выключает электропитание (если это аппаратно и программно возможно).
-r	Перезагружает систему.
-k	Отключает всех пользователей и запрещает регистрацию и вход в систему (за исключением root). Однако система остается в многопользовательском режиме и подключенной к сети.
-o	Закрывает систему, не посылая сигнал процессу init. Это не очень хорошо, поскольку в этом случае не запускаются сценарии, закрывающие отдельные программы.
-n	Если при этом задан также и параметр -о, то перед закрытием кэш файловой системы (диска) не будет сбрасываться на диск. Это может привести к потере данных.

Временные параметры команды shutdown могут быть заданы несколькими способами. Ключевое слово now означает, что действие должно быть выполнено немедленно. Возможен также формат +n, где п указывает через сколько минут будет выполнено указанное действие (это дает пользователям время сохранить файлы и закрыть программы). Допустим и формат yymmddhhmm, позволяющий задать точное время выполнения действия. Здесь уу - год, mm - месяц, dd - день, hh - часы (в 24-часовом формате) и mm - минуты. Если год и месяц не заданы, то это означает, что действие должно быть выполнено сегодня. Если вы зададите время, которое уже прошло, то на экране появится сообщение, предупреждающее об этом.

Часть команды shutdown, называемая "широковещательным сообщением", представляет собой предупреждение, которое через регулярные интервалы времени посылается всем подключенным к системе пользователям. Эти сообщения начинают передаваться за 10 часов до предстоящего закрытия системы и становятся все более частыми по мере приближения момента закрытия.

Ниже дан типичный процесс закрытия системы, в данном случае с 10-минутной задержкой.

# shutdown - h +10 Hard disk needs to be replaced

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

*** System shutdown message from *****@***sanylenet. org ***

System going down in 10 minutes

Hard disk needs to be replaced

За пять минут до предстоящего закрытия система создает файл /var/run/nologin. Таким способом запрещается дальнейшая регистрация для входа в систему, а когда кто-нибудь пытается это сделать, у него на экране отображается содержимое этого файла. В этот файл помещается широковещательное сообщение и указывается время закрытия системы. Так, в данном случае, всякий, кто попытается зарегистрироваться в системе, увидит на экране следующее сообщение:

NO LOGINS; System going down at 17:57

Hard disk needs to be replaced.

Когда наступает время закрытия, выполняются следующие действия:

·  В процесс init посылается сигнал TERM, который прекращает создание любых новых процессов.

·  Процесс init читает содержимое файла /etc/rc. shutdown и выполняет все сценарии закрытия для отдельных программ, которые там содержатся.

·  Всем процессам посылается сигнал TERM и дается время на то, чтобы мягко, то есть корректно, завершить свою работу.

·  Всем процессам, которые в течение разумного промежутка времени не отвечают на сигнал TERM, посылается сигнал KILL, который нельзя проигнорировать. Он жестко завершает процесс, грубо прерывая его выполнение.

·  С помощью команды sync данные из кэша синхронизируются с носителем информации, файловые системы демонтируются и отмечаются как clean.

·  Происходит останов ядра.

Кроме того, команда shutdown производит в системный журнал запись, в которой отмечается время закрытия системы и кто это сделал. Обратите внимание, что закрывать систему может только root (либо зарегистрировавшийся как root, либо ставший им с помощью команды su).

Чтобы закрыть систему «сейчас» введите su и нажмите Enter. Когда появится соответствующее приглашение, введите пароль root. Предполагая, что в системе нет других пользователей, вводим следующую команду:

# shutdown - h now

Когда произойдет закрытие системы, вы увидите на экране следующее сообщение:

System halted

Please press any key to reboot

И только после этого можно спокойно выключать электропитание вычислительной системы.

Замечания относительно команд halt и reboot

Для останова и перезагрузки системы можно использовать еще две команды: halt и reboot. Однако лучше не привыкать пользоваться этими командами. Ни одна из них не выполняет сценарий rc.shutdown, что может привести к неправильному завершению работы некоторых программ. Кроме того, ни одна из этих программ не позволяет задавать временную задержку и ни одна из них не предупреждает пользователей о предстоящем закрытии системы. Поэтому для останова системы всегда используйте команду shutdown.

Примечание. Если раньше вы работали в DOS и/или Windows, у вас могла выработаться привычка перезагружать систему, используя Ctrl+Alt+Delete. По умолчанию FreeBSD перехватывает сигнал, вырабатываемый этой комбинацией клавиш, и выполняет действия, эквивалентные команде reboot. Это может вызвать проблемы, если обычные пользователи имеют доступ к клавиатуре сервера. Можно сконфигурировать FreeBSD таким образом, чтобы нажатие комбинации клавиш Ctrl+Alt+Delete не приводило к перезагрузке системы.

9.5. Процессы-демоны

Рассматриваются процессы-демоны init, inetd, portmap, pagedaemon, swapper, nfsd, ftpd, telnetd.

Демон – это фоновый процесс, который выполняет системную задачу.

В соответствии с принципом модульности демоны являются программами, а не частями ядра.

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

Слово "демон" (daemon) впервые употребил в компьютерной практике Мик Бейли (Mick Bailey), англичанин, который в начале 60-х гг. работал программистом в Массачусетсом технологическом институте. Для объяснения смысла и правильного написания слова "daemon" Мик цитировал Оксфордский словарь английского языка.

Слова "daemon" и "demon" имеют общий корень, но первое - более' древнее, сохранившее первоначальное значение. Слово "daemon" дословно означает "гений, дух-покровитель человека". В этом смысле демоны являются не воплощениями добра или зла, а независимыми существами со своими собственными намерениями и желаниями.

Из системы CTSS, в работе над которой Бейли принимал участие, этот термин перешел в Multics, а затем и в UNIX, где демоны стали настолько популярными, что для управления ими понадобился "супердемон" (inetd).

До того как был написан демон inetd, все демоны запускались во время начальной загрузки и работали непрерывно (точнее, блокировались в ожидании работы). Со временем в систему вводились все новые и новые демоны. Их появилось столько, что начали возникать проблемы с производительностью. В ответ специалисты университета Беркли разработали inetd - демон, отвечающий за запуск других демонов по мере необходимости.

Супердемон inetd стал таким популярным, что теперь его включают во все основные версии UNIX, а большинство новых демонов работает под его контролем.

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

9.5.1. Демон init – первоначальный процесс

Демон init — это первый процесс, который запускается после начальной загрузки системы, и во многих отношениях это самый важный демон. Oн всегда имеет идентификатор процесса 1 и является предком всех пользовательских и почти всех системных процессов.

Во время начальной загрузки демон init либо переводит систему в однопользовательский режим, либо порождает интерпретатор команд для чтения стартовых сценариев. Когда система загружается в однопользовательском режиме, демон init начинает читать стартовые сценарии после того, как однопользовательский интерпретатор команд завершается нажатием клавиш <Ctrl-D>.

После обработки файлов запуска демон init обращается к файлу конфигурации (/etc/ttytab, /etc/ttys или /etc/inittab, в зависимости от системы и получает оттуда список портов, через которые следует ожидать входа систему. Демон init активизирует эти порты и порождает для каждого из них процесс getty. Если порт открыть нельзя, демон init периодически выдает на системную консоль сообщения, пока порт не будет открыт или удален и списка активных портов.

В старых системах управление терминальными портами было основной задачей администраторов. Сегодня терминалы являются реликтами было эпохи. Пользователи регистрируются в системах по сети при помощи таки демонов, как rlogind, telnetd и sshd.

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

Останов системы осуществляется путем передачи демону init соответствующего сигнала (обычно это SIGTERM), который заставляет его перевести систему в однопользовательский режим. Это последняя операция в большинстве сценариев останова. Демон init играет настолько существенную роль в работе системы, что в случае его зависания инициируется автоматическая перезагрузка системы.

Во FreeBSD демону init можно дать указание перечитать свой управляющий файл. Для этого посылается сигнал отбоя (SIGHUP). Поскольку демон init всегда имеет один и тот же идентификатор процесса, можно просто выполнить команду kill -HUP 1. Не забудьте указать аргумент -HUP, иначе система зависнет.

9.5.2. Сетевой супердемон inetd

Демон inetd управляет другими демонами. Он запускает демоны-клиенты, когда для них есть работа, а после выполнения задачи позволяет им тихо завершиться.

Демон inetd работает только с теми демонами, которые оказывают услуги по сети. Для того чтобы установить, не пытается ли кто-нибудь получить доступ к одному из его клиентов, демон inetd контролирует те редко активизируемые сетевые порты, которые обслуживаются обычно бездельничающими демонами. Когда устанавливается соединение, демон inetd запускает соответствующий демон и соединяет каналы его стандартного ввода-вывода с сетевым портом. Это правило следует учитывать при написании демонов, совместимых с inetd.

Работа некоторых демонов (например, тех, что связаны с NIS и NFS) основана на протоколе RPC, который был разработан и реализован компанией Sun в качестве механизма совместного использования информации в распределенной сетевой среде. Назначениями портов для RPC-демонов управляет демон portmap (иногда называется rpcbind).

Многие демоны могут использоваться либо традиционным способом (т. е. они запускаются однократно и работают до выключения системы), либо под контролем демона inetd.

Конфигурирование демона inetd

Для того чтобы определить, какие сетевые порты нужно контролировать, демон inetd читает файл конфигурации (обычно /etc/inetd.conf, а иногда /usr/etc/inetd.conf или /etc/servers). Его формат одинаков для всех платформ. Приведем пример:

ftp stream tcp nowait root /usr/sbin/ftpd ftpd

telnet stream tcp nowait root /usr/sbin/telnetd telnetd

shell stream tcp nowait root /usr/sbin/rshd rshd

finger stream tcp nowait guest /usr/sbin/fingerd finger

bootp dgram udp wait root /usr/sbin/bootpd bootp - f

pop-2 stream tcp nowait root /usr/sbin/popper popper

pop-3 stream tcp nowait root /usr/sbin/popper popper

mountd/1 dgram rpc/tcp wait root /usr/sbin/mountd mountd

mountd/1 dgram rpc/tcp wait root /usr/sbin/mountd mountd

Первая колонка содержит имя сервиса. Эти имена преобразуются и номера портов на основе данных, содержащихся в файле /etc/services (для UDP - и ТСР-сервисов) или демоном portmap (для RPC-сервисов). RPC-cepвисы можно отличить по формату имени имя/номер и обозначению rpc в третьей колонке. В приведенном выше примере RPC-сервисы указаны в двух последних строках.

Во второй колонке определяется тип сокета, которым будет пользоваться сервис: stream или dgram. Сокеты типа stream используются с ТСР-сервисами (ориентированными на установление соединения), а сокеты типа dgram - с UDP-сервисами.

В третьей колонке указывается протокол обмена, которым пользуется данный сервис. Допустимые типы перечислены в файле protocols (обычно он находится в том же каталоге, что и файл конфигурации демона inetd). Почти всегда в этой колонке указывается тип tcp или udp. RPC-сервисы предваряют тип протокола обозначением rpc/.

Если описываемый сервис может обрабатывать одновременно несколько запросов (а не завершает выполнение после обработки одного запроса), в четвертой колонке нужно ставить ключевое слово wait, которое не даст демону inetd постоянно порождать новые экземпляры демона этого сервиса. Данное средство применяется для сервисов, которые обрабатывают множество мелких запросов. Если опция wait не подходит, то в этом поле нужно поставить ключевое слово nowait.

В пятой колонке указан пользователь, от имени которого должен выполняться данный демон. Если вы не доверяете той или иной программе либо знаете, что она порождает проблемы, связанные с безопасностью системы, можете выполнить ее от имени непривилегированного пользователя. Естественно, это годится только для демонов, которые не требуют привилегий пользователя root. В нашем примере демон fingerd выполняется с правами пользователя guest.

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

Файл services

После добавления нового сервиса в файл inetd. conf, возможно, понадобится ввести его и в файл services. Этот файл обычно находится в том же каталоге, что и файл inetd. conf, и используется несколькими стандартными библиотечными функциями, которые преобразуют имена сервисов в номера портов. Например, если ввести команду

% telnet anchor smtp

то в файле services будет произведен поиск номера порта, соответствующего SMTP-сервису. В большинстве систем все самые распространенные сервисы на момент поставки уже сконфигурированы. Если потребуется добавить еще несколько сервисов, нужно будет просто отредактировать файл services.

Файл services используется только для сервисов TCP/IP. Аналогичная информация для RPC-сервисов хранится в отдельном файле конфигурации (обычно это /etc/грс).

Ниже приведено несколько строк из файла services (размер которого около 70 строк):

tcp 1/tcp # TCP port multiplexer

echo 7/tcp

echo 7/udp

smtp 25/tcp mail

time 37/tcp timserver

time 37/udp timserver

rlp 39/udp resource # resource location

name 42/tcp # IEN 116

whois 43/tcp

Формат строки таков:

имя порт/тип псевдонимы # комментарий

Сервисы в файле обычно упорядочены по номерам, но это не обязательно. В поле имя указывается имя сервиса (которое используется в файле inetd. conf). В поле порт значится номер порта, контролируемого сервисом. Если сервис работает под управлением демона inetd, то это тот порт, который контролируется демоном inetd.

Поле тип обозначает протокол, которым пользуется данный сервис (на практике это всегда tcp или udp). Если программа может работать и по протоколу TCP, и по протоколу UDP, необходимо включить строку для каждого из этих протоколов (как в записи для сервиса time; см. пример). Поле псевдонимы содержит дополнительные имена сервиса (например, сервис whois можно искать по имени nicname).

Перезапуск демона inetd

Изменения, внесенные в файл конфигурации, вступят в силу лишь после того, как демону inetd будет дано указание перечитать файл. Это делается путем передачи этому демону сигнала отбоя. Послав сигнал, подождите минуту и проверьте, нет ли в журнальных файлах сообщений об ошибках, связанных с внесенными изменениями (демон inetd регистрирует ошибки в системе Syslog). Можно попробовать связаться с новыми сервисами и проверить, как они работают.

9.5.3. Демон portmap – преобразование номеров RPC-программ в номера портов TCP и UDP

Демон portmap (в настоящее время называется rpcbind во многих системах) преобразует номера RPC-сервисов в номера портов TCP/IP, которые контролируются их серверами. Когда запускается PRC-сервер, он регистрирует себя с помощью демона portmap/rpcbind, указывая поддерживаемые сервисы, а также используемый порт. Клиенты запрашивают демон portmap/rpcbhid и выясняют, как связаться с соответствующим сервером.

Такая схема позволяет устанавливать соответствие между номером порта и символьным именем сервиса. Это уже принципиально иной уровень абстракции, более высокий, чем используемый в файле services, но вместе с ним появляются дополнительные сложности (и проблемы безопасности), тогда как реальных проблем он не решает. Многие RPC-сервисы фактически запускаются демоном inetd. Таким образом, создается не один, а два уровня косвенного вызова программ.

Если демон portmap/rpcbind зависает, все связанные с ним службы (включая inetd и NFS) должны перезапускаться. На практике это означает перезагрузку системы. Для того чтобы демон inetd обрабатывал RPC-запросы правильно, демон portmap должен быть запущен раньше, чем inetd.

9.5.4. Демон pagedaemon – замещение странтц виртуальной памяти

Реализация данного демона и его функционирование зависят от конкретной системы. Он называется pageout в Solaris, vhand в HP-UX, kpiod в Red Hat и pagedaemon во FreeBSD.

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

9.5.5. Демон swapper - свопинг

Этот демон называется swapper во FreeBSD и HP-UX и kswapd в Linux. Когда одновременно работает много процессов, система тратит массу времени на обработку ошибок, возникающих из-за отсутствия свободных страниц, потому что каждый процесс использует определенное количество страниц, к которым регулярно обращается. Такая перегрузка системы управления виртуальной памятью серьезно ухудшает производительность системы.

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

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

9.5.6. Демон update – синхронизация файловых систем

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

В большинстве систем этот демон называется update, но в HP-UX он носит имя syncer, а в Solaris — fsflush.

9.5.7. Демон syslogd: обработка сообщений об ошибках

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

9.5.8. Демоны NFS:

Следующие демоны входят в состав сетевой файловой системы - NFS.

Демон nfsd – файловый сервис

Демон nfsd работает на серверах и отвечает за обработку запросов, поступающих от клиентов NFS. В некоторых системах он называется rpc.nfsd (префикс "rрс" означает, что данный демон использует протокол RPC).

В большинстве реализации NFS демон nfsd является частью ядра, "замаскированной" под процесс из соображений простоты планирования. У этого демона есть один аргумент - количество порождаемых экземпляров самого себя. Правильно выбрать количество экземпляров довольно сложно.

Демон rpc.mountd – ответы на запросы монтирования

Демон mountd (иногда называемый rpc.mountd) принимает от потенциальных клиентов NFS запросы на монтирование файловых систем. Он отвечает за проверку наличия у каждого клиента разрешения на монтирование заявленных каталогов. Для того чтобы выяснить, какие запросы правомочны, демон mountd обращается к файлу /etc/exports.

Демоны amd и automount: монтирование файловых систем по запросу

Программы amd и automount - это автоматические монтировщики NFS, которые, прежде чем смонтировать файловую систему, ждут, когда процесс попытается обратиться к ней. Впоследствии, если к файловой системе не было обращения в течение определенного промежутка времени, демоны демонтируют ее.

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

Демоны lockd и statd управление файлами блокировки NFS

Демоны lockd и statd (называемые также rpc. lockd и rpc. statd) всегда работают в паре. Демон lockd отвечает за блокировку файлов NFS. Демон statd позволяет процессам контролировать состояние компьютеров, на которых работает NFS. Он используется демоном lockd для принятия решения о том, когда следует произвести попытку установления связи с удаленным компьютером.

Демон biod – кэширование блоков

Демон biod (называемый nfsiod во FreeBSD) отвечает за кэширование запросов чтения и записи на машинах-клиентах NFS. Демон выполняет буферизацию как с опережающим чтением, так и с отстающей записью, что значительно повышает производительность сетевой файловой системы.

9.5.9. Демоны Internet

В этом разделе перечислены демоны, которые для обработки запросов пользуются Internet-протоколами. В реальности большинство демонов Internet основную часть времени тратят на обслуживание локальных запросов.

Демон sendmail: транспортировка электронной почты

Задачи программы sendmail включают прием сообщений от пользователей и удаленных компьютеров, подстановку адресов, раскрытие псевдонимов и пересылку почты по сети Internet. Это очень важный и очень сложный демон.

Демон ftpd: сервер пересылки файлов

Демон ftpd обрабатывает запросы, поступающие из программы ftp. Во многих организациях этот демон отключен - либо потому, что без толку "пожирает" ресурсы, либо по соображениям безопасности. Демон ftpd может быть настроен так, чтобы все пользователи имели право пересылать файлы в систему и копировать файлы из нее.

Демон telnetd: сервер удаленной регистрации

Демон telnetd напоминает демон rlogind, но пользуется протоколом TELNET. Этот протокол позволяет двум компьютерам (клиенту и серверу) согласовывать порядок управления потоком данных и работу в дуплексном режиме. Для низкоскоростных и малонадежных каналов передачи это более предпочтительный выбор, нежели демон rlogind. Программа telnet передает пароли в незашифрованном виде по сети, поэтому использовать ее не рекомендуется. Программа telnet поддерживается не только в UNIX-системах.

Демон sshd: безопасный сервер удаленной регистрации

Демон sshd функционирует подобно демону telnetd, но все данные (в том числе аутентификационные) передаются через зашифрованный канал. Поддерживается множество алгоритмов шифрования. В связи с тем, что современная среда Internet весьма небезопасна, доступ в систему через Internet необходимо разрешать только этому демону, а демону telnetd - запрещать.

Демон routed: ведение таблиц маршрутизации

Демон routed ведет таблицы маршрутизации, используемые стеком протоколов TCP/IP для передачи пакетов по сети. Демон routed занимается только динамической маршрутизацией; статически заданные маршруты (т. е. назначаемые командой route) не модифицируются. Демон routed довольно прост и неэффективен, поэтому рекомендуется пользоваться им только в особых случаях.

Демон named: сервер DNS

Демон named - самый популярный сервер доменной системы имен (DNS). Он преобразует имена компьютеров в сетевые адреса и выполняет много других функций, пользуясь распределенной базой данных, которую ведут его коллеги в других системах.

Демон httpd: сервер World Wide Web

Демон httpd позволяет текущему узлу стать сервером гипертекстовых документов всемирной паутины. Демон httpd может посылать своим клиентам текст, изображения и звук.

Демоны синхронизации времени

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

timed: синхронизация часов

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

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

Понятие "точное время" весьма туманно. Некоторые системы опрашивают сеть и определяют среднее значение времени, а некоторые тюлевым решением объявляют, время главного компьютера точным.

xntpd: более точная синхронизация часов

Программа xntpd — это демон, который, пользуясь протоколом NTP (Network Time Protocol — протокол сетевого времени; RFC1119), синхронизирует ряд "равноправных" часов с точностью до миллисекунд. Синхронизируемые серверы образуют иерархию, каждый уровень которой называется слоем.

Демон xntpd имеет доступ к ряду вторичных эталонов времени, поэтому он точнее устанавливает время на UNIX-системах, чем демон timed: часы не только синхронизируются, но и точно идут. Текущую версию демона xntpd можно получить по анонимному FTP-доступу на узле ftp. udel. edu.