Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
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
up vote 18 down vote accepted

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.

share|improve this answer

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

share|improve this answer

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:

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

You must log in to answer this question.

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