Bug 199305 - sysvinit re-exec doesn't preserve WAITING state
Summary: sysvinit re-exec doesn't preserve WAITING state
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: SysVinit   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-18 19:47 UTC by Jonathan Peatfield
Modified: 2014-03-17 03:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-18 20:54:13 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
possible patch for EL3 2.85 version, the one for 2.86 differs only by a few lines (309 bytes, patch)
2006-07-18 19:47 UTC, Jonathan Peatfield
no flags Details | Diff

Description Jonathan Peatfield 2006-07-18 19:47:44 UTC
Description of problem:

When init re-execs itself (from telinit u etc), it doesn't (attempt to) preserve
the WAITING flag, so if this happens while a startup script (say) is being run,
init goes off and runs the next init line in the inittab anyway...

Version-Release number of selected component (if applicable):

I've checked the source of SysVinit-2.85-4.4 (from EL3), but the same code seems
to be present in the version in EL4 and in the upstream 2.86

How reproducible:


Steps to Reproduce:
1.  (this is a trivial example) add inittab entries like


where each script does some work and sleeps before finishing off.

#! /bin/bash
exec >> /root/abyno 2>&1
echo in test1
sleep 60
echo 'got to end!'

(and similar for the other).

On HUP'ing init they would be run (normally) in order: test1, test2.

2. kill -1 1
3. telinit u
Actual results:

as soon as the telinit u is sent the 2nd script is started (before the fist has

Expected results:

the 2 scripts to run in order as they would without the 'telinit u'

Additional info:

In the default EL3/EL4 /etc/inittab we have entries like:

l5:5:wait:/etc/rc.d/rc 5
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
x:5:respawn:/etc/X11/prefdm -nodaemon

if one of the init scripts from rc5.d results in 'telinit u' happening then the
getty's and gdm (or whatever) get started *before* the init scripts have
finished.  In particular this is likely to be before xfs gets started so gdm
won't work very well (this scares the hell out of my users!)

In my case an init script attempts to apply missed updates (e.g. from when a
machine was off etc), so when (say) glibc (or sysvinit) get upgraded the
postinstall scriptlet ends up doing a telinit u so gdm (and getty's) get
spawned.  My users seem to think that the machine is broken and tend to turn it
back off again...  The flashing X/gdm failing can eventually get to the 'I can't
start an X server' warning which worries some users...

Of course there might be a good reason why WAITING isn't preserved over a
re-exec, but I don't understand the code well enough to be 100% sure.

Comment 1 Jonathan Peatfield 2006-07-18 19:47:44 UTC
Created attachment 132617 [details]
possible patch for EL3 2.85 version, the one for 2.86 differs only by a few lines

Comment 2 Bill Nottingham 2006-08-18 20:54:13 UTC
This is fixed for RHEL 5, and in the current rawhide Fedora Core development
tree. At this point, it is not planned to be backported to previous Red Hat
Enterprise Linux releases.

Comment 3 Bill Nottingham 2006-08-18 20:54:56 UTC
Clarify - at least not to RHEL 3.

Comment 4 Jonathan Peatfield 2006-08-18 21:13:15 UTC
Note that I did report this issue to the upstream author, but got no reply at all.

From the fc-devel SysVinit-2.86-11.src.rpm it looks like the
sysvinit-2.86-godot.patch is doing what I was suggesting.  I don't think I can
look at the EL5 sources to check those (or if I can I don't know where to look!)

If you think that it won't break anything (much), I'm happy to build my own
versions for here on EL3/4 (since who knows when EL5 will be available -- or

However, if a later update of yours reverts this I'd probably be slightly upset.

ie if there arn't going to be fixes for EL3/4 then fine. if any later fixes
include the patch also fine.  If a patch (e.g. one still going through qa etc)
undoes this fix then it will cause me more work...

Comment 5 Bill Nottingham 2006-08-18 21:58:28 UTC
RHEL 5 is going to be using at least what's in FC devel. The reason I say that
it's not planned for RHEL 3 is that I doubt we'll be doing any updates for RHEL
3 for SysVinit at this stage in RHEL 3's lifecycle.

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