When using metalog with active function of console log, then after a time it leads to system unstability, and thousands of ooopses in loop (null pointer). Especially if activated udev_log in /etc/udev/udev.conf. System create device node for the log console, and then delete it, and so on. Reproducible: Sometimes Steps to Reproduce: 1. activate console log 2. activate udev_log (not necessary but lead to faster oops) 3. wait, observe console, or console log Actual Results: after a time a lot of oopses.
What is dying here, udev, or metalog?
It seems that kernel. When you switch on console log, then udev create an device node for the console when each message come, and then delete it. If you switch on udev_log, then there also created messages informing that device node for the console log is created and deleted (in practice never ending loop). It seems that if on this time happen something wrong with sys subsystem then device node for console log cannot be created/deleted and it lead to oopses. In such case not any operation can be performed (only switch off power supply). I think that as solution the console for log should be opened once on start of metalog, and closed on shut down of metalog, and not for each particular message.
Created attachment 43216 [details] dmesg output Ok, I don't have udev_log activated, but I have the same problems. I have dumped the output and here is a part of it
*** Bug 68869 has been marked as a duplicate of this bug. ***
Reassigning to kernel. Greg, do these oops's make any sense to you? To anyone with this problem: Does development-sources-2.6.10-rc1 resolve the issue? What happens if you take metalog out of your runlevels?
No, these oopses don't make sense to me. Try filing a bug at bugzilla.kernel.org for this.
Anyway, in my opinion to display each particular message system shouldn't create device node for that message, and delete it after message is displayed. The device node should be created once.
That's an issue with metalog, not the kernel.
