Bug 348651 - [RFE] add init u support for initlevel 0 and 6
[RFE] add init u support for initlevel 0 and 6
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: SysVinit (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2007-10-23 07:39 EDT by Mark Hlawatschek
Modified: 2014-03-16 23:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 16:23:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark Hlawatschek 2007-10-23 07:39:51 EDT
Description of problem:
init u is ignored for initlevel 0 and 6. Is there a reason for this ? We'd 
need to be able to rexec init in initlevel 0 and 6.

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

How reproducible:

Steps to Reproduce:
1. during a shutdown process try to rexec init 
Actual results:
init u is ignored

Expected results:
init process is restarted.

Additional info:
We need to restart init in a chroot environment (something similar to the 
initrd but for halting) during the reboot/halt operation. This is needed to 
free the root filesystem from all processes and to be able umount it cleanly.
IMHO, the affected part of init.c would just be:
1838         if (strchr("S12345",runlevel) == NULL)
1839                 return;
Comment 1 Bill Nottingham 2007-10-23 13:21:33 EDT
What in init is holding it open that it needs re-execed?
Comment 2 Mark Hlawatschek 2007-10-23 14:09:29 EDT
That's a good question. I think its just because init was started in the 
rootfs. A fuser -mv / shows that init somehow "uses" the rootfs:
# fuser -mv / 2>&1 | grep " init"
/:                   root          1 .rce. init

Comment 3 Bill Nottingham 2007-10-23 14:47:48 EDT
Right, but we get that for normal setups as well and we don't need to re-exec it.
Comment 4 Mark Hlawatschek 2007-10-23 17:23:34 EDT
Yes, I think your right for "normal" setups. There, the /etc/init.d/halt  
script is is remounting the rootfs ro before the real reboot or halt command 
is executed and therefore everything is clean. 
I'm sorry, I should have given you some more background information about what 
we are doing. We are using GFS to build up a diskless sharedroot cluster with 
RHEL. Have a look at http://www.open-sharedroot.org for more information. 
In this kind of setup, we'd like to pivot_root to an initrd like chroot 
environment during reboot/halt and umount the GFS rootfs there before 
executing the real reboot or halt command. To be able to do this, no process 
is allowed to run on the rootfs at this time. The idea is to re-exec init into 
the chroot environment during a halt or reboot operation and then umount the 
rootfs there.
Comment 5 Bill Nottingham 2008-01-12 11:05:46 EST
Does the obvious patch for that line work for you?
Comment 6 Mark Hlawatschek 2008-01-14 03:53:20 EST
yes, I tested it by commenting out both lines. Adding a 6 and 0 would also be 
Comment 7 RHEL Product and Program Management 2008-06-02 16:30:09 EDT
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
Comment 9 Bill Nottingham 2008-09-17 16:51:39 EDT
Building as 2.86-15.el5.
Comment 13 errata-xmlrpc 2009-01-20 16:23:40 EST
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 therefore 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.


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