From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207
Description of problem:
Sometimes the system hangs on boot after printing "Finding module
dependencies:". Using SysRq-T shows that there are two instances on minilogd in
the "D" state. The bug is not 100% reproducible. Since I'm never use stock
RedHat kernels, I don't know if they have this problem.
One of the systems exhibits it only when run in text mode (framebuffer is
disabled). Another started hanging after I changed the kernel configuration
reducing the number of modules.
If I add a dummy action to /etc/rc.d/rc.sysinit, the hang is almost certain:
# The root filesystem is now read-write, so we can now log
# via syslog() directly..
if [ -n "$IN_INITLOG" ]; then
action "Dummy action" true # This is added
It seems that minilogd doesn't have time to exit if depmod finished too early,
and then minilogd becomes locked in memory because initlog opens a connection to
it instead of using syslog.
Perhaps Red Hat stock kernels are less vulnerable because they have many
modules. minilogd has time to terminate before the results from depmod are shown.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Recompile the kernel with less modules
2. Install it
3. Reboot the system
Actual Results: System hangs after displaying "Finding module dependencies:"
Expected Results: System boots
It seems that the bug has already been reported, but it was dismissed. See bugs
Bugs when minilogd leaks memory (#22196, #46545) may have to do with the fact
that minilogd fails to exit.
When the hang happens, there are two minilogd processes running. Their parents
are two different initlog processes. Both initlog processes are children of the
same rc.sysinit process. The tree with PID numbers:
init(1) -> init(15) -> rc.sysinit(16) -> initlog(17) -> minilogd(84)
-> initlog(83) -> minilogd(85)
minilogd with PID 84 is waiting in bind() called from main(). minilogd with PID
85 is waiting in unlink() called from main() just one line above. This was
discovered by adding print statements that write output to /dev/console.
Both minilogd processes are hanging in the kernel in the "D" state. The problem
can be reproduced with the stock 2.4.21-rc1-ac3 kernel, but not with any recent
Right now, the hang happens approximately for two third of boots. If there is
no hang, I see only minilogd with PID 84 being launched, and it goes beyond bind().
I'm using Red Hat 8.0 with initscripts-6.95-1. The problem also exists on Red
Hat 9.0, also on the Intel platform.
What is the output of alt-sysrq-p when it's stuck?
Created attachment 91499 [details]
Output of Alt-SysRq-P and Alt-SysRq-T
This is the output of Alt-SysRq-P and Alt-SysRq-T. I was using serial console.
Apart from that, it's the same Red Hat 8.0 system with all updates.
Created attachment 91500 [details]
Same output after running it through ksymoops
You can clearly see that both minilogd processes hang in devfs code. I
couldn't reproduce the hang when devfs is not mounted.
Well, that explains why I've never seen it here.
Closing as we don't enable or support devfs; you might want to take this up with
the upstream devfs maintainer.