Bug 143289 - init should protect against calls to reexec from within init scripts
init should protect against calls to reexec from within init scripts
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: sysvinit (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
David Lawrence
: FutureFeature
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2004-12-17 21:22 EST by Geoff Gustafson
Modified: 2014-03-16 22:51 EDT (History)
5 users (show)

See Also:
Fixed In Version: 2.86-8
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-09 15:07:14 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Geoff Gustafson 2004-12-17 21:22:17 EST
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 05:46:35 EST
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 16:48:49 EDT
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 15:07:14 EDT
Fixed in 2.86-8.
Comment 7 David Lawrence 2007-06-21 22:11:32 EDT
Package name is now sysvinit in Fedora.

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