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

  • What do the messages look like? (Personally, I generally work in an xterm window, so if the console is flooded it doesn't bother me.) – Keith Thompson Oct 27 '11 at 23:15
  • At the risk of stating the obvious, the messages are coming from Shorewall (which I've never used, so I can't help much). Adding a shorewall or firewall tag might get more useful attention. – Keith Thompson Oct 28 '11 at 0:10
  • @KeithThompson: the messages are coming through the kernel logging mechanism. Shorewall is just one producer of these messages (via iptables kernel modules), the most annoying one, but all kernel-generated messages are shown there. – haimg Oct 28 '11 at 0:20

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.


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)


# 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


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:


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.


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

  • This is exactly what I wanted! I just wanted to disable the messages temporarily in one terminal while I debug the problem that is generating them. – ntc2 Feb 15 '18 at 23:53

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

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.

  • Question says that stopping the syslog daemon has already been tried, and that's not enough – Toby Speight Feb 19 at 15:22

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.