Bug 201146 - sysvinit re-exec doesn't preserve WAITING state
Summary: sysvinit re-exec doesn't preserve WAITING state
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: SysVinit
Version: 4.0
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
: ---
Assignee: Bill Nottingham
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-03 07:10 UTC by Bastien Nocera
Modified: 2014-03-17 03:01 UTC (History)
2 users (show)

Fixed In Version: RHBA-2007-0293
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-05-01 17:26:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0293 0 normal SHIPPED_LIVE SysVinit bug fix update 2007-05-01 17:25:40 UTC

Description Bastien Nocera 2006-08-03 07:10:05 UTC
+++ This bug was initially created as a clone of Bug #199305 +++

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:

100%

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

jsp1:5:wait:/root/test1
jsp2:5:wait:/root/test2

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

e.g.
#! /bin/bash
#
exec >> /root/abyno 2>&1
echo in test1
date
sleep 60
date
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
finished).

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.

-- Additional comment from J.S.Peatfield.ac.uk on 2006-07-18 15:47 EST --
Created an attachment (id=132617)
possible patch for EL3 2.85 version, the one for 2.86 differs only by a few lines

Comment 1 RHEL Program Management 2006-08-18 14:49:46 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 3 Bill Nottingham 2006-11-21 22:20:43 UTC
Added in SysVinit-2.85-34.4.

Comment 7 Red Hat Bugzilla 2007-05-01 17:26:08 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0293.html



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