From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5 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 IN_INITLOG= fi 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): initscripts-6.95-1 How reproducible: Sometimes 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 Additional info: It seems that the bug has already been reported, but it was dismissed. See bugs #1264, #11352. 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 2.5.x kernels. 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.