После того, как пользователь выберет нужное ему ядро, загрузка системы будет продолжена. Сначала будет загружаться ядро, а потом — программа init. Для полноты рассмотрения процесса загрузки я буду считать, что у нас установлен уровень управления 5.
Первыми будут выполнены процессы, которые указаны в действии sysinit файла /etc/inittab. Затем — процессы, перечисленные с помощью действий boot и bootwait (см. п. 5.5).
Обычно для действия sysinit выполняется сценарий загрузки /etc/re.d/rc.sysinit:
si::sysinit:/etc/rc.d/rc.sysinit
На данном этапе загрузки системы (sysinit) выполняются следующие действия:
1. Устанавливается имя машины (hostname).
2. Конфигурируются параметры ядра.
3. Устанавливается раскладка клавиш и системный шрифт.
4. Активируются разделы подкачки.
5. Корневая система проверяется программой fsck. Если будут найдены ошибки, которые невозможно исправить автоматически, будет запрошен пароль администратора для входа в административный режим, что равноценно переходу на уровень выполнения 1. В этом режиме вы запустите программу fsck с параметром /, который означает проверку корневой файловой системы. После исправления всех ошибок введите команду exit для перезагрузки системы. Если программа fsck ошибок не обнаружила, файловая система монтируется в режиме чтение/запись.
6. Проверяются зависимости модулей ядра.
7. Выполняется проверка других файловых систем.
8. Монтируются локальные файловые системы.
9. Включаются квоты.
10. Подключается (не активизируется!) раздел подкачки. С этого момента система начинает использовать раздел подкачки.
После выполнения сценария загрузки /etc/re.d/rc.sysinit выполняется сценарий /etc/re.d/rc. Этому сценарию передается один параметр –номер уровня выполнения. В рассматриваемом случае — это номер 5, поэтому будет выполнена команда:
/etc/re.d/rc 5
Разумеется, данный сценарий будет выполнен при наличии в вашем файле /etc/initab строки:
15:5:wait:/etc/re.d/rc 5
Вы можете определить любое другое действие для уровня выполнения 5. Однако я не рекомендую вам этого делать: если вы написали свой сценарий загрузки, который работает лучше, чем предлагаемый разработчиками дистрибутива по умолчанию, значит, вам самое время написать свой дистрибутив! Запуск пятого уровня выполнения подразумевает запуск сценариев из каталога /etc/re.d/rc5.d/.
После выполнения этого сценария будет выполнен сценарий /etc/re.d/rc. local. Данный сценарий всегда выполняется последним, вне зависимости от уровня выполнения.
После запуска сценариев пятого уровня выполнения создаются виртуальные консоли и запускается менеджер дисплеев системы X Window (xdm).
5.7. Стандартные файлы протоколов (журналов)
В любой Unix-системе есть стандартные файлы протоколов (журналов), расположение которых может изменяться в зависимости от операционной системы. В Linux они находятся в каталоге /var/log. К стандартным протоколам относятся следующие файлы:
secure
auth.log
boot.log
dmesg
messages
syslog
В подкаталогах каталога /var/log находятся журналы (протоколы) других программ, например, в каталоге /var/log/kernel находятся журналы ядра, а в /var/log/httpd — журналы HTTP-сервера. По большому счету расположение журналов зависит от настройки соответствующих им программ, но в стандартном виде все они находятся в каталоге /var/log и его подкаталогах. Назначение стандартных журналов представлено в табл. 5.6. Подробно файлы журналов будут рассмотрены в следующем пункте (п. 5.8), в котором мы научимся управлять процессом протоколирования.
Стандартные журналы Таблица 5.6
Файл Назначение auth.log Протоколирование аутентификации user.log Сообщения пользовательских программ secure Обычно в этот файл записываются сообщения об удаленном доступе к этой машине, например, сообщения от демона FTP о том, какие пользователи и когда регистрировались на данном сервере messages Остальные сообщения
5.8. Управление протоколированием
Этот раздел посвящен демону syslogd, а также управлению протоколированием сообщений системы и ядра с помощью этого демона. Прежде всего следует отметить, что демон находится в пакете sysklogd (если вы, конечно, используете Red Hat-совместимую систему), поэтому перед его использованием нужно установить этот пакет. В большинстве случаев у вас пакет уже будет установлен, а демон syslogd запущен. Чтобы проверить этот факт, введите команду syslogd. Если демон запущен, то в ответ вы должны получить сообщение:
syslogd: Already running.
Убедиться в том, что демон запущен, можно также с помощью команды:
ps –ax | grep syslogd
Обратите внимание, что в пакет sysklogd на самом деле входят две программы: syslogd и klogd. Программа syslogd отвечает за протоколирование сообщений системы, a klogd — ядра.
5.8.1. Демон Syslogd
Демон syslogd (system logging-deamon) обеспечивает вид протоколирования, который поддерживается большинством программ. При этом демон syslogd пишет сообщения в файл /var/log/syslog. Записи в этом файле обычно содержат такие поля: дата и время, хост, программа, сообщение. Пример этого файла представлен ниже:
Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can't locate module sound-service-1-0
Jan 27 17:09:35 dhsilabs modprobe: modprobe: Can't locate module sound-slot-1
Jan 27 17:12:28 dhsilabs kernel: VFS: Disk change detected on device ide1(22,64)
Jan 27 17:12:31 dhsilabs kernel: ISO 9660 Extensions: Microsoft Joliet Level 1
Jan 27 17:12:31 dhsilabs kernel: ISOFS: changing to secondary root
Jan 27 17:12:32 dhsilabs kernel: VFS: Disk change detected on device fd(2,0)
Jan 27 17:12:32 dhsilabs kernel: end_request: I/O error, dev 02:00 (floppy), sector 0
Например, из предпоследней записи мы можем узнать, что 27-го января 2002 года в 17:12 произошла смена носителя в устройстве fd, о чем нам любезно сообщило ядро системы (запись «программа» — kernel). А носитель (дискета) оказался подпорченным, о чем свидетельствует следующая запись — ошибка ввода/вывода (I/O error, dev 02:00 (floppy), sector 0).
Демон syslogd запускается автоматически при старте системы. Для его запуска предназначен сценарий /etc/rc.d/init.d/syslog. Как обычно, запустить демон самостоятельно вы можете с помощью команды: /etc/rc.d/init.d/syslog start, а остановить — /etc/rc.d/init.d/syslog stop. Для обеспечения автоматической загрузки нужно создать символическую ссылку на этот файл, например:
ls –s /etc/re.d/rc5.d/@S30syslog /etc/rc.d/init.d/syslog.
В этом случае вы обеспечите запуск демона на пятом уровне запуска (автоматический запуск X Window). Если вы используете Linux Mandrake, включить и отключить автоматический запуск вы можете с помощью команды drakxservices. При использовании Linux Red Hat включите автозапуск демона с помощью конфигуратора setup. Демон syslogd можно запускать с опциями, указанными в табл. 5.7.
В табл. 5.7 указаны не все опции демона. Назначение всех остальных опций вы можете найти в справочной системе, введя команду man syslogd.
Опции демона syslogd Таблица 5.7
Опция Описание -а сокет Этот параметр позволяет указать дополнительный сокет, который syslogd должен прослушивать -d Включает режим отладки. В этом режиме демон не будет использовать системный вызов fork(2) для переключения себя в фоновый режим и будет выводить больше отладочной информации -f файл Этот параметр определяет альтернативный файл конфигурации -h По умолчанию демон не перенаправляет сообщения, которые он получает от других узлов. Этот параметр позволяет перенаправить сообщения другим хостам, которые определены -n Этот параметр нужен, если syslogd запускается и контролируется программой init -р сокет Позволяет задать другой сокет Unix вместо /dev/log -r Позволяет принимать сообщения из сети. Данная опция появилась в версии syslogd 1.3 -v Выводит версию демона syslogd
5.8.2. Сигналы
Демон syslogd реагирует на следующие сигналы: SYGTERM, SIGINT, SIGQUIT, SIGHUP, SIGUSR1, SIGCHLD. Реакция демона на сигналы описана в табл. 5.8.
Реакция демона на сигналы Таблица 5.8
Сигнал Реакция SIGTERM Завершает работу демона SIGINT, SIGQUIT Завершает работу демона, если выключена отладка (debugging), Если же отладка включена, эти сигналы игнорируются SIGUSR1 Включает или выключает отладку SIGHUP Перезапуск демона
5.8.3. Файл конфигурации
По умолчанию используется файл конфигурации /etc/syslog.conf. Кроме этого вы можете указать другой файл конфигурации с помощью опции –f. Давайте рассмотрим установки демона на примере обычного файла конфигурации (см. листинг 5.4).
Листинг 5.4.# Протоколирование аутентификации. Файл протокола /var/log/auth.log
auth,authpriv.* /var/log/auth.log
# Префикс "-" используется, если вы хотите синхронизировать
# файл после каждой записи в него.
*.*;auth,authpriv.none –/var/log/syslog
# Сообщения пользовательских программ
user.* –/var/log/user.log
# Протоколировать все (кроме mail (почты)) . Уровень info и выше.
# Частные (private) сообщения протоколироваться не будут (попе)
*.info;mail.none;authpriv.none –/var/log/messages
# Файл регистрации частных сообщений имеет ограниченный доступ.
# Обычно в этот файл записываются сообщения об удаленном доступе к этой
# машине, например, сообщения от демона FTP о том, какие пользователи и
# когда регистрировались на данном сервере.
authpriv.* /var/log/secure
# Протоколирование почты
# Уровень отладки, информации и замечаний
mail.=debug;mail.=info;mail.=notice –/var/log/mail/info
# Уровень предупреждений
mail.=warn –/var/log/mail/warnings
# Уровень ошибок
mail.err –/var/log/mail/errors
# Протоколирование демона cron. Уровни отладки, информации,
# предупреждений и ошибок
cron.=debug;cron.=info;cron.=notice –/var/log/cron/info
cron.=warn –/var/log/cron/warnings
cron.err –/var/log/cron/errors
# Протоколирование ядра
kern.=debug;kern.=info;kern.=notice –/var/log/kernel/infо
kern.=warn –/var/log/kernel/warnings
kern.err –/var/log/kernel/errors
# Протоколирование очереди печати
lpr.=debug;lpr.=info;lpr.=notice –/var/log/lpr/info
lpr.=warn –/var/log/lpr/warnings
lpr.err –/var/log/lpr/errors
# Протоколирование новостей
news.=debug;news.=infо;news.=notice –/var/log/news/info
news.=warn –/var/log/news/warnings
news.err –/var/log/news/errors
# Протоколирование демонов
daemon.=debug;daemon.=info;daemon.=notice –/var/log/daemons/infо
daemon.=warn –/var/log/daemons/warnings
daemon.err –/var/log/daemons/errors
# Критические сообщения *.emerg *
# Сохранять ошибки почты и новостей (уровень err и выше)
# в отдельном файле
uucp,news.crit –/var/log/spooler
# Загрузочные сообщения
local?.* –/var/log/boot.log
Как вы уже заметили, файл конфигурации состоит из двух полей: объект протоколирования и файл, в который будут записываться сообщения, порождаемые этим объектом. Для каждого объекта можно указать один из уровней протоколирования: debug, info, notice, warn, err. Первые три относятся к информационным сообщениям. Уровень warn — это предупреждения, а err — ошибки. Существуют специальные сообщения — критические. Обычно они выводятся прямо на консоль.
Как для обозначения объектов, так и для обозначения уровней протоколирования можно использовать символ *, который обозначает все объекты или все уровни. Например, если вы хотите протоколировать все сообщения демонов в файл /var/log/daemons, то используйте такую конструкцию: daemon.* /var/log/daemons.
Пример протоколирования всех сообщений уровня emerg (критический уровень) приведен выше. Если вы хотите отправлять сообщения не в файл, а в поименованный канал (FIFO), используйте символ | перед именем файла-потока.
5.8.4. Сетевое протоколирование
Сейчас разберемся, как обеспечить протоколирование в сети. Протоколирование в сети — это перенаправление сообщений на демон syslogd, запущенный на другой машине, где они будут записаны на диск.
Для передачи сообщений используется протокол UDP. Он менее надежный, чем TCP, но отправление пакетов происходит несколько быстрее. Начните с того, что убедитесь, не закомментирована ли следующая строка в вашем файле /etc/services:
syslog 514/udp
Затем необходимо внести некоторые коррективы в файл конфигурации. Как и прежде, определите объекты протоколирования, а вместо файлов протоколов используйте параметр @hostname, где hostname — это имя компьютера, на который будут перенаправлены сообщения. Например, для перенаправления всех сообщений об ошибках на узел сети hostname можно использовать такую запись:
*.err @hostname
Для перенаправления всех сообщений используется запись:
*.* @hostname
Имя узла желательно указать в файле /etc/hosts, так как демон syslogd может быть запущен после сервера доменных имен или сервер DNS окажется недоступным.
Вы можете организовать центральный сервер протоколирования для всей вашей локальной сети. Для того, чтобы указать, какие хосты вы хотите протоколировать, используйте опцию –l список_хостов. В списке указываются простые имена машин, то есть без указания имени домена. Имена машин разделяются двоеточием (:). Возможно, вы также захотите использовать опцию –s для указания дополнительного сокета для прослушивания. Для перенаправления сообщений используйте опцию –r на машине-клиенте, при этом сообщения будут перенаправлены на сервер (см. табл. 5.7).
5.8.5. Демон klogd
Демон klogd предназначен для перехвата и протоколирования сообщений ядра Linux (klogd расшифровывается как kernel-logging daemon). В своей работе вы можете использовать параметры демона, указанные в табл. 5.9.
Параметры демона klogd Таблица 5.9
Параметр Описание -c n Устанавливает уровень сообщений, которые будут выводиться на экран -d Режим отладки -f файл Записывать сообщения в указанный файл раньше демона syslogd -i Позволяет перезагрузить символьную информацию ядра о модулях -l Перезагружает статическую символьную информацию и информацию о модулях ядра -n Не переходить в фоновый режим. Этот параметр используется, когда демон управляется программой init -o Демон читает и протоколирует все сообщения, которые он найдет в буферах сообщений ядра. После одного цикла чтения/протоколирования демон завершает работу -s Заставляет демон klogd использовать системные вызовы для обращений к буферам сообщений ядра -k файл Использует указанный файл в качестве файла, содержащего символьную информацию ядра -v Выводит версию и завершает работу
Для просмотра сообщений ядра используется команда dmesg. Обычно она используется так:
dmesg | less
Данная команда выводит сообщения ядра при запуске системы. С помощью параметра –с этой команды можно очистить ring-буфер ядра. Параметр –n задает уровень сообщений, которые будут выводиться на консоль.
По умолчанию демон klogd вызывается системным вызовом для того, чтобы препятствовать отображению всех сообщений на консоль. Это правило не распространяется на критические сообщения ядра (kernel panic), так как эти сообщения все равно будут отображены на консоли.
Демон реагирует на сигналы: SIGHUP, SIGKILL, SIGINT, SIGTERM, SIGTSTP, SIGUSR1, SIGUSR2, SIGCONT. Сигналы SIGTSTP и SIGCONT используются для начала и завершения протоколирования сообщений ядра. Сигналы SIGUSR1 и SIGUSR2 аналогичны опциям –i и –I соответственно. То есть первый перезагружает информацию о модулях, а второй статическую информацию и информацию о модулях. Использовать сигнал GIGUSR1 (как и все остальные) можно так:
# kill –USR1 PID
5.8.6. Параметры ядра
Параметр debug ядра Linux задает уровень отладки. Сообщения ядра (важные и не очень) передаются через функцию prinfk(). Если сообщение очень важное, то его копия будет передана на консоль, а также демону klogd для регистрации сообщения на жестком диске. Сообщения передаются на консоль, потому что иногда невозможно запротоколировать сообщение на жестком диске (например, отказ диска).
Предел того, что будет отображаться на консоли, задается переменной console_loglevel. По умолчанию на консоли отображается все, что выше уровня DEBUG (7). Список уровней можно найти в файле kernel.h.
6