Bug 496857 - [RFE] exclude mountpoints from halt initscript
[RFE] exclude mountpoints from halt initscript
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On: 496854
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-21 09:35 EDT by Marc Grimme
Modified: 2014-03-16 23:18 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-14 10:25:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
This patch implements the /etc/xtab approach. (1.64 KB, patch)
2009-04-21 09:36 EDT, Marc Grimme
no flags Details | Diff

  None (edit)
Description Marc Grimme 2009-04-21 09:35:24 EDT
Description of problem:
If there are filesystems mounted that are either dependent on the
rootfilesystem (i.e. bind mounts) or provide chroot environments for userspace
programs the rootfilesystem depends on they should not be umounted during
halt/reboot. One hotspot where this happens is the halt initscript. The halt
initscript just umounts every filesystem other then the rootfilesystem.
But this can lead to huge problems if the rootfilesystem itself is dependent on
other filesystems dependent on this.

Idea:
Like the xrootfs approach this introduces a similar one. The patch attached
will change the halt behavior in so far that not only the rootfilesystem is
not umounted but also all mountpoints listed in /etc/xtab.

Version-Release number of selected component (if applicable):
fedora, rhel5
Description of problem:
If there are filesystems mounted that are either dependent on the
rootfilesystem (i.e. bind mounts) or provide chroot environments for userspace
programs the rootfilesystem depends on they should not be umounted during
halt/reboot. One hotspot where this happens is the netfs initscript. The halt
initscript just umounts every network filesystem other then the rootfilesystem.
But this can lead to huge problems if the rootfilesystem itself is dependent on
other filesystems dependent on this.

Idea:
Like the xrootfs approach this introduces a similar one. The patch attached
will change the halt behavior in so far that not only the rootfilesystem is
not umounted but also all mountpoints listed in /etc/xtab.

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

How reproducible:
always when the rootfilesystem is dependent on other filesystems.

We use it very extensively as we are sharing the rootfs. For this we need a
chroot filesystem holding the userspace programs dependent on the
rootfilesystem that shouldn't be umounted by netfs. We also have a bindmount
where we keep context dependent hostdependent files that should also not being
umounted. For this the /etc/xtab approach would help us very much.

Steps to Reproduce:
1.
2.
3.

Actual results:
All filesystems except the rootfs mounted on / is umounted. But this is not
appropriate as we need more filesystems to survive.

Expected results:
This behavior should be configurable.

Additional info:  
How reproducible:
always when the rootfilesystem is dependent on other filesystems.

We use it very extensively as we are sharing the rootfs. For this we need a
chroot filesystem holding the userspace programs dependent on the
rootfilesystem that shouldn't be umounted by netfs. We also have a bindmount
where we keep context dependent hostdependent files that should also not being
umounted. For this the /etc/xtab approach would help us very much.

Steps to Reproduce:
1.
2.
3.

Actual results:
All filesystems except the rootfs mounted on / is umounted. But this is not
appropriate as we need more filesystems to survive.

Expected results:
This behavior should be configurable.

Additional info:
Comment 1 Marc Grimme 2009-04-21 09:36:20 EDT
Created attachment 340524 [details]
This patch implements the /etc/xtab approach.
Comment 2 Bill Nottingham 2009-07-09 16:26:52 EDT
So, you are mounting network filesystem A, running things from it, and then mounting root filesystem B?

That's... a little pathological.
Comment 3 Marc Grimme 2009-07-10 09:53:26 EDT
I agree, that you won't need this for locally used filesystems that are not dependent on userspace processes.

Nevertheless, there are basically two usecases that require attention during the halt process.

usecase_1: Filesystems that depend on userspace processes. (e.g. NFS4, GFS, GFS2)

usecase_1 requires a chroot environment for the userspace processes that are needed to mount the root filesystem. E.g. GFS needs the cluster stack up and running (aisexec, clvmd, ccsd, ...) 

During the halt process, the chroot environment must not be umounted before the root filesystem. To be able to umount the root filesystem, a pivot_root to the chroot environment has to be done.

proposed halt process (right now implemented in /sbin/halt.local which is implicitly called by /etc/init.d/halt):

1. cd <chroot_environment> 
2. pivot_root . /mnt/oldroot
3. init u (releasing the old root filesystem)
4. umount /mnt/oldroot
5. leave cluster and cleanup
6. reset or halt

if the chroot environment is umounted before the root filesystem, the node either stalls or the cluster needs to initiate an unneeded and time consuming filesystem recovery.

usecase_2: Shared root configuration with hostdependent files.

usecase_2 requires a --bind mount of a hostdependent dependent area in the root filesystem. I.e. we bind mount a special directory residing on the root filesystem to another place (/cluster/cdsl/<nodeid> to /cdsl.local).

e.g. mount --bind /cluster/cdsl/1 /cdsl.local

Then /var which has to be hostdependent points to /cdsl.local/var. 

Right now the halt initscript umounts this --bind mount and therefore the halt cannot proceed. This leads to an unsuccessful umount of the root filesystem causing the cluster to initiate an unneeded and time consuming filesystem recovery.

In my opinion, for the described use cases it is crucial to leave some dependent filesystems mounted before unmounting the root filesystem. 

I hope this makes it clear why it would be good to have this flexibility in the initscripts.
Comment 4 Bill Nottingham 2009-07-10 11:27:41 EDT
(In reply to comment #3)

> usecase_2: Shared root configuration with hostdependent files.
> 
> usecase_2 requires a --bind mount of a hostdependent dependent area in the root
> filesystem. I.e. we bind mount a special directory residing on the root
> filesystem to another place (/cluster/cdsl/<nodeid> to /cdsl.local).
> 
> e.g. mount --bind /cluster/cdsl/1 /cdsl.local
> 
> Then /var which has to be hostdependent points to /cdsl.local/var. 

This case does not seem different to me than network root; in this
case, the filesystem that is bindmounted should be marked in the exact same way a network root filesystem is.
Comment 5 Marc Grimme 2009-07-10 12:50:58 EDT
The _netdev mountoption does not find its way into /proc/mounts and in /etc/init.d/halt it is not checked:

LANG=C __umount_loop '$2 ~ /^\/$|^\/proc|^\/dev/{next}
        $3 == "tmpfs" || $3 == "proc" {print $2 ; next}
        /(loopfs|autofs|nfs|cifs|smbfs|ncpfs|sysfs|^none|^\/dev\/ram|^\/dev\/root$)/ {next}
        {print $2}' /proc/mounts \
        $"Unmounting file systems: " \
        $"Unmounting file systems (retry): " \
        -f

nfs is explicitly excluded but this will only work for nfs not for any other cluster filesystem.

Or did I mix or miss understand something?

Marc.
Comment 6 Lukáš Nykrýn 2013-03-14 10:25:08 EDT
Initscripts no longer handle this -> close.

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