Re: [PATCH v2] printk: Add kernel parameter to disable writes to /dev/kmsg

From: Ingo Molnar
Date: Tue Apr 26 2016 - 01:36:57 EST



* Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:

> On Mon, 25 Apr 2016 12:28:30 -0700
> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> > On Mon, Apr 25, 2016 at 12:06 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> >
> > I think it should be a tristate with "yes/no/ratelimit", and let's
> > default to ratelimit.
> >
>
> Also note that ratelimit wouldn't have solved my issue either. It
> wasn't that systemd was rapidly spewing into the kernel buffers. It was
> doing it gradually, for every connection that I made to the box (lots
> of automated connections were also being logged). I believe something
> happened on Friday but due to all the unnecessary logging over the
> weekend, I lost it.
>
> To make matters worse, I lost my /var/log/syslog data from then.
> logrotate was a bit more destructive than I expected.

I have similar problems with systemd logging. For test kernels I always use the
'debug' option on the boot command line:

BOOT_IMAGE=/boot/bzImage root=/dev/sda2 ro rd.md=0 rd.lvm=0 rd.dm=0
earlyprintk=serial,ttyS0,115200 console=ttyS0,115200 console=tty
SYSFONT=latarcyrheb-sun16 KEYTABLE=us rd.luks=0 LANG=en_US.UTF-8 debug
^^^^^

... to increase the default loglevel to the max, but in this case systemd decides
that it wants to be very chatty, and note how it even mentions this in the comment
(from the latest systemd source code):

static int parse_proc_cmdline_item(const char *key, const char *value) {

/*
* The systemd.log_xyz= settings are parsed by all tools, and
* so is "debug".
*
* However, "quiet" is only parsed by PID 1, and only turns of
* status output to /dev/console, but does not alter the log
* level.
*/

if (streq(key, "debug") && !value)
log_set_max_level(LOG_DEBUG);

else if (streq(key, "systemd.log_target") && value) {

Why systemd does this fully knowing that other software (such as the kernel)
already uses 'debug', while systemd already has the 'system.*' parameter namespace
is left up to the reader...

Thanks,

Ingo