уменьшить уровень детализации журнала загрузки ядра

9

Когда мое ядро ​​загружается, помимо полезной важной информации, оно печатает много отладочной информации, такой как

....
kernel: [0.00000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d3ff] usable
kernel: [0.00000] BIOS-e820: [mem 0x000000000009d400-0x000000000009ffff] reserved
kernel: [0.00000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
...
kernel: [0.00000] MTRR variable ranges enabled:
kernel: [0.00000]   0 base 0000000000 mask 7E00000000 write-back
...
kernel: [0.00000] init_memory_mapping: [mem 0x00100000-0xcf414fff]
kernel: [0.00000]  [mem 0x00100000-0x001fffff] page 4k
kernel: [0.00000]  [mem 0x00200000-0xcf3fffff] page 2M
kernel: [0.00000]  [mem 0xcf400000-0xcf414fff] page 4k
....
kernel: [0.00000] ACPI: XSDT 0xD8FEB088 0008C (v01 DELL CBX3 01072009 AMI 10013)
kernel: [0.00000] ACPI: FACP 0xD8FFC9F8 0010C (v05 DELL CBX3 01072009 AMI 10013)
....
kernel: [0.00000] Early memory node ranges
kernel: [0.00000]   node   0: [mem 0x00001000-0x0009cfff]
kernel: [0.00000]   node   0: [mem 0x00100000-0xcf414fff]
kernel: [0.00000]   node   0: [mem 0xcf41c000-0xcfdfcfff]
....
kernel: [0.00000] ACPI: Local APIC address 0xfee00000
kernel: [0.00000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
kernel: [0.00000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)

и многое, многое другое.

Я не понимаю, как это может быть полезно кому-либо, кроме разработчика / отладчика ядра.

Я обнаружил, что могу избавиться от них, используя в loglevel=5качестве параметра загрузки. Журналы отладки больше не печатаются на терминале, но они все еще находятся внутри dmesgи внутри syslog.

Можно ли уменьшить многословность загрузочного журнала глобально, чтобы dmesgи syslogне залиться этой бесполезной информацией?

Я использую само скомпилированное ядро 3.18

ПРИНЯТО РЕШЕНИЕ

Оказывается, поставив следующие строки, /etc/rsyslog.confрешил проблему для меня:

kern.debug   /dev/null
& ~
Мартин Вегтер
источник
Какие именно проблемы вы пытаетесь решить? Слишком большие лог-файлы? Спрашивая, поскольку я не вижу проблем с наличием этой информации в журнале, который обычно не читается людьми и увеличение размера которого тривиально.
Хеннес
@Hennes - проблема в том, что syslogи dmesgзалиты бесполезных журналов отладки, и , таким образом , делая реальные предупреждения и ошибки легче заметить. К тому же dmesgи syslogдолжен быть прочитан людьми (т.е. администратором). Это все их цель.
Мартин Вегтер
Беспокойство о затоплении важной информации является хорошим моментом.
Хеннес
1
Вас может заинтересовать этот вопрос на веб-сайте Superuser Stack-Exchange: как остановить сообщения ядра от переполнения моей консоли?
perror

Ответы:

5

Для системного журнала Вы можете добавить следующую строку /etc/syslog.conf:

kern.info; kern.debug   /dev/null

Это отбросит сообщения ядра .info и .debug (которые отбрасываются с loglevel = 5)

Кроме того, dmesgможет использоваться с возможностью -nпоказывать сообщения с определенным уровнем логирования.

Marqin
источник
4

Некоторые журналы печатаются с помощью printk (), который вы не можете отключить. И некоторые из них печатаются с помощью pr_debug (), который может быть отключен в зависимости от конфигурации ядра. Поведение pr_debug () контролируется функцией динамической отладки. Если установлено CONFIG_DYNAMIC_DEBUG , то все вызовы pr_debug () могут быть динамически включены / отключены для каждого места вызова. Деталь динамической отладки здесь . Если CONFIG_DYNAMIC_DEBUG не установлен, но DEBUG определен в исходном файле, pr_debug () работает как printk () . Если оба не определены, pr_debug ничего не сделает.

Вот определение в ядре:

#include <linux/dynamic_debug.h>

/* If you are writing a driver, please use dev_dbg instead */
#if defined(CONFIG_DYNAMIC_DEBUG)
/* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
#define pr_debug(fmt, ...) \
    dynamic_pr_debug(fmt, ##__VA_ARGS__)
#elif defined(DEBUG)
#define pr_debug(fmt, ...) \
    printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#else
#define pr_debug(fmt, ...) \
    no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#endif

Итак, проверьте конфигурацию вашего ядра и найдите, откуда эти журналы. Тогда вы узнаете, как его отключить.

Крис Цуй
источник
Также не забудьте echo 8 > /proc/sys/kernel/printk: stackoverflow.com/questions/28936199/…
Сиро Сантилли 冠状 病毒 审查 六四 事件 法轮功
0

Помимо настройки loglevelиз KCL, вы также можете настроить kernel.printksysctl так, чтобы максимальный уровень отражал то, что вы хотите, и сохранялся при загрузке.

Что касается этого дальнейшего разъяснения в комментарии:

проблема заключается в том, что syslog и dmesg заполнены бесполезными журналами отладки, что позволяет упускать из виду реальные предупреждения и ошибки.

Я бы просто использовал logrotateв работе cron, чтобы убрать файлы с пути после перезагрузки :

root ~ $ crontab -l
@reboot /usr/sbin/logrotate --force /root/rotate-boot-messages
@reboot /bin/dmesg -c

root ~ $ cat /root/rotate-boot-messages
"/var/log/dmesg" {
  copytruncate
  notifempty
  missingok
  dateext
}
"/var/log/syslog" {
  copytruncate
  notifempty
  missingok
  dateext
}

Тогда вы начинаете, так сказать, с нуля, с ограниченным сбросом отладочных данных в журналы.

епископ
источник
Прошу прощения, но предлагать logrotateсовершенно не суть. Моя проблема не в том, что мои файлы журналов слишком велики, а в том, что у меня недостаточно места на диске. Вместо этого проблема в том, что отладочная информация в этих лог-файлах делает полезную информацию менее доступной.
Мартин Вегтер
Правильно. Используйте logrotate для перемещения журнала со всем этим дерьмом, чтобы у вас был пустой файл журнала после загрузки, чтобы вы могли видеть, что имеет значение. Мое использование logrotate здесь не канонично: используйте mv, если хотите. Суть в том, чтобы избавиться от этого дерьма как можно скорее после загрузки.
епископ
Разве вы не имеете в виду, что эти сообщения скрывают проблемы с загрузкой? В этом случае принятое решение кажется идеальным.
епископ