11

When my kernel boots, apart from the useful important information, it prints lots of debugging info, such as

....
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)

and much much more.

I don't see how this can be useful to anybody other than a kernel developer/debugger.

I have found, that I can get rid of these by using loglevel=5 as boot parameter. The debugging logs are no longer printed on the terminal, but they are still in dmesg and in syslog.

Is it possible to decrease the boot log verbosity globally, so that dmesg and syslog are not flooded by this useless information ?

I am using self compiled kernel 3.18

ACEPTED SOLUTION

Turns out, putting following lines to /etc/rsyslog.conf solved the problem for me:

kern.debug   /dev/null
& ~
  • What is the actualy problems which you are trying to solve? Too big logfiles? Asking since I see no problem with having this information in a log which usually is not read by humans and whose size increase is trivial. – Hennes Sep 17 '15 at 12:58
  • @Hennes - the problem is, that syslog and dmesg are flooded with useless debugging logs, and thereby making real warnings and errors easier to overlook. Besides, dmesg and syslog should be read by humans (i.e. the administrator). That is their whole purpose. – Martin Vegter Sep 17 '15 at 13:03
  • Concern about flooding important information is a good point. – Hennes Sep 17 '15 at 13:10
  • 1
    You may be interested by this question on the Superuser Stack-Exchange website: How to stop kernel messages from flooding my console? – perror Sep 19 '15 at 21:53
5
+300

For syslog You can add following line to /etc/syslog.conf:

kern.info; kern.debug   /dev/null

It will discard kernel .info and .debug messages ( which are discarded with loglevel=5 )

Also, dmesg can be used with option -n to show messages with certain loglevel.

4

Some of the logs are printed by printk() which you could not turn it off. And some are printed by pr_debug() which may be turned off depends on the configuration of the kernel. The behavior of pr_debug() is controlled by the dynamic debug feature. If CONFIG_DYNAMIC_DEBUG is set, then all pr_debug() calls can be dynamically enabled/disabled per-callsite. The detail of dynamic debug is here. If CONFIG_DYNAMIC_DEBUG is not set, but DEBUG is defined in source file, pr_debug() works like printk(). If both are not defined, pr_debug will do nothing.

Here is the definition in kernel:

#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

So, check your kernel configuration and find where these logs come from. Then you will know how to disable it.

0

Besides setting the loglevel from the KCL, you can also tweak the the kernel.printk sysctl so that the maximum level reflects what you want and persists across boot.

As to this further clarification in comment:

the problem is, that syslog and dmesg are flooded with useless debugging logs, and thereby making real warnings and errors easier to overlook.

I'd just use logrotate in a cron job to move the files out of the way after reboot:

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
}

Then you're starting fresh, so to speak, with limited debug data dumping to logs.

  • I am sorry, but suggesting logrotate completely misses the point. My problem is not that my logfiles are too large, and that I am running out of disk space. Instead, the problem is, the debugging information in those logfiles makes useful information less accessible. – Martin Vegter Oct 14 '15 at 20:33
  • Right. Use logrotate to move the log with all that crap out of the way, so that you have an empty log file after boot, so you can see what matters. My use of logrotate here isn't canonical: use mv if you want. The point is to get the crap out of the way as soon after boot as possible. – bishop Oct 15 '15 at 2:27
  • Unless you mean these messages obscure boot time problems? In which case, the accepted solution seems ideal. – bishop Oct 15 '15 at 2:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.