Red Hat Bugzilla – Bug 143289
init should protect against calls to reexec from within init scripts
Last modified: 2014-03-16 22:51:18 EDT
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.
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.
Moving to an enhancement for FC; there's nothing in the current RHEL 4 plans
that will cause this to show up there.
Fixed in 2.86-8.
Package name is now sysvinit in Fedora.