10

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
& ~
Improve this question
4
  • 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, 2015 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, 2015 at 13:03
  • Concern about flooding important information is a good point.
    – Hennes
    Sep 17, 2015 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, 2015 at 21:53

3 Answers 3

Reset to default
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.

Improve this answer
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.

Improve this answer
1
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.

Improve this answer
3
  • 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, 2015 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, 2015 at 2:27
  • Unless you mean these messages obscure boot time problems? In which case, the accepted solution seems ideal.
    – bishop
    Oct 15, 2015 at 2:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .