Re: [blfs-dev] screen cluttered by kernel messages
On 16/10/2015 16:15, Fernando de Oliveira wrote: Almost OT: I am impressed how your tests results improved. What have you done? Try another machine:-) . Tests are still as bad on the original machine. It looks like there are some race conditions, which depend on processor and disk speeds, but I still want to investigate (also, I have to try on a machine without any LVM partition, to see if one statement about the tests is still valid). My home machine CPU is almost twice faster than the one at work, but the disks are real SCSI at work, while SATA at home. Well, this is relevant information for the ticket. I'll update... Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] screen cluttered by kernel messages
Pierre Labastie wrote:
You gave me pointers to where to look for. Actually, it seems to
me that there is a small issue in rc.site: it has:
"#LOGLEVEL=5"
and I would imagine that it means the default log level is 5. But the
rc script has:
dmesg -n "${LOGLEVEL:-7}"
which means the default level is 7. I'd suggest put "#LOGLEVEL=7" in
rc.site. There is a thread in 2010 (most relevant message is
http://lists.linuxfromscratch.org/pipermail/lfs-dev/2010-February/063518.html)
where Bruce explains why the log level should be 7.
Now, for BLFS, we always assume that the user uses the defaults,
so that log level is 7 (all messages printed except DEBUG). In this
case, running the LVM test just renders any virtual console unusable
(I have not tried on an X display). What do you think if change the test
command to:
dmesg -D;make -k check;dmesg -E
I've updated the rc.site page in my sandbox. Will be a part of my next
commit to LFS.
-- bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] screen cluttered by kernel messages
Pierre Labastie wrote: Hi, Just want to share something everybody may be knowing already... In the past years, we have seen more and more kernel messages cluttering the screen (when mounting an ext2 system, when setting up network, etc). It culminates with the LVM tests, where it is almost impossible to work on another console during the tests (since the kernel messages go the the console you are working on, not the console where you started the test). The command "dmesg -D" can be used to avoid those annoyances. Normally, critical messages should still show up through the sysklogd system. I had not noticed that option before, but LFS has the option to change the logging level in rc.site or the console config. I normally set the LOGLEVEL to 4 (warn) instead of the default 5 (notice) and haven't seen the problem. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] screen cluttered by kernel messages
Em 16-10-2015 10:20, Pierre Labastie escreveu:
> On 16/10/2015 12:41, Fernando de Oliveira wrote:
>> Em 16-10-2015 02:37, Pierre Labastie escreveu:
>>> Hi,
>>>
>>> Just want to share something everybody may be knowing already...
>>>
>>> In the past years, we have seen more and more kernel messages cluttering
>>> the screen (when mounting an ext2 system, when setting up network, etc).
>>> It culminates with the LVM tests, where it is almost impossible to work
>>> on another console during the tests (since the kernel messages go the
>>> the console you are working on, not the console where you started the
>>> test).
>>>
>>> The command "dmesg -D" can be used to avoid those annoyances. Normally,
>>> critical messages should still show up through the sysklogd system.
>>>
>>> Pierre
>>>
>> It is good discussing this. First time I wrote to help a client, IIRC,
>> DJ warned me, because I instructed a user to change a bootscript. :-)
>>
>> Found in man 2 syslog.
>>
>> Kernel constant Level value Meaning
>> KERN_EMERG 0System is unusable
>> KERN_ALERT 1Action must be taken immediately
>> KERN_CRIT 2Critical conditions
>> KERN_ERR 3Error conditions
>> KERN_WARNING 4Warning conditions
>> KERN_NOTICE5Normal but significant condition
>> KERN_INFO 6Informational
>> KERN_DEBUG 7Debug-level messages
>>
>> I use /etc/sysconfig/rc.site:
>>
>> $ grep LOGLEVEL /etc/sysconfig/rc.site
>> #LOGLEVEL=5
>> LOGLEVEL=3
>>
>>
>> Perhaps it would do with level 4.
> Thanks Fernando,
>
> You gave me pointers to where to look for. Actually, it seems to
> me that there is a small issue in rc.site: it has:
>
> "#LOGLEVEL=5"
>
> and I would imagine that it means the default log level is 5. But the
> rc script has:
>
> dmesg -n "${LOGLEVEL:-7}"
>
> which means the default level is 7. I'd suggest put "#LOGLEVEL=7" in
> rc.site. There is a thread in 2010 (most relevant message is
> http://lists.linuxfromscratch.org/pipermail/lfs-dev/2010-February/063518.html)
>
> where Bruce explains why the log level should be 7.
>
> Now, for BLFS, we always assume that the user uses the defaults,
> so that log level is 7 (all messages printed except DEBUG). In this
> case, running the LVM test just renders any virtual console unusable
> (I have not tried on an X display). What do you think if change the test
> command to:
> dmesg -D;make -k check;dmesg -E
>
> Pierre
>
Both are OK, for me.
But I had seen in man dmesg:
{{{
-n, --console-level level
Set the level at which printing of messages is done to the con‐
sole. The level is a level number or abbreviation of the level
name. For all supported levels see the --help output.
For example, -n 1 or -n alert prevents all messages, except
emergency (panic) messages, from appearing on the console. All
levels of messages are still written to /proc/kmsg, so sys‐
logd(8) can still be used to control exactly where kernel mes‐
sages appear. When the -n option is used, dmesg will not print
or clear the kernel ring buffer.
}}}
Therefore, it is more useful to having default in the rc script and
rc.site as 4, explaining somwhere (if it isn't already done, that all
messages are still logged in /dev/kmsg, and can be read with, e.g.:
dd if=/dev/kmsg iflag=nonblock
I believe they are also in /var/log/sys.log and /var/log/kern.log.
But while this is not discussed, for the status quo, at least the LVM
tests could be modified as you suggested.
Almost OT: I am impressed how your tests results improved. What have you
done?
--
[]s,
Fernando, aka Sísifo
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] screen cluttered by kernel messages
On 16/10/2015 12:41, Fernando de Oliveira wrote:
Em 16-10-2015 02:37, Pierre Labastie escreveu:
Hi,
Just want to share something everybody may be knowing already...
In the past years, we have seen more and more kernel messages cluttering
the screen (when mounting an ext2 system, when setting up network, etc).
It culminates with the LVM tests, where it is almost impossible to work
on another console during the tests (since the kernel messages go the
the console you are working on, not the console where you started the
test).
The command "dmesg -D" can be used to avoid those annoyances. Normally,
critical messages should still show up through the sysklogd system.
Pierre
It is good discussing this. First time I wrote to help a client, IIRC,
DJ warned me, because I instructed a user to change a bootscript. :-)
Found in man 2 syslog.
Kernel constant Level value Meaning
KERN_EMERG 0System is unusable
KERN_ALERT 1Action must be taken immediately
KERN_CRIT 2Critical conditions
KERN_ERR 3Error conditions
KERN_WARNING 4Warning conditions
KERN_NOTICE5Normal but significant condition
KERN_INFO 6Informational
KERN_DEBUG 7Debug-level messages
I use /etc/sysconfig/rc.site:
$ grep LOGLEVEL /etc/sysconfig/rc.site
#LOGLEVEL=5
LOGLEVEL=3
Perhaps it would do with level 4.
Thanks Fernando,
You gave me pointers to where to look for. Actually, it seems to
me that there is a small issue in rc.site: it has:
"#LOGLEVEL=5"
and I would imagine that it means the default log level is 5. But the
rc script has:
dmesg -n "${LOGLEVEL:-7}"
which means the default level is 7. I'd suggest put "#LOGLEVEL=7" in
rc.site. There is a thread in 2010 (most relevant message is
http://lists.linuxfromscratch.org/pipermail/lfs-dev/2010-February/063518.html)
where Bruce explains why the log level should be 7.
Now, for BLFS, we always assume that the user uses the defaults,
so that log level is 7 (all messages printed except DEBUG). In this
case, running the LVM test just renders any virtual console unusable
(I have not tried on an X display). What do you think if change the test
command to:
dmesg -D;make -k check;dmesg -E
Pierre
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] screen cluttered by kernel messages
Em 16-10-2015 02:37, Pierre Labastie escreveu: > Hi, > > Just want to share something everybody may be knowing already... > > In the past years, we have seen more and more kernel messages cluttering > the screen (when mounting an ext2 system, when setting up network, etc). > It culminates with the LVM tests, where it is almost impossible to work > on another console during the tests (since the kernel messages go the > the console you are working on, not the console where you started the > test). > > The command "dmesg -D" can be used to avoid those annoyances. Normally, > critical messages should still show up through the sysklogd system. > > Pierre > It is good discussing this. First time I wrote to help a client, IIRC, DJ warned me, because I instructed a user to change a bootscript. :-) Found in man 2 syslog. Kernel constant Level value Meaning KERN_EMERG 0System is unusable KERN_ALERT 1Action must be taken immediately KERN_CRIT 2Critical conditions KERN_ERR 3Error conditions KERN_WARNING 4Warning conditions KERN_NOTICE5Normal but significant condition KERN_INFO 6Informational KERN_DEBUG 7Debug-level messages I use /etc/sysconfig/rc.site: $ grep LOGLEVEL /etc/sysconfig/rc.site #LOGLEVEL=5 LOGLEVEL=3 Perhaps it would do with level 4. -- []s, Fernando, aka Sísifo -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] screen cluttered by kernel messages
Hi, Just want to share something everybody may be knowing already... In the past years, we have seen more and more kernel messages cluttering the screen (when mounting an ext2 system, when setting up network, etc). It culminates with the LVM tests, where it is almost impossible to work on another console during the tests (since the kernel messages go the the console you are working on, not the console where you started the test). The command "dmesg -D" can be used to avoid those annoyances. Normally, critical messages should still show up through the sysklogd system. Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
