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 How reproducible: 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 Actual results: You should see the error messages which appear : umount /var [FAILED] Unable to umount the /var Expected results: Additional info: 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 inittab. 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 occurs. 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. http://rhn.redhat.com/errata/RHSA-2005-663.html