В Linux есть два потенциальных источника для журналирования информации ядра: файловая система /proc и системный вызов (sys_syslog), хотя, в конечном счете, это одно и тоже. Klogd разработан таким образом, что сам выбирает какой источник информации больше всего подходит. Для этого он сначала проверяет, смонтирована ли файловая система /proc . Если да, то файл /proc/kmsg используется в качестве источника информации для журналирования. Если файловая система не смонтирована, демон klogd использует системный вызов, чтобы получить доступ к сообщениям ядра. Для того, чтобы заставить klogd принудительно использовать системный вызов в качестве источника сообщений, можно использовать в командной строке опцию "-s".
Если сообщения ядра направлены через демон syslogd, демон klogd, начиная с версии 1.1, имеет возможность корректно сортировать сообщения ядра согласно их приоритетам (приоритезация). Приоритезация сообщения была добавлена в ядро в версии 0.99pl13. Необработанные сообщения ядра имеют форму:
Приоритет сообщения представлен как односимвольное значение заключенное в <>. Эти значения определены в заголовочном файле ядра kernel.h. Когда сообщение получено из ядра, демон klogd распознает уровень приоритета и назначает соответствующий уровень syslog приоритета для сообщения. Если задан выходной файл посредством (-f), то приоритет добавляется к началу сообщения ядра.
Демон klogd также предоставляет возможность выводить сообщения ядра на системную консоль. Совместно с приоритезацией сообщений ядра было включение изначального уровня сообщений для ядра. В стандартном ядре изначальный уровень сообщений консоли установлен в 7. Любое сообщение с уровнем приоритета ниже чем 7 (наивысший приоритет) появляется на консоли.
Сообщения с уровнем приоритета 7 считаются отладочными сообщениями, и поэтому не будут появляться на консоли. Множество администраторов, особенно в многопользовательских системах, предпочитают, чтобы все сообщения ядра обрабатывались демоном klogd и направлялись в файл либо в демон syslogd. Это предотвращает появление таких неприятных ситуаций как выход за пределы бумаги на принтере или изменение в использовании диска, обнаруженное в беспорядочных сообщениях консоли.
Когда в командной строке передается -c , демон klogd выполнит системный вызов, чтобы подавить вывод на консоль всех сообщений ядра. Предыдущие версии всегда вызывали этот системный вызов и исключали появление всех сообщений ядра за исключением сообщений 'panic'. В настоящие время это обрабатывается по другому, поэтому демону klogd больше не нужно выставлять это значение. Аргумент, представляемый опцией -c, задает уровень приоритета сообщений, которые будут направлены на консоль. Заметьте, что только сообщения с приоритетом МЕНЬШЕ заданного будут направлены на консоль.
klogd -c 4
Если установлены исходные тексты ядра, числовые значения для сообщений ядра можно найти в заголовочном файле ядра kernel.h из каталога /usr/include/linux. Эти значения аналогичны значениям приоритета syslog, которые определены в файле syslog.h из каталога /usr/include/sys.
Демон klogd может быть также использован в режиме 'взгляд' для чтения буферов сообщений ядра. Этот режим задается опцией -o в командной строке. Результат работы будет направлен или в демон syslogd или в альтернативный файл, заданный опцией -f .
klogd -o -f ./krnl.msg
Эта информация ЧРЕЗВЫЧАЙНО ВАЖНА для определения какие условия вызвали внутреннюю ошибку. Но разработчики ядра сталкиваются с трудностями при попытке проанализировать эту информацию. Необработанные числовые данные, представленные в отчете об ошибке защиты, не очень полезны для разработчиков. Это происходит потому, что ядра не идентичны друг другу и адреса расположения переменных или функций не одни и те же в разных ядрах. Для того, чтобы диагностировать причину проблемы, разработчикам необходимо знать, какая конкретная функция ядра или переменная были вовлечены в процесс появления ошибки.
Список, содержащий адреса расположения важных переменных и функций, создается в ходе процесса компиляции ядра. Этот список хранится в файле System.map в корне дерева исходных текстов ядра. Используя этот список, разработчики ядра могут однозначно определить, что ядро делало когда произошла ошибка.
Процесс преобразования числовых значений адресов из отчета об ошибке защиты может быть сделан вручную или с использованием программы ksymoops , поставляемой вместе с исходными текстами ядра.
Для удобства klogd будет пытаться преобразовать числовые значения адресов в их символическую форму, если во время выполнения доступна таблица символов ядра. Если вам необходимы оригинальные адреса символов, используйте опцию -2 , чтобы вывести необработанные адреса. Таблица символов может быть задана опцией -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 был информирован при изменении состояния модуля ядра. Опции -i и -I могут быть использованы для передачи сигнала демону (исполняющемуся в данный момент), чтобы он перезагрузил информацию о символах. Наиболее важная опция для корректного получения символов модуля - это -i . Каждый раз, когда модуль загружается или удаляется из ядра, должна выполняться следующая команда:
klogd -i
Также может быть использована опция -p , чтобы гарантировать, что информация о символах актуальна. Эта опция говорит klogd перезагрузить таблицу символов, как только ошибка защиты обнаруживается. В этом режиме "паранойи", программу необходимо запускать с осторожностью. В момент появления ошибки защиты стабильность ядра и операционного окружения всегда под вопросом. Поскольку для чтения информации о символах демон klogd должен выполнять системные вызовы, существует вероятность того, что система будет слишком нестабильна для получения полезной информации. Намного лучшим решением было бы гарантирование того, что klogd обновляется каждый раз, когда модуль загружается или выгружается. При наличии обновленной информации о символах, вероятность правильного разбора ошибки защиты увеличивается.
Включенный в распространяемые исходные тексты sysklogd, патч к пакету modules-2.0.0, позволяет командам insmod, rmmod и modprobe автоматически генерировать сигнал для klogd каждый раз, когда модуль подключается или отключается из ядра. Использование этого патча гарантирует, что информация о символах в klogd всегда соответствует текущему состоянию ядра.
Сигналы SIGTSTP и SIGCONT используются, чтобы запустить и остановить журналирование сообщений ядра. После получения сигнала SIGTSTP демон закроет источники журналирования и переключиться в режим ожидания, ничего не выполняя. Соответственно, сигнал SIGCONT приказывает демону переинициализироваться и выбрать заново источник журналирования. Используя комбинацию из SIGSTOP и SIGCONT, источник журналирования можно перевыбрать без остановки и перезапуска демона. К примеру, если файловая система /proc отмонтировалась по какой-либо причине, то может быть использована следующая последовательность команд:
Это будет отмечено в системных журналах с приоритетом
LOG_INFO ,
таким образом, документируя запуск/остановку процесса журналирования.
Сигналы SIGUSR1 и SIGUSR2 используются, чтобы инициировать загрузку/перезагрузку информации о символах ядра. Получение сигнала SIGUSR1 загружает заново информацию о символах ядра. Сигнал SIGUSR2 загружает заново информацию о статических символах ядра и информацию о символах модулей ядра.
При условии, что файл System.map находится в соответствующем месте, самый полезный сигнал - SIGUSR1 . Этот сигнал используется, чтобы сообщить демону о том, что модули ядра загружены/выгружены. Посылка этого сигнала демону после изменения состояния модуля ядра, гарантирует, что в случае появления ошибки защиты в адресном пространстве, занимаемом модулем ядра, будет происходить корректное преобразование символов.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |