Bug 18369

Created attachment 7742 [details]
tty2 filled with logs

Created attachment 7743 [details]
opened on the tty2 mc screen filled with logs

I don't have that problem in cauldron with the applications I use in a VT, but I never use mc. I do only logs when switching to a VT and attaching an external HD at the same time, so it's a bit hard to log in there, but for me there's no problem beyond that.

I'm wondering whether logging to VTs works differently with different kernels. Which kernel do you use?

CC: (none) => marja11, tmb

$ uname -r
4.6.0-server-0.rc7.2.mga6

It is not related to any application. Just switch to any VT and watch the screen getting filled with logs. Even login at VT is not needed. The logs get written only on the opened VT. It does not happen in the background.

I do not remember when it started? Maybe about 2 months ago?

OK, that might be why I don't see it: I have kernel-desktop here

What is the output of (as root)

   sysctl kernel.printk

CC: tmb => (none)
Assignee: bugsquad => tmb
Summary: Cauldron virtual terminals are filled with logs => Cauldron virtual terminals are filled with logs (using kernel-server)
Source RPM: (none) => kernel-4.6.0-0.rc7.2.mga6

This is happening for me also and has been doing so for some time.

It appears to only occur when running kernel-sever.

All are 2 line audit entries
[xxxxxx.xxxxxx] audit: blah blah-------------
blah blah------------------------------------

Most if not all the entries are specific services or application for logged-in user and are also present if user is root.
If a service or app is respawning the VT is continuously filled and rendered unusable.

root@SuperSize x86_64]# sysctl kernel.printk
kernel.printk = 7	4	1	7

CC: (none) => cae

(In reply to Charles Edwards from comment #6)
> This is happening for me also and has been doing so for some time.
> 
> It appears to only occur when running kernel-sever.
> 
> All are 2 line audit entries
> [xxxxxx.xxxxxx] audit: blah blah-------------
> blah blah------------------------------------
> 
> Most if not all the entries are specific services or application for
> logged-in user and are also present if user is root.
> If a service or app is respawning the VT is continuously filled and rendered
> unusable.
> 
> root@SuperSize x86_64]# sysctl kernel.printk
> kernel.printk = 7	4	1	7

Does it help if you edit 

   /proc/sys/kernel/printk

and change the first value to 4?

(dunno whether a reboot would be needed)

IIUC, the "7" means that any messages will be shown, regardless of severity level, see
https://en.wikipedia.org/wiki/Syslog#Severity_level
A "4" shows only warnings and worse, but not level 5, 6 and 7 messages.

(The 7 at the end of the line is OK, afaik,  because that's for when booting)

I have "4	4	1	7" here in my system using kernel-desktop, that doesn't have the flooding problem.

Editing /proc/sys/kernel/printk and setting 1st value to 4 does solve my issue.
The effect was immediate no reboot was needed.

Thanks.

Yes, the same situation here:
# sysctl kernel.printk
kernel.printk = 7       4       1       7

Changing the first value to 4 cures the VT log flooding problem immediately.

are you guys using grub2 ?
if so, has the word "quiet" disappeared from kernel command line ?

if there is no "quiet" kernel defaults lo loglevel 7, if "quiet" is there it defaults to 4

Somwhere along changes to grub2 and/or drakx, the default options have gone missing :/

CC: (none) => thierry.vignaud, zen25000

(In reply to Thomas Backlund from comment #10)
> are you guys using grub2 ?
> if so, has the word "quiet" disappeared from kernel command line ?
> 
> if there is no "quiet" kernel defaults lo loglevel 7, if "quiet" is there it
> defaults to 4
> 
> Somwhere along changes to grub2 and/or drakx, the default options have gone
> missing :/


My understanding is for grub2 those changes now need to be made in /etc/default/grub.
For guiet you would need to add|change it to:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


FWIW when testing x86_64 sta1.iso I had to add the line
GRUB_CMDLINE_LINUX_DEFAULT="nokmsboot"
to prevent X set-up from looping after installing kernel-server and wanting to use
the nvidia driver.

Installed kernel-desktop-latest and the situation is the same - VT's are filled with logs.

# uname -r
4.6.0-desktop-0.rc7.3.mga6

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

And yes, I'm using grub2 due to having btrfs at both / and /home - at least it (using grub2) was so configured during install.

I have no that line: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
in /etc/default/grub

Inserting that line and running "update-grub" solves the reported problem.

Now: 
# sysctl kernel.printk
kernel.printk = 4       4       1       7
even for kernel-server

So it seems to be related to grub2 not to kernel-server...

Forgot to mention, that now the Plymouth boot screen is displayed again as it was previously missing for obvious reasons :)

One more comment: running again "drakboot" and reconfiguring the system removes the line GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" from /etc/default/grub

After today morning updates (4.6.2-server-1.mga6 + several drak packages)
the grub2 configuration remained correct, plymouth boot screen was displayed and
# sysctl kernel.printk displayed:
kernel.printk = 4       4       1       7

So, can we mark this bug as resolved?

(In reply to Jüri Ivask from comment #15)
> After today morning updates (4.6.2-server-1.mga6 + several drak packages)
> the grub2 configuration remained correct, plymouth boot screen was displayed
> and
> # sysctl kernel.printk displayed:
> kernel.printk = 4       4       1       7
> 
> So, can we mark this bug as resolved?

Yes, thanks for the feedback

@ Charles

Of course, if this bug is still valid for you, then please reopen it.

Status: NEW => RESOLVED
Resolution: (none) => FIXED