How to stop kernel messages from flooding my console?

Question

I'm using Centos 6, rsyslog logging. Console is flooded with kernel messages.

• Klogd is not running (I'm using rsyslog)
• Rsyslog config does not direct anything to the console
• Even tried stopping rsyslog altogether

Still something is flooding my console with kernel log messages. What it is and how do I make it stop?

Update: These are the messages generated by the kernel (hardware, iptables, etc.), stuff that goes out of /proc/kmsg, like this:

Shorewall:pub2loc:DROP:IN=br0 OUT= MAC=xxx SRC=xxx DST=xxx LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=15731 DF PROTO=TCP SPT=63767 DPT=3493 WINDOW=8192 RES=0x00 SYN URGP=0

Answer 1

I suggest you alter your /etc/sysctl.conf. Specifcally, you want to tweak the kernel.printk line.

# Uncomment the following to stop low-level messages on console
kernel.printk = 3 4 1 3

I am not sure what the centos default settings are, but I seems likely that have things set more verbose then you need.

Also do see the shorewall section on logging. You don't have to use the LOG target for logging, you can use other tools, or adjust the log severity, and tweak things to control where you messages go.

Answer 2

To set the values at runtime, use sysctl. (I suppose one can write to /proc/sys/kernel/printk directly too and apparently you can also use dmesg -n CUR as described here)

Display:

# sysctl kernel.printk
kernel.printk = 2       4       1       7

The separators in the output are single tabs, btw.

Set. Here the separators are just spaces. Works as well.

# sysctl -w kernel.printk="2 4 1 7"
kernel.printk = 2 4 1 7
# sysctl kernel.printk
kernel.printk = 2       4       1       7

See man sysctl - "configure kernel parameters at runtime" for more.

Reminder of the severity levels and the four values of kernel.printk given by Brian above:

• CUR = current severity level; only messages more important than this level are printed
• DEF = default severity level assigned to messages with no level
• MIN = minimum allowable CUR
• BTDEF = boot-time default CUR

On my CentOS: 7 4 1 7

                     CUR  DEF  MIN  BTDEF
0 - emergency        x              x                        
1 - alert            x         x    x
2 - critical         x              x
3 - error            x              x
4 - warning          x    x         x
5 - notice           x              x
6 - informational    V              V
7 - debug            

This is too noisy, I just want critical and up (no errors). Unlabeled messages should be regarded as warning, so DEF is good:

                     CUR  DEF  MIN  BTDEF
0 - emergency        x              x                        
1 - alert            x         x    x
2 - critical         x              x
3 - error            V              V
4 - warning               x         
5 - notice                           
6 - informational                   
7 - debug            

Set to: 3 4 1 3

Answer 3

You can also temporarily suppress all kernel logging to the console by using:

sudo dmesg -n 1

See also: https://askubuntu.com/questions/97256/how-do-i-disable-messages-or-logging-from-printing-on-the-console-virtual-termin

Answer 4

I found this helpful as well. On RHEL based distros you can cat /proc/sys/kernel/printk to see what your current settings are.

Four values are found in the printk file. Each of these values define a different rule for dealing with error messages. The first value, called the console loglevel, defines the lowest priority of messages printed to the console. (Note that, the lower the priority, the higher the loglevel number.) The second value sets the default loglevel for messages without an explicit loglevel attached to them. The third value sets the lowest possible loglevel configuration for the console loglevel. The last value sets the default value for the console loglevel.

Use of the LOGLEVEL parameter in /etc/sysconfig/init to set the console loglevel is no longer supported. To set the console loglevel in Red Hat Enterprise Linux 6, pass loglevel=' as a boot time parameter. For example, loglevel=6 will print all messages less than 6 (not equal to just less than).

Credit to:

• RHEL 6 - E.3.9. /proc/sys/
• Linuxtopia - Kernel Log Levels

Answer 5

Here is the "official" way to do it, according to RedHat:

To set the console loglevel in Red Hat Enterprise Linux 6, pass loglevel=<number> as a boot time parameter.

Answer 6

As this is a stack overflow related site, I'll start by saying you shouldn't switch off the output, you should address the errors.

If you're in a console and can't even see what you're doing because of the messages try typing this.

sudo dmesg -D

That should make it quiet enough to look at the other solutions.

Answer 7

What you see are kernel log messages printed to the console. What log messages reach the console depends on the currently set console log level.

When the kernel cmdline includes the quiet kernel parameter the resulting console log level is 4 (i.e. errors and worse). Without it it is set to 7 (i.e. info and worse).

You can view the active kernel parameters with cat /proc/cmdline and your current console log level with sysctl kernel.printk. It can be dynamically changed with dmesg -n X (or even with sysctl -w).

To make the change permanent you can add kernel parameters to kernel cmdline (e.g. quiet and/or loglevel=X) or add a sysctl .conf file under /etc/sysctl.d.

The kernel parameter can be added like this:

# vi /etc/default/grub # edit the GRUB_CMDLINE_LINUX value
# for i in /boot/grub2/grub.cfg /boot/efi/EFI/*/grub.cfg; do
     [ -f "$i" ] && grub2-mkconfig -o "$i" ; done

Answer 8

Setting dmesg --console-off or dmesg -n 1 did not help here, nor did setting kernel.printk to "0 0 0 0", and even with mesg n set, all my graphic terminals (running on Wayland) would still get (flooded with) kernel messages when a WiFi driver started to act up.

Turns out I had to disable omusrmsg in rsyslog to stop the messages reaching my console:

# Everybody gets emergency messages
#*.emerg                                        :omusrmsg:*

Answer 9

If you are in a real jam you could just disable the syslog service temporarily in the case that there is such a flood that you cannot view or type anything properly.