KLOGD

Section: Cистемное администрирование Linux (8)
Updated: 24 ноября 1995
Index Return to Main Contents

НАЗВАНИЕ

klogd - демон протоколирования сообщений ядра.

СИНТАКСИС

klogd [ -c n ] [ -d ] [ -f fname ] [ -iI ] [ -n ] [ -o ] [ -p ] [ -s ] [ -k fname ] [ -v ] [ -x ]

ОПИСАНИЕ

klogd это системный демон, который перехватывает и протоколирует сообщения ядра Linux.

ОПЦИИ

-c n: Установить уровень протоколирования по умолчанию для консольных сообщений равным n.
-d: Разрешить режим отладки. Это создаёт ОГРОМНЫЙ поток сообщений в stderr.
-f file: Сохранять сообщения в указанном файле, а не передавать их syslog.
-i -I: Послать сигнал выполняющемуся демону klogd. Оба этих параметра управляют загрузкой/перезагрузкой символьной информации. Параметр -i говорит демону перегрузить символы модулей ядра. Параметр -I говорит перегрузить и статические символы ядра и символы модулей ядра.
-n: Избегать автоматической фоновой обработки. Особенно эта опция требуется если klogd запускается и управляется с помощью init(8).
-o: Запуститься в 'одноразовом' режиме. При этом klogd читает и сохраняет все сообщения, которые найдёт в буфере сообщений ядра. После одиночного цикла чтения и записи демон заканчивает работу.
-p: Параноидальный режим. Эта опция влияет когда klogd загружает символьную информацию модулей ядра. Установка этой опции заставляет klogd загружать символьную информацию модулей ядра даже при обнаружении строки Oops в потоке сообщений ядра.
-s: Принуждает klogd использовать интерфейс системных вызовов к буферу сообщений ядра.
-k file: Использовать указанный файл в качестве источника символьной информации ядра.
-v: Напечатать номер версии и выйти.
-x: Пропустить трансляцию EIP и не читать System.map.

ОБЗОР

Функции klogd обычно встраивались в разных версиях syslogd, но оказалось что это не очень правильное решение. В современных ядрах Linux некоторые создаваемые ядром сообщения, такие как во время загрузки, при назначении приоритетов и определении адресов ядра, должны иметь источник. Создание журналирования ядра как отдельный процесс внесло ясность в разделение служб. В Linux есть два потенциальных источника сообщений ядра: файловая система /proc и интерфейс syscall (sys_syslog), хотя в конце концов это одно и тоже. Klogd умеет распознавать из какого источника возникло сообщение. Он делает это с помощью проверки смонтирована ли файловая система /proc. Если файл /proc/kmsg найден, то он используется как источник информации от ядра. Если файловая система proc не смонтирована, то klogd использует системный вызов чтобы получать сообщения ядра. Можно задать параметр (-s) в командной строке для того чтобы klogd сразу использовал интерфейс системных вызовов в качестве своего источника сообщений. Если надо передавать сообщения ядра syslogd демону, то начиная с версии 1.1 демон klogd умеет правильно работать с уровнями сообщений ядра. Уровни сообщений были добавлены в ядра, приблизительно начиная с версии 0.99pl13. Необработанные сообщения ядра имеют форму:

: <[0-7]> То, что хотело сказать ядро.

Уровень сообщений ядра кодируется как одноразрядная цифра, заключённая в скобки <>. Эти значения задаются во включаемом файле ядра kernel.h. Когда сообщение принимается от ядра, демон klogd читает уровень приоритета и назначает соответствующий уровень сообщению syslog. Если используется вывод в файл (-f), то приоритет задаётся слева, предваряя сообщение ядра. Демон klogd также может решать выдавать сообщение ядра на системную консоль или нет. В результате появления сообщений ядра с уровнями стало появление уровня сообщений ядра по умолчанию. По умолчанию в ядре уровень протоколирования на консоль установлен в 7. Любое сообщение с уровнем меньше 7 (высший уровень) отображаются на консоли. Сообщения с уровнем 7 считаются 'отладочными' сообщениями и поэтому не отображаются на консоли. Многие администраторы, особенно в многопользовательской среде, предпочитают чтобы все сообщения ядра обрабатывались klogd и направлялись в файл или демону syslogd. Это предотвращает загромождение экрана 'надоедливыми' сообщениями типа закончилась бумага в принтере или сменился диск. По умолчанию, демон klogd выполняет системный вызов, который подавляет все сообщения ядра (кроме panic) не давая им отображаться на консоли. Можно использовать параметр -c чтобы изменить такое поведение. Аргумент, задаваемые с параметром -c, указывает уровень до которого сообщения будут направлены на консоль. Заметим, что сообщения с уровнем МЕНЬШИМ чем заданный номер будут направляться на консоль.

Например, чтобы отображались все сообщения ядра с уровнем 3 (KERN_ERR) или выше выполним следующую команду:

        klogd -c 4

Определение числовых значений сообщений ядра есть в файле kernel.h, который можно найти в каталоге /usr/include/linux, если установлены исходные тексты ядра. Эти значения соответствуют значениям уровней syslog, которые определяются в файле syslog.h из каталога /usr/include/sys. Демон klogd может также работать в 'одноразовом' режиме для чтения буфера сообщений ядра. Чтобы запуститься в одноразовом режиме в командной строке задаётся параметр -o. Вывод направляется демону syslogd или в файл, указываемый в параметре -f.

Например, для чтения всех сообщений ядра после загрузки системы и записи их в файл с именем krnl.msg выполним следующую команду.

        klogd -o -f ./krnl.msg

ОПРЕДЕЛЕНИЕ АДРЕСОВ ЯДРА

Если ядро обнаруживает условия внутренней ошибки, то оно переходит в состояние общей ошибки защиты. Как часть процедуры обработки GPF ядро распечатывает сообщение о состоянии, показывающее состояние процессора во время сбоя. В него включено содержимое регистров микропроцессора, стек ядра и отслеженные функции, которые выполнялись во время сбоя. Эта информация ЧРЕЗВЫЧАЙНО ВАЖНА для определения того что привело к внутренней ошибке. Сложность возникает когда разработчик ядра пытается проанализировать эту информацию. Сырая числовая информация из распечатки ошибки малопригодна для разработчиков. Это происходит из-за того что ядра отличаются друг от друга и адреса переменных или функций во всех ядрах разные. Чтобы правильно распознать причину падения ядра разработчику нужно знать какая функция или переменная ядра располагалась в месте вызвавшим ошибку. Во время сборки ядра создается список, в котором указаны адреса важных переменных и функций собираемого ядра. Этот список сохраняется в файле с именем System.map на вершине дерева каталогов с исходными текстами ядра. С помощью этого списка разработчик ядра может точно определить при каких условиях в ядре возникла ошибка. Процесс преобразования числовых адресов из распечатки сбоя защиты можно выполнять вручную или с помощью программы ksymoops, которая включена в исходники ядра. Для удобства, klogd будет пытаться преобразовывать числовые адреса ядра в их символьную форму, если во время работы доступна таблица символов ядра. Таблицу символов можно задать с помощью параметра -k в командной строке. Если файл с символами явно не указан, то ищутся следующие файлы:

/boot/System.map
/System.map
/usr/src/linux/System.map

Информация о версии содержится в системных таблицах, начиная с ядра 1.3.43. Информация о версии используется для управления интеллектуальным поиском в списке таблиц символов. Это свойство полезно, т.к. оно обеспечивает поддержку одновременно и рабочих и экспериментальных ядер. Например рабочее ядро может хранить свой файл таблицы как /boot/System.map.
Если экспериментальное или тестовое ядро собирается из исходников в 'стандартном' месте /usr/src/linux, системную таблицу можно найти в /usr/src/linux/System.map. Когда klogd запускается под экспериментальным ядром таблица в /boot/System.map будет пропущена в угоду таблице /usr/src/linux/System.map. Современные ядра начиная с 1.3.43 правильно задают формат важных адресов ядра, так что они распознаются и преобразовываются klogd. У старых ядер необходимо править исходные тексты. Файл с исправлениями поставляется вместе с исходными текстами sysklogd. Процесс анализа ошибок защиты ядра проходит хорошо, когда ядро статическое. Дополнительные сложности возникают при попытке диагностирования ошибок, встречающихся в ядре с подгруженными модулями. Загружаемые модули ядра используются для реализации такой функциональности ядра как их загрузка и выгрузка когда угодно. Использование загружаемых модулей полезно с точки зрения отладки и может быть также полезно для уменьшения количества памяти, необходимой ядру. Сложность определения ошибок в загружаемых модулях возникает из-за динамичной природы модулей ядра. Когда модуль загружается, ядро выделяет память под модуль, когда модуль выгружается, эта память возвращается обратно ядру. Такое динамическое выделение памяти делает невозможным создать файл таблицы, в котором подробно бы расписывались адреса переменных и функций загружаемого модуля ядра. Без этой таблицы определений разработчику ядра невозможно определить что происходило не так, если ошибку защиты вызвал модуль ядра. klogd оказывает поддержку в решении проблемы с диагностикой ошибок защиты в загружаемых модулях ядра. Во время запуска программы или в ответ на сигнал демон запрашивает у ядра список всех загруженных модулей и адреса памяти где они располагаются. Отдельные модули могут также зарегистрировать местоположение важных функций при загрузке модуля. Адреса этих экспортируемых символов также определяются во время процесса запроса. Когда происходит ошибка защиты, делается попытка определения адресов ядра из статической таблиц символов. Если она завершается неудачно, то проверяются символы в загруженных в настоящий момент модулях. Этот минимум позволяет klogd указать какой загруженный модуль ответственен за генерацию ошибки защиты. Дополнительная информация может быть доступна, если разработчик ядра экспортировал символьную информацию из модуля. Правильное и точное определение адресов модулей ядра необходимо чтобы klogd знал, когда изменяется состояние модулей ядра. Параметры -i b -I могут использоваться для уведомления работающего демона, что символьная информация изменилась. Наибольшую важность в правильности определения символов модулей имеет параметр -i. Каждый раз когда модуль ядра загружается или удаляется из ядра должна выполняться такая команда:

klogd -i

Параметр -p также можно использовать для гарантии, что символьная информация модуля самая новая. Этот параметр указывает klogd перезагружать символьную информацию модуля всякий раз когда обнаруживается общая ошибка защиты. Этот 'параноидальный' режим нужно использовать с большой предосторожностью. Стабильность ядра и рабочей среды всегда под вопросом когда возникает ошибка защиты. Т.к. демон klogd должен выполнить системные вызовы для чтения символьной информация модуля, то есть возможность, что система может быть нестабильна для получения полезной информации. Намного лучшим правилом будет обеспечение klogd обновлениями во время загрузки или выгрузки модуля. Наличие загруженной свежей символьной информации увеличивает вероятность правильного трактования ошибки защиты, если она произойдет. Дистрибутив sysklogd в исходных текстах включает патч для пакета modules-2.0.0, который позволяет утилитам insmod, rmmod и modprobe автоматически посылать сигнал klogd когда происходит загрузка или выгрузка модуля из ядра. Использование этого патча гарантирует, что символьная информация в klogd будет всегда согласована с текущим состоянием ядра.

ОБРАБОТКА СИГНАЛОВ

klogd отвечает на восемь сигналов: SIGHUP, SIGINT, SIGKILL, SIGTERM, SIGTSTP, SIGUSR1, SIGUSR2 и SIGCONT. При сигналах SIGINT, SIGKILL, SIGTERM и SIGHUP демон закрывает свои источники сообщений ядра и изящно завершает работу. Сигналы SIGTSTP и SIGCONT используются для запуска и остановки протоколирования ядра. При приёме сигнала SIGTSTP демон закрывает свои источники и переходит в цикл ожидания. Последующий приём сигнала SIGCONT заставляет демона пройти через свою инициализационную последовательность и перевыбрать источник входящих сообщений. Использование SIGSTOP и SIGCONT в комбинации с вводом протоколирования ядра можно перевыбрать без остановки и перезапуска демона. Например, если файловая система /proc должна быть размонтирована, то используется следующая последовательность команд:

# kill -TSTP pid
# umount /proc
# kill -CONT pid

В журнале системы будет сделано примечание с уровнем
LOG_INFO описывающее запуск/остановку протоколирования. Сигналы SIGUSR1 и SIGUSR2 используются для начала загрузки/перезагрузки символьной информации ядра. Приём сигнала SIGUSR1 вызывает перезагрузку символов модулей ядра. Указание сигнала SIGUSR2 демону вызывает перезагрузку и статических символов и символов модулей ядра. После предоставление файла System.map в нужное место очень полезно послать сигнал SIGUSR1. Этот сигнал используется для извещения демона, что модули ядра загрузились/выгрузились. Отправление этого сигнала демону после изменения состояния модуля ядра гарантирует правильное определение символов в случае возникновения ошибки защиты в адресном пространстве занимаемом модулем ядра.

ФАЙЛЫ

/proc/kmsg: Первый источник сообщений ядра для klogd
/var/run/klogd.pid: Файл, содержащий id процесса klogd
/boot/System.map, /System.map, /usr/src/linux/System.map: Расположение по умолчанию kernel system maps.

БАГИ

Вероятно много. Принимаются хорошо описанные diffы.

АВТОР

klogd изначально был написан Steve Lord (lord@cray.com), Greg Wettstein сделал основные усовершенствования.

Dr. Greg Wettstein (greg@wind.enjellic.com)
Enjellic Systems Development

Oncology Research Divsion Computing Facility
Roger Maris Cancer Center
Fargo, ND 58122

ПЕРЕВОД

Оригинал взят из sysklogd-1.3-31

Перевод выполнил Юрий Козлов, очень рад замечаниям по адресу y_kozlov@chat.ru.

Пнд Июл 31 20:22:53 MSD 2000

Сергиев-Посадская LUG spslug.sposad.ru

HomePage www.chat.ru/~y_kozlov