• 5.1. Системные вызовы fork() и ехес()
  • 5.1.1. Общая схема управления процессами
  • 5.2. Перенаправление ввода/вывода
  • 5.3. Команды управления процессами
  • 5.4. Создание расписаний
  • 5.5. Уровни выполнения.Программа init
  • 5.6. Сценарии загрузки системы
  • 5.7. Стандартные файлы протоколов (журналов)
  • 5.8. Управление протоколированием
  • 5.8.1. Демон Syslogd
  • 5.8.2. Сигналы
  • 5.8.3. Файл конфигурации
  • 5.8.4. Сетевое протоколирование
  • 5.8.5. Демон klogd
  • 5.8.6. Параметры ядра
  • 5

    Процессы

    5.1. Системные вызовы fork() и ехес()

    Процесс в Linux (как и в UNIX) — это программа, которая выполняется в отдельном виртуальном адресном пространстве. Когда пользователь регистрируется в системе, под него автоматически создается процесс, в котором выполняется оболочка (shell), например, /bin/bash.

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

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

    В связи с развитием SMP (Symmetric Multiprocessor Architectures) в ядро Linux был внедрен механизм нитей или потоков управления (threads). Нитями также называют «легковесные» процессы. Другими словами, нить — это процесс, выполняемый в виртуальной памяти, которая используется вместе с другими нитями одного и того же «тяжеловесного» процесса. Такой «тяжеловесный процесс» обладает отдельной виртуальной памятью и может иметь несколько «легковесных» процессов.

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

    Операционная система предоставляет программе некоторый интервал процессорного времени. Когда программа переходит в режим ожидания какого-либо события (например, сигнала) или освобождает процессор, операционная система передает управление другой программе. Распределяя время центрального процессора, операционная система распределяет его не между программами, а между потоками. Исходя из всего этого, потоки — это наборы команд, имеющие возможность получать время процессора. Время процессора выделяется квантами. Квант — это минимальное время, на протяжении которого поток (нить) может использовать процессор.

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

    Если интерпретатору (shell) встречается команда, соответствующая выполняемому файлу, интерпретатор выполняет ее, начиная с точки входа (entry point). Для С-программ entry point — это функция main. Точка входа для каждой среды разработки различна. Запущенная программа тоже может создать процесс, т.е. запустить какую-то программу и ее выполнение тоже начнется с функции main. Затем с помощью системного вызова fork() создается адресное пространство — подготавливается «место» для нового процесса, а потом с помощью вызова ехес() в это адресное пространство загружается программа. Таким образом, каждый новый процесс выполняется в своей индивидуальной среде.

    Для создания процессов используется системный вызов: fork(). Вызов fork() создает новое адресное пространство, которое полностью идентично адресному пространству основного процесса. Другими словами, вызов fork() создает новый процесс. После выполнения этого системного вызова вы получаете два абсолютно одинаковых процесса — основной и порожденный. Функция fork() возвращает 0 в порожденном процессе и PID (Process ID — идентификатор порожденного процесса) — в основном. PID — это целое число.

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

    В качестве примера рассмотрим следующий фрагмент программы:

    if (fork() == 0) wait(0);

    else execl("ls", "ls", 0); /* порожденный процесс */

    Теперь рассмотрим более подробно, что же делается при выполнении вызова fork():

    1. Выделяется память для описателя нового процесса в таблице процессов.

    2. Назначается идентификатор процесса PID.

    3. Создается логическая копия процесса, который выполняет fork() — полное копирование содержимого виртуальной памяти родительского процесса, копирование составляющих ядерного статического и динамического контекстов процесса-предка.

    4. Увеличиваются счетчики открытия файлов (порожденный процесс наследует все открытые файлы родительского процесса).

    5. Возвращается PID в точку возврата из системного вызова в родительском процессе и 0 — в процессе-потомке.

    5.1.1. Общая схема управления процессами

    Каждый процесс может порождать полностью идентичный процесс с помощью fork(). Родительский процесс может дожидаться окончания выполнения всех своих процессов-потомков с помощью системного вызова wait. В любой момент времени процесс может изменить содержимое своего образа памяти, используя одну из разновидностей вызова ехес(). Каждый процесс реагирует на сигналы и, естественно, может установить собственную реакцию на сигналы, производимые операционной системой. Приоритет процесса может быть изменен с помощью системного вызова nice.

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

    Примеры сигналов:

    1. Окончание порожденного процесса (например, из-за системного вызова exit (см. ниже)).

    2. Возникновение исключительной ситуации.

    3. Сигналы, поступающие от пользователя, при нажатии определенных клавиш.

    Установить реакцию на поступление сигнала можно с помощью системного вызова signal:

    func = signal(snum, function);

    где: snum — номер сигнала;

     function — адрес функции, которая должна быть выполнена при поступлении указанного сигнала.

    Возвращаемое значение — адрес функции, которая будет реагировать на поступление сигнала. Вместо function можно указать ноль или единицу. Если был указан ноль, то при поступлении сигнала snum выполнение процесса будет прервано аналогично вызову exit. Если указать единицу, данный сигнал будет проигнорирован, но это возможно не для всех процессов.

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

    kill(pid, snum);

    где: pid — идентификатор процесса;

     snum — номер сигнала, который будет передан процессу (см. табл. 5.1).

    Pid состоит из идентификатора группы процессов и идентификатора процесса в группе. Если вместо pid указать нуль, то сигнал snum будет направлен всем процессам, относящимся к данной группе (понятие группы процессов аналогично группе пользователей). В одну группу включаются процессы, имеющие общего предка. Идентификатор группы процесса можно изменить с помощью системного вызова setpgrp. Если вместо pid указать –1, то ядро передаст сигнал всем процессам, идентификатор пользователя которых равен идентификатору текущего выполнения процесса, посылающего сигнал. Номера сигналов приведены в табл. 5.1. Сигналы (точнее, их номера) описаны в файле signal.h.

    Номера сигналов Таблица 5.1

    Номер Название Описание
    01 SIGHUP Освобождение линии (hangup)
    02 SIGINT Прерывание (interrupt)
    03 SIGQUIT Выход (quit)
    04 SIGILL Некорректная команда (illegal instruction). He переустанавливается при перехвате
    05 SIGTRAP Трассировочное прерывание (trace trap). He переустанавливается при перехвате
    06 SIGIOT или SIGABRT Машинная команда IOT. Останов ввода/вывода
    07 SIGBUS Ошибка на шине
    08 SIGFPE Исключительная ситуация при выполнении операции с вещественными числами (floating-point exception)
    09 SIGKILL Уничтожение процесса (kill). He перехватывается и не игнорируется
    10 SIGUSR1 Определяемый пользователем сигнал 1
    11 SIGSEGV Некорректное обращение к сегменту памяти (segmentation violation)
    12 SIGUSR2 Определяемый пользователем сигнал 2
    13 SIGPIPE Запись в канал, из которого некому читать. Обрыв потока
    14 SIGALRM Будильник
    15 SIGTERM Программный сигнал завершения
    16 SIGSTKFLT Сбой стека
    17 SIGCHLD (или SIGCLD) Изменение статуса дочернего процесса
    18 SIGCONT Продолжение работы после сигнала STOP. He перехватывается и не игнорируется
    19 SIGSTOP Сигнал СТОП. Не перехватывается и не игнорируется
    20 SIGTSTP Сигнал останова клавиатуры
    21 SIGTTIN Фоновое чтение из терминала (tty)
    22 SIGTTOU Фоновая запись на терминал (tty)
    23 SIGURG Критическое состояние сокета
    24 SIGXCPU Превышенный предел процессорного времени
    25 SIGXFSZ Превышенный предел размера файла
    26 SIGVTALRM Сигнал виртуального будильника
    27 SIGPROF Сигнал профилирующего будильника
    28 SIGWINCH Изменение размера окна
    29 SIGIO Разрешение ввода/вывода
    30 SIGPWR Сбой питания
    31 SIGSYS Некорректный параметр системного вызова

    Для нормального завершения процесса используется вызов:

    exit(status)

    где status — это целое число, возвращаемое процессу-предку для его информирования о причинах завершения процесса-потомка.

    Вызов exit может задаваться в любой точке программы, но может быть и неявным, например, при выходе из функции main (при программировании на С) оператор return 0 будет воспринят как системный вызов exit(0).

    5.2. Перенаправление ввода/вывода

    Практически все операционные системы обладают механизмом перенаправления ввода/вывода, и Linux не является исключением из этого правила. Обычно программы вводят текстовые данные с консоли (терминала) и выводят данные на консоль. При вводе под консолью подразумевается клавиатура, а при выводе — экран монитора. Клавиатура и экран монитора — это, соответственно, стандартный ввод и вывод (stdin и stdout). Любой ввод/вывод можно интерпретировать как ввод из некоторого файла и вывод в файл. Работа с файлами производится через их дескрипторы.

    Для организации ввода/вывода в UNIX используются три файла: stdin (дескриптор 0), stdout (дескриптор 1) и stderr (дескриптор 2).

    Символ > («больше») используется для перенаправления стандартного вывода в файл. Например:

    $ cat > newfile.txt

    В этом примере стандартный вывод команды cat будет перенаправлен в файл newfile.txt, который будет создан после выполнения этой команды. Если файл с этим именем уже существует, то он будет перезаписан. Нажатие Ctrl + D остановит перенаправление и прервет выполнение команды cat.

    Символ < («меньше») используется для переназначения стандартного ввода команды. Например, при выполнении команды cat < file.txt в качестве стандартного ввода будет использован файл file.txt, а не клавиатура.

    Символ >> используется для присоединения данных в конец файла (append) стандартного вывода команды. Например, в отличие от случая с символом >, выполнение команды cat >> newfile.txt не перезапишет файл в случае его существования, а добавит данные в его конец.

    Чтобы перенаправить весь стандартный поток ошибок в какой-нибудь файл, используйте переадресацию 2> имя файла или 2>> имя файла. В первом случае стандартный поток ошибок будет передан в файл или на устройство, а во втором — поток ошибок будет добавлен в файл, если такой существует. При использовании переадресации 2>&1 стандартный поток ошибок будет перенаправлен на стандартный вывод интерпретатора Bourne (здесь 1 и 2 — дескрипторы файлов). Для перенаправления стандартного потока ошибок в файл вы можете также использовать переадресацию >& имя_файла (интерпретатор C-Shell).

    В командных интерпретаторах Korn и C-Shell можно использовать переадресацию >! имя_файла. При этом файл не будет перезаписан, если он существует.

    Символ | используется для перенаправления стандартного вывода одной программы на стандартный ввод другой. Например,

    ps –ax | grep httpd.

    Можно также использовать переадресацию |&. В этом случае стандартный поток ошибок будет передан по каналу другой команде интерпретатора.

    5.3. Команды управления процессами

    Команда ps

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

    Параметры программы ps Таблица 5.2

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

    Например, после ввода команды ps –а вы увидите примерно следующее:

    PID  TTY   TIME     CMD

    1007 tty1  00:00:00 bash

    1036 tty2  00:00:00 bash

    1424 tty1  00:00:02 me

    1447 pts/0 00:00:02 mpg123

    2309 tty2  00:00:00 ps

    Для вывода информации о конкретном процессе вы можете воспользоваться командой:

    # ps –ax | grep httpd

    698  7 S 0:01 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1261 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1262 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1263 9 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1264 9 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1268 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1269 ? S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1270 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1271 9 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1272 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1273 7 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    1280 9 S 0:00 httpd –DHAVE_PHP4 –DHAVE_PROXY –DHAVE_ACCESS –DHAVE_A

    В приведенном выше примере используется перенаправление ввода/вывода между программами ps и grep, в результате чего будет отображена информация обо всех процессах, содержащих в строке запуска «httpd». Данную команду (ps –ax | grep httpd) я написал только лишь в демонстрационных целях — гораздо проще использовать параметр –С программы ps вместо перенаправления ввода/вывода и параметр –е вместо –ах.

    Команда top

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

    # top

    7:49pm up 5 min, 2 users, load average: 0.03, 0.20, 0.11

    56 processes: 55 sleeping, 1 running, 0 zombie, 0 stopped

    CPU states: 7.6% user, 9.8% system, 0.0% nice, 82.5% idle

    Mem 130660K av, 94652K used, 36008K free, OK shrd, 5220K buff

    Swap:72256K av, 0K used, 72256K free 60704K cached

    PID  USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND

    1067 root 14  0  892  892 680   R    2.8  0.6  0:00 top

    1    root 0   0  468  468 404   S    0.0  0.3  0:06 init

    2    root 0   0  0    0   0     SW   0.0  0.0  0:00 kflushd

    3    root 0   0  0    0   0     SW   0.0  0.0  0:00 kupdate

    4    root 0   0  0    0   0     SW   0.0  0.0  0:00 kswapd

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

    Существует графический аналог программы top — gtop (см. рис. 5.1).

    Изменение приоритета процесса — команда nice

    Формат использования:

    nice [-коэффициент понижения] команда [аргумент]

    Рис. 5.1. Программа gtop

    Команда nice выполняет указанную команду с пониженным приоритетом, коэффициент понижения указывается в диапазоне 1..19 (по умолчанию он равен 10). Суперпользователь может повышать приоритет команды, для этого нужно указать отрицательный коэффициент, например —10. Если указать коэффициент больше 19, то он будет рассматриваться как 19.

    Команда nohup — игнорирование сигналов прерывания

    Формат использования:

    nohup команда [аргумент]

    Команда nohup выполняет запуск команды в режиме игнорирования сигналов. Не игнорируются только сигналы SIGHUP и SIGQUIT.

    Команда kill — принудительное завершение процесса

    Формат использования:

    kill [-номер сигнала] PID

    где PID — идентификатор процесса, который можно узнать с помощью команды ps.

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

    Команды выполнения процессов в фоновом режиме — jobs, fg, bg

    Команда jobs выводит список процессов, которые выполняются в фоновом режиме, fg — переводит процесс в нормальный режим («на передний план» — foreground), a bg — в фоновый. Запустить программу в фоновом режиме можно с помощью конструкции

    <команда> &

    5.4. Создание расписаний

    Механизм расписаний Linux (UNIX) предоставляет удобные и мощные средства для обслуживания системы. Например, можно создать расписание резервирования данных в нерабочее время или обновления системы через Интернет.

    Для запуска команд по расписанию используется демон cron. Он запускается автоматически из файла /etc/init.d при многопользовательском уровне запуска. Об уровнях запуска поговорим немного позже. Каждую минуту cron пробуждается и проверяет содержимое файлов crontab. Для какой-то определенности назовем эти файлы файлами расписаний.

    Демон cron имеет свою буферную область (каталог /var/spool/cron/), в которой находятся файлы crontab — файлы расписаний. Имена файлов расписаний соответствуют именам пользователей из файла /etc/passwd. Если cron найдет файлы расписаний, он загрузит их в память. К этим файлам не должно быть прямого доступа, редактировать их можно с помощью программы crontab.

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

    Программа crontab

    Программа crontab используется для редактирования файлов расписаний отдельных пользователей. Программа позволяет устанавливать, удалять, редактировать и просматривать файлы расписаний. Например, для установки файла расписаний используется команда:

    crontab –u user file.cron

    Если не использовать опцию –u, то будет установлен файл расписания для пользователя, запустившего программу.

    Каждый пользователь может иметь файл расписания. Для того, чтобы использовать эту возможность, пользователь должен быть прописан в файле /var/spool/cron.allow, если такой существует. Программу crontab можно запускать с опциями, приведенными в табл. 5.3.

    Примечание. Последние версии демона crond используют файл /etc/cron.allow вместо файла /var/spool/cron.allow и файл/etc/cron.deny вместо файла /var/spool/cron.deny. В файле /etc/cron.allow содержится списокразрешенных пользователей, в файле /etc/cron.deny — запрещенных.

    Опции программы crontab Таблица 5.3

    Опция Описание
    -l Выводит текущий файл расписания
    -r Удаляет файл расписания
    Вызывает редактор, указанный в переменной окружения $EDITOR для редактирования файла расписания

    Каждая строка файла расписания имеет такой формат:

    время_выполнения действие

    Время выполнения состоит из пяти полей. В первом поле задаются минуты (0…59), во втором — часы (0…23), в третьем — день месяца (1…31), в четвертом — номер месяца (1…12), а в пятом день недели (0…6, 0 соответствует воскресенью). В любом из этих полей можно поставить звездочку, которая обозначает все возможные значения. Например, следующая запись означает, что архивирование каталога /etc будет производиться каждый день, кроме воскресенья, в семь часов утра:

    0 7 * * 1-6 tar cfz /backup /etc

    В системе используется системный файл расписания — это /etc/crontab (см. листинг 5.1).

    Листинг 5.1. Файл /etc/crontab

    # Интерпретатор команд

    SHELL=/bin/bash

    # Путь для поиска команд

    PATH=/sbin:/bin:/usr/sbin:/usr/bin

    # Отчет о выполнении расписания будет отправлен

    # пользователю root

    MAILTO=root

    # Домашний каталог

    НОМЕ=/

    # run-parts

    01 * * * * root run-parts /etc/cron.hourly

    02 4 * * * root run-parts /etc/cron.daily

    22 4 * * 0 root run-parts /etc/cron.weekly

    42 4 1 * * root run-parts /etc/cron.monthly

    Директива run-part означает, что будут выполнены все выполняемые файлы из указанного каталога.

    Демон atd

    Еще одним способом планирования задач является использование демона atd. Этот демон используется для отложенного выполнения заданий. Для постановки заданий в очередь используются команды at и batch. Чтобы добавить задание в очередь используйте команду:

    at время дата

    После этого введите все команды, которые хотите выполнить. Для окончания ввода нажмите Ctrl+D. Более подробно о формате задания времени и даты вы можете прочитать в справочной системе. Например, для выполнения команд в 13:00 введите команду:

    at 1pm

    Для просмотра очереди заданий, введите команду atq. В результате будут выведены задания для пользователя, запустившего команду. При запуске программы суперпользователем будет выведен список заданий для всех пользователей. Удалить задание вы можете командой atrm.

    5.5. Уровни выполнения.Программа init

    ОС Linux имеет шесть уровней выполнения, а также три уровня выполнения по требованию.

    Программа init переключает систему в нужный режим работы (на нужный уровень выполнения), и ее имеет право использовать только пользователь root. Для переключения на уровень n достаточно ввести команду:

    # init n

    Иногда, при небольшом изменении файла /etc/inittab, нужно заново перечитать таблицу инициализации (inittab). Для этого воспользуйтесь командой:

    init q

    Помните, что вы в любой момент можете изменить файл /etc/inittab и перечитать его заново командой

    init q.

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

    init: init s

    Описание уровней приведено в табл. 5.4.

    Уровни выполнения Таблица 5.4

    Уровень Описание
    0 Останов системы
    1 Административный (однопользовательский) режим. Обычно используется пользователем root для восстановления системы после сбоя
    2 Многопользовательский режим, но без использования сети
    3 Многопользовательский режим, допускается работа в сети
    4 Не используется
    5 Многопользовательский режим. Поддержка сети. Автоматический запуск системы X Window
    6 Перезагрузка системы

    Файл /etc/inittab описывает, какие процессы должны запускаться во время загрузки и на протяжении нормальной работы системы. Программа init переключает уровни выполнения системы. Корректными номерами уровней системы являются 0…6, а также А, В и С.

    Каждая строка файла /etc/inittab должна быть записана в формате:

    id:уровни_выполнения:действие:процесс

    Поле «Id» (идентификатор) — уникальная последовательность из четырех символов (в старых дистрибутивах длина имени идентификатора ограничена двумя символами).

    Поле «уровни выполнения» — перечень уровней выполнения, для которых будет выполнено указанное действие.

    Поле «действие» — задает действие, которое будет выполнено.

    Поле «процесс» — определяет процесс, который будет выполнен.

    В качестве значений поля «уровни_выполнения» могут быть указаны номера уровней выполнения без каких-либо разделителей. Например, значение данного поля 1235 означает, что указанное действие будет применено к уровням 1, 2, 3 и 5. В качестве дополнительных уровней, которые называются уровнями по требованию (ondemand), могут быть указаны уровни А, В и С.

    В качестве действия может быть указано одно из действий, описанных в табл. 5.5

    Действия над процессами, задаваемые в файле /etc/inittab Таблица 5.5

    Действие Описание
    wait Процесс будет запущен на одном из указанных уровней выполнения, и программа init будет ждать его завершения
    respawn Процесс будет перезапущен после его завершения
    once Процесс будет запущен всего один раз на одном из указанных уровней выполнения
    boot Процесс будет запущен во время загрузки системы. Поле «уровни_выполнения» будет проигнорировано
    bootwait То же, что и boot, но программа init будет ждать завершения процесса
    off Не выполняет никаких действий
    ondemand Процесс будет запущен в режиме по требованию, то есть он будет выполнен, когда будет вызван один из уровней по требованию (А, В, С)
    initdefault Определяет уровень выполнения по умолчанию. Если он не указан, при загрузке программа init попросит вас ввести уровень выполнения
    sysinit Процесс будет запущен во время загрузки, но перед выполнением процессов, которые запускаются с помощью действия boot или bootwait
    powerwait Процесс будет запущен, когда исчезнет напряжение в сети. Естественно, для корректной работы этой записи нужен источник бесперебойного питания, от которого система и получит уведомление об исчезновении напряжения. Программа init будет ждать завершения этого процесса
    powerfail То же, что и powerwait, но программа init не будет ждать завершения процесса
    powerokwait Процесс будет запущен сразу после того, как программа init получит сведения о том, что питание восстановлено
    ctrlaltdel С помощью этого действия можно установить реакцию системы на нажатие комбинации клавиш Ctrl+Alt+Del

    Теперь рассмотрим листинг обычного файла /etc/inittab (см. листинг 5.2).

    Листинг 5.2. Файл /etc/inittab

    id:5:initdefault:

    si::sysinit:/etc/rc.d/rc.sysinit

    10:0:wait:/etc/re.d/rc 0

    11:1:wait:/etc/re.d/rc 1

    12:2:wait:/etc/re.d/rc 2

    13:3:wait:/etc/re.d/rc 3

    14:4:wait:/etc/re.d/rc 4

    15:5:wait:/etc/re.d/rc 5

    16:6:wait:/etc/re.d/rc 6

    # Things to run in every runlevel.

    ud::once:/sbin/update

    # Trap CTRL-ALT-DELETE

    ca::ctrlaltdel:/sbin/shutdown –t3 –r now

    pf::powerfail:/sbin/shutdown –f –h +2 "Power Failure; System Shutting Down"

    pr:12345:powerokwait:/sbin/shutdown –c "Power Restored; Shutdown Cancelled"

    1:2345:respawn:/sbin/mingetty tty1

    2:2345:respawn:/sbin/mingetty tty2

    3:2345:respawn:/sbin/mingetty tty3

    4:2345:respawn:/sbin/mingetty tty4

    5:2345:respawn:/sbin/mingetty tty5

    6:2345:respawn:/sbin/mingetty tty6

    # Run xdm in runlevel 5

    # xdm is now a separate service

    x:5:respawn:/etc/X11/prefdm –nodaemon

    Рассмотрим подробно приведенный пример. Самая первая строка определяет уровень выполнения по умолчанию. Очень рекомендую вам установить это значение. Во-первых, вводить уровень загрузки каждый раз при запуске системы не очень удобно. Во-вторых, если не установлен уровень выполнения по умолчанию, система не сможет запускаться автоматически: при загрузке она будет ждать ввода номера уровня выполнения. Для загрузки системы подойдут два уровня: или 3, или 5. Я рекомендую использовать третий уровень выполнения, использовать уровень выполнения 5 нужно только в том случае, если вы хотите, чтобы система X Window запускалась автоматически при старте системы.

    Затем указываются программы, которые будут выполнены во время системной инициализации (sysinit). В нашем случае будет запушен сценарий загрузки системы /etc/re.d/rc.sysinit.

    Далее следуют описания действий для каждого из уровней выполнения. Например, для уровня выполнения номер 5 будет запущен сценарий /etc/re.d/rc с параметром 5. Программа init будет ждать завершения процесса /etc/re.d/rc.

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

    Реакция на нажатие комбинаций клавиш Ctrl+Alt+Del устанавливается с помощью действия ctrlaltdel. Будет запущена программа shutdown для немедленной (now) перезагрузки (-r) системы. Задержка перед переключением на шестой уровень (перезагрузка) составит три секунды (-t3).

    Реакция на перебои с питанием устанавливается с помощью действий powerfail и powerokwait. В качестве реакции на событие powerfail будет запущена программа shutdown для останова системы (-h). Опция –f указывает, что при перезагрузке будет пропущена проверка файловой системы с помощью fsck. Задержка перед переключением на шестой уровень выполнения составит две минуты (+2). На всех активных терминалах пользователи увидят сообщение «Power Failure; System Shutting Down». Если в течение двух минут питание будет восстановлено, запустится программа shutdown для отмены останова системы (-с). На терминалах пользователей будет отображено сообщение «Power Restored; Shutdown Cancelled».

    Наглядным примером для действия respawn может послужить система X Window. Можете провести такой эксперимент: перейдите на уровень выполнения 5: init 5

    Если уровень 5 уже активен, этого делать, естественно, не нужно. Находясь в системе X Window, нажмите Ctrl+Alt+Backspace — эта комбинация клавиш используется для экстренного останова системы X Window. После останова система X Window будет перезапущена.

    5.6. Сценарии загрузки системы

    Все Red Hat-подобные системы, в отличие от BSD-подобных (Slackware), используют систему инициализации SysV, хотя и несколько переработанную.

    Примечание. Система инициализации —это набор файлов, необходимых для запуска операционной системы. Обычно система инициализации представляет собой сценарии загрузки системы. В процессе развития Unix (см. гл. 1) выделились два основных типа систем — BSD-подобные системы и SysV-совместимые. Первые были совместимы (полностью или частично) с операционной системой BSD, разработанной Калифорнийским университетом, а вторые использовали в качестве своего предка операционную систему Unix System V, разработанную компанией AT&T. Системы инициализации BSD и SysV отличаются набором входящих в них файлов и их назначением.

    Запуск и останов демонов осуществляется с помощью сценариев, расположенных в каталоге /etc/re.d/init.d. Демон — это программа, которая в фоновом режиме периодически выполняет какие-нибудь действия. Например, демон ftpd непрерывно проверяет наличие пользовательских запросов на соединение по протоколу FTP.

    Сценарии каталога /etc/re.d выполняются автоматически при запуске системы. В этом каталоге есть несколько подкаталогов rcN.d, где N — это номер уровня выполнения. В большинстве случаев у вас будет установлен уровень 5 в качестве уровня по умолчанию. Этот уровень соответствует многопользовательскому режиму с автоматическим запуском системы X Window. В каталоге /etc/rd.d/rc5.d находятся символические ссылки на сценарии, расположенные в каталоге /etc/rc.d/init.d.

    Для запуска какого-нибудь демона нужно выполнить соответствующий ему сценарий в каталоге /etc/rc.d/init.d с опцией start. Для останова нужно запустить тот же сценарий, но с опцией stop.

    Чтобы обеспечить автоматический запуск какого-нибудь сервера, нужно создать сценарий для его запуска и поместить его в каталоге /etc/rc.d/init.d. Затем, в зависимости от уровня выполнения, в каталоге rcN.d нужно создать символическую ссылку на этот сценарий.

    Для выбора демонов, которые будут запускаться автоматически при загрузке системы, обычно используют программу drakconf в операционной системе Linux Mandrake (см. рис. 5.2) или программу setup в ОС Red Hat Linux.

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

    Рис. 5.2. Конфигуратор DrakConf


    Листинг 5.3. Шаблон для запуска демона

    #!/bin/bash

    # Шаблон для запуска демона

    # Подключаем библиотеку функций

    . /etc/init.d/functions

    # Определяем параметры

    case "$1" in

    start)

     # Запуск демона

     echo "Starting my_daemon…"

     daemon my_daemon

     touch /var/lock/subsys/my_daemon

     ;;

    stop)

     # Останов демона

     kill proc my_daemon

     rm –f /var/lock/subsys/my_daemon

     rm –f /var/run/my_daemon.pid

     ;;

    status)

     # Выводим статистику работы

     ;;

    restart | reload)

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

     :

     ;;

    *)

     # Произошел вызов без параметров

     echo "Usage: my_daemon {start|stop|status|restart|reload}"

     exit 1

    esac

    exit 0

    Теперь рассмотрим весь процесс загрузки системы, начиная с самого начала: от включения питания. Итак, вы включаете питание, система выполняет процедуру самотестирования POST (Power On Self Test). Если во время самотестирования ошибок обнаружено не было, из главной загрузочной записи MBR (Master Boot Record) вызывается загрузчик операционной системы. Поиск загрузчика происходит на загрузочных устройствах в соответствии с последовательностью загрузки (Boot Sequence). Данная последовательность определяется в программе настройки компьютера — SETUP. Например, у вас может быть установлена такая последовательность загрузки:

    FLOPPY, HDD-0, CDROM

    В этом случае система сначала будет искать загрузчик на дискете (диск А, устройство /dev/fd0). Если в дисководе нет дискеты, система перейдет к поиску загрузчика на первом жестком диске (HDD-0, устройство /dev/hda). Если же в дисководе есть дискета, но она не является загрузочной, вы получите соответствующее сообщение об этом. На этом этапе вы можете либо сменить дискету, либо вообще извлечь ее из дисковода, чтобы разрешить системе произвести поиск загрузчика операционной системы на жестком диске. Если и на жестком диске не будет обнаружен загрузчик, система перейдет к следующему элементу загрузочной последовательности — CDROM.

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

    После того, как пользователь выберет нужное ему ядро, загрузка системы будет продолжена. Сначала будет загружаться ядро, а потом — программа 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.






     

    Главная | В избранное | Наш E-MAIL | Прислать материал | Нашёл ошибку | Наверх