Red Hat Bugzilla – Bug 142960
Unable to umount /var during shutdown process when connected with ssh
Last modified: 2007-11-30 17:07:05 EST
Description of problem:
I know that I am not stuck but as I have never had this kind of
problem with you older version or update of RHEL V3.0 so I permit
myself to conctact you.
Well, it seems that when I am connected with ssh to the server and
I am doing a shutdown via ssh, the system is unable to umount the
device associated to the /var.
This one is trying and trying it several time without success then
few seconds after the system finish to shutdown.
BTW, I can see that on the screen attached localy to the machine
when all messages which appear during the stop process - The [OK]
or [FAILED] messages -
Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux AS release 3 (Taroon Update 3)
FYI : All packages are provided by the Installation CDs
Well, just install a freshly new Red Hat Enterprise Linux AS
release 3 (Taroon Update 3) on a machine. Then be connected with
ssh to the machine from any other station and do a "shutdown -r
now". Have a look on the screen attached to the machine. And you
should see the error messages which appear.
Steps to Reproduce:
1. Install a freshly new Red Hat Enterprise Linux AS release 3
(Taroon Update 3) on a machine
2. Be connected with ssh to the machine from any other station
3. Do a "shutdown -r now"
4. Have a look on the screen attached to the machine
You should see the error messages which appear :
umount /var [FAILED]
Unable to umount the /var
Well, it seems that is purly linked to ssh cause when I do a shutdown
localy I have not this kind of error.
We see this too in RHEL 3, update 3, but only if we run mgetty from
So, if you have inittab entries running mgetty, try commenting them
out, then REBOOT your system so that you get a clean boot without
mgetty, and then try shutting down.
Mgetty appears to wedge some system resource that prevents /var from
being unmounted via umount.
Unfortunately, there appears to be no work-around at this time that
allows one to run mgetty and also to get a clean shutdown. Mgetty
cannot be allowed to run at any time, or else the resource wedging
This resource wedging is invisible to "lsof".
We are also experiencing this issue with RHEL3U3 - a "poweroff"
results in me actually seeing the "Syslog: Power Down" message *in*
SSH, which suggests that SSH may have somehow ignored the SIGKILL.
We've been noticing this for a few months now with some custom scripts
as well, but I had assumed it to be a timing issue - now, I'm leaning
toward the possibility that, for some reason, signals either aren't
reaching thread children, or that applications are otherwise not
receiving/responding to signals sent by init at shutdown.
Also, if the above wasn't clear, I'm suggesting that this problem is
*not* an openssh bug, but a bug in some other component, that you can
see by having ssh (or mgetty) running at the time of shutdown.
I think this is the audit problem that is fixed in U6, BZ #142532. The problem
is due to the audit subsystem holding dentry and vfsmount references which
typically prevent /var from being unmounted during shutdown.
My testing and attempting to reproduce the problems leads me to concur with
PeterM's analysis from Comment #5. Without the changes from that patch, I
can reproduce something like what is described. With those changes, I am
unable to reproduce the problem.
I would feel better if there was a root cause analysis which definitively
indicated that the audit subsystem was the problem, but this seems good
enough. As such, I will close this BZ as a duplicate of 142532. If this
situation can be reproduced even with the changes, then it should be
reopened and I will look at things again.
*** This bug has been marked as a duplicate of 142532 ***
A fix for this problem was committed to the RHEL3 U6 patch pool
on 22-Apr-2005 (in kernel version 2.4.21-32.2.EL).
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 the 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.