Help - Search - Members - Calendar
Full Version: Incredible amounts of kernel logs
OESF Portables Forum > Model Specific Forums > Gemini PDA > Gemini PDA - Linux OS
DonOregano
The amount of logs generated by the kernel in TP1 & TP2 is astounding. Is there any way to turn off or reduce these logs? They make the system log difficult to use for debugging other things...
Kiriririn
You can install systemd from stretch-backports, and then set ReadKMsg=no (I think that setting may already be in place by default)
Murple2
You should be able to
CODE
cat /proc/sys/kernel/printk w x y z


where you substitute the letters for the desired numbers below

0 - emergency
1 - alert
2 - critical
3 - error
4 - warning
5 - notice
6 - informational
7 - debug

Or you can put quiet in your kernel command line (or loglevel=X)

Or you can
CODE
sudo dmesg -n 1
or dmesg -D (off) and dmesg -E (on) to toggle console messages on/off

Or you create / edit /etc/sysctl.conf and add
CODE
kernel.printk = w x y z
substituting the numbers from above.

QUOTE(Kiriririn @ Jul 7 2018, 11:16 PM) *
You can install systemd from stretch-backports, and then set ReadKMsg=no (I think that setting may already be in place by default)


I wouldn't install systemd just to get functionality that already exists several times over. But if you do then be aware that recent versions of systemd no longer read /etc/sysctl.conf and look in /etc/sysctl.d/*.conf
Kiriririn
QUOTE(Murple2 @ Jul 8 2018, 09:00 AM) *
You should be able to
CODE
cat /proc/sys/kernel/printk w x y z


where you substitute the letters for the desired numbers below

0 - emergency
1 - alert
2 - critical
3 - error
4 - warning
5 - notice
6 - informational
7 - debug

Or you can put quiet in your kernel command line (or loglevel=X)

Or you can
CODE
sudo dmesg -n 1
or dmesg -D (off) and dmesg -E (on) to toggle console messages on/off

Or you create / edit /etc/sysctl.conf and add
CODE
kernel.printk = w x y z
substituting the numbers from above.

QUOTE(Kiriririn @ Jul 7 2018, 11:16 PM) *
You can install systemd from stretch-backports, and then set ReadKMsg=no (I think that setting may already be in place by default)


I wouldn't install systemd just to get functionality that already exists several times over. But if you do then be aware that recent versions of systemd no longer read /etc/sysctl.conf and look in /etc/sysctl.d/*.conf


All of those only affect what is printed to TTYs, which in this case would be the serial console

It's not clear whether the OP is referring to that, to dmesg, or to the systemd journal
Murple2
QUOTE(Kiriririn @ Jul 8 2018, 12:14 PM) *
QUOTE(Murple2 @ Jul 8 2018, 09:00 AM) *
You should be able to
CODE
cat /proc/sys/kernel/printk w x y z


where you substitute the letters for the desired numbers below

0 - emergency
1 - alert
2 - critical
3 - error
4 - warning
5 - notice
6 - informational
7 - debug

Or you can put quiet in your kernel command line (or loglevel=X)

Or you can
CODE
sudo dmesg -n 1
or dmesg -D (off) and dmesg -E (on) to toggle console messages on/off

Or you create / edit /etc/sysctl.conf and add
CODE
kernel.printk = w x y z
substituting the numbers from above.

QUOTE(Kiriririn @ Jul 7 2018, 11:16 PM) *
You can install systemd from stretch-backports, and then set ReadKMsg=no (I think that setting may already be in place by default)


I wouldn't install systemd just to get functionality that already exists several times over. But if you do then be aware that recent versions of systemd no longer read /etc/sysctl.conf and look in /etc/sysctl.d/*.conf


All of those only affect what is printed to TTYs, which in this case would be the serial console

It's not clear whether the OP is referring to that, to dmesg, or to the systemd journal


I'm guessing systemd journal isn't installed seeing as you are suggesting the OP installs systemd. Your suggestion just disables kernel messages within the journald, which probably isn't what the OP wanted (particularly if it isn't even installed!). I also think my suggestions would suppress messages to other programs (eg journald) and not just the TTYs as you assert. (OK I admit, some of the suggestions not all)

Edit : Sorry,, I've given up smoking and I'm a little tetchy...
DonOregano
Well, to clarify what I was after, I wanted to be able to use dmesg -w without getting drowned in stuff, and journalctl -f without getting inundated.
On a "normal" debian system I have never had these amounts of logs. Also I was thinking that with the amount of logging there must be a little too much disk access being generated, which would reduce battery life...
mithrandir
QUOTE(DonOregano @ Jul 11 2018, 02:30 AM) *
Well, to clarify what I was after, I wanted to be able to use dmesg -w without getting drowned in stuff, and journalctl -f without getting inundated.
On a "normal" debian system I have never had these amounts of logs. Also I was thinking that with the amount of logging there must be a little too much disk access being generated, which would reduce battery life...

I think the journal does not get persisted. At least journalctl -b1 tells "no persisted journal was found". So there should be no disk access. However, the exessive logging at least generates some CPU usage which consumes a bit battery.
Kiriririn
QUOTE(DonOregano @ Jul 11 2018, 11:30 AM) *
Well, to clarify what I was after, I wanted to be able to use dmesg -w without getting drowned in stuff, and journalctl -f without getting inundated.
On a "normal" debian system I have never had these amounts of logs. Also I was thinking that with the amount of logging there must be a little too much disk access being generated, which would reduce battery life...


My above suggestion hides kernel logs from journalctl, but doesn't help with dmesg. In my kernel fork you can find a couple of commits that hack out the worst offenders https://github.com/lukefor/gemini-linux-kernel-3.18

You may also want to disable logd, which is the worst for CPU usage - see https://www.oesf.org/forum/index.php?showtopic=35245

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2019 Invision Power Services, Inc.