Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 143289

Summary: init should protect against calls to reexec from within init scripts
Product: [Fedora] Fedora Reporter: Geoff Gustafson <grgustaf>
Component: sysvinitAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dff, jturner, kaccardi, roland, rvokal
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: 2.86-8 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-08-09 19:07:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 150221    

Description Geoff Gustafson 2004-12-18 02:22:17 UTC
Description of problem:
In bug 143046, we tracked down a problem with the 32-bit compatibility glibc
%post script calling "telinit u" -- and running from the context of firstboot,
called from an init script. We will probably come up with a temporary hack to
fix this for RHEL4 pre-rc2 or GA, but it sounds like the right fix is in init.

Comment 1 Roland McGrath 2004-12-18 10:46:35 UTC
To clarify, what we think is the reduced basic test case is an init script that
does "telinit u".  That makes init re-exec itself, and then it does something
like go on to the "rc 2" while the "rc 1" is still running or something along
those lines.  This came up in the context of firstboot installing the i386 glibc
rpm on ia64, where there really was never going to be any need to restart the
init since it doesn't actually use the 32-bit libraries.  But this would also
come up in any situation where an inittab script caused "telinit u" for any
other reason, such as if firstboot were to do over-the-network rpm updates and
possibly upgrade glibc from inside an init script.

I looked at init and it seems to me that the re-execing code could actually
handle this case fine, but I have only a cursory understanding of init's real
control flow.  It looks to me like it might be sufficient just to add the
WAITING flag to the `flags' table of flags that get pickled into the state
preserved across re-execs.  That is, the re-execing init would just know that it
was in the middle of running the "rc 1" inittab command or whatever it is, and
should wait for it to finish before doing anything else.

Unless we do intend to have glibc upgrades from firstboot in RHEL4 at some
point, then the workaround of avoiding the telinit u is the safe bet.
Noone is in a hurry to perturb init's subtle behaviors.  But for future
versions, it's worth looking into whether my suggestion seems to do the trick.

Comment 5 Bill Nottingham 2005-09-21 20:48:49 UTC
Moving to an enhancement for FC; there's nothing in the current RHEL 4 plans
that will cause this to show up there.

Comment 6 Bill Nottingham 2006-08-09 19:07:14 UTC
Fixed in 2.86-8.

Comment 7 David Lawrence 2007-06-22 02:11:32 UTC
Package name is now sysvinit in Fedora.