Linux – How to find out a linux kernel ring buffer size

Tcpdump has the option -B to set the capture buffer size. The value is then passed to libpcap (library used by tcpdump to do the actual packet capturing) via pcap_set_buffer_size() function. Tcpdump manpage does not specify in what units the buffer size is specified with -B, but from the source it seems that it is KiB.

manual page of pcap_set_buffer_size() does not specify default buffer size (which is used if this function is not called), but again, from the libpcap source, this seems to be 2 MiB, at least on linux (but is most likely system dependent).

With regard to packet buffering and dropping, you should also pay attention to setting snaplen (-s) parameter accordingly. man tcpdump:

-s     Snarf  snaplen bytes of data from each packet rather than the
default of 65535 bytes.  Packets truncated because of a limited snapshot
are indicated in the output with ``[|proto]'', where proto is the name of
the protocol level at which the truncation has occurred. Note that  taking
larger  snapshots both increases the amount of time it  takes  to
process packets and, effectively, decreases the amount of packet buffering.
This may cause packets to be lost. You should limit snaplen to the
smallest number that will capture the protocol information you're
interested in. Setting snaplen to 0 sets it to the default of 65535, for
back-wards compatibility with recent older versions of tcpdump.

This means that with fixed buffer size, you can increase the number of packets that fit into the buffer (and thus not being dropped) by decreasing the snaplen size.

Yes, all of this has to do with logging. No, none of it has to do with runlevel or "protection ring".

The kernel keeps its logs in a ring buffer. The main reason for this is so that the logs from the system startup get saved until the syslog daemon gets a chance to start up and collect them. Otherwise there would be no record of any logs prior to the startup of the syslog daemon. The contents of that ring buffer can be seen at any time using the dmesg command, and its contents are also saved to /var/log/dmesg just as the syslog daemon is starting up.

All logs that do not come from the kernel are sent as they are generated to the syslog daemon so they are not kept in any buffers. The kernel logs are also picked up by the syslog daemon as they are generated but they also continue to be saved (unnecessarily, arguably) to the ring buffer.

The log levels can be seen documented in the syslog(3) manpage and are as follows:

• LOG_EMERG: system is unusable
• LOG_ALERT: action must be taken immediately
• LOG_CRIT: critical conditions
• LOG_ERR: error conditions
• LOG_WARNING: warning conditions
• LOG_NOTICE: normal, but significant, condition
• LOG_INFO: informational message
• LOG_DEBUG: debug-level message

Each level is designed to be less "important" than the previous one. A log file that records logs at one level will also record logs at all of the more important levels too.

The difference between /var/log/kern.log and /var/log/mail.log (for example) is not to do with the level but with the facility, or category. The categories are also documented on the manpage.