Bug 85621 - rc.sysinit hangs after switching to syslogd
rc.sysinit hangs after switching to syslogd
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2003-03-04 23:03 EST by Pavel Roskin
Modified: 2014-03-16 22:34 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-05-05 14:25:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output of Alt-SysRq-P and Alt-SysRq-T (2.73 KB, text/plain)
2003-05-05 14:14 EDT, Pavel Roskin
no flags Details
Same output after running it through ksymoops (7.15 KB, text/plain)
2003-05-05 14:17 EDT, Pavel Roskin
no flags Details

  None (edit)
Description Pavel Roskin 2003-03-04 23:03:01 EST
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):

How reproducible:

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.
Comment 1 Pavel Roskin 2003-05-04 22:24:44 EDT
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.
Comment 2 Bill Nottingham 2003-05-05 12:47:26 EDT
What is the output of alt-sysrq-p when it's stuck?
Comment 3 Pavel Roskin 2003-05-05 14:14:42 EDT
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.
Comment 4 Pavel Roskin 2003-05-05 14:17:15 EDT
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.
Comment 5 Bill Nottingham 2003-05-05 14:25:17 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.