Bug 468458 - System hangs on shutdown trying to umount busy nfs filesystems
System hangs on shutdown trying to umount busy nfs filesystems
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-24 15:56 EDT by Orion Poplawski
Modified: 2014-03-16 23:16 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-30 11:24:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2008-10-24 15:56:38 EDT
Description of problem:

Using autofs mounted home directories.  I often see on shutdown it hang here:

Unmounting file systems:                        [ OK ]
umount.nfs: DNS resolution failed for 192.168.0.8: Name or service not know
umount.nfs: DNS resolution of '192.168.0.8' failed
umount2: Device or resource busy
umount.nfs: /home/orion: device is busy
umount.nfs: DNS resolution failed for 192.168.0.8: Name or service not know
umount.nfs: DNS resolution of '192.168.0.8' failed
umount2: Device or resource busy
umount.nfs: /home/orion: device is busy
umount2: Device or resource busy
umount: /home:/device is busy
    (In some cases useful info about processes that use
     the device is found by losf(8) or fuser(1))


Version-Release number of selected component (if applicable):
initscripts-8.84-1.i386
Comment 1 Bill Nottingham 2008-10-24 16:14:57 EDT
Are you using NetworkManager?
Comment 2 Orion Poplawski 2008-10-24 16:32:08 EDT
(In reply to comment #1)
> Are you using NetworkManager?

yes.
Comment 3 Orion Poplawski 2008-10-24 16:39:29 EDT
Hmm, trouble might be that I've disabled the autofs script and am starting/stopiing it with a NM dispatcher script.  May be important that autofs stops before NM.  I re-enabled autofs and I still got some "DNS resolution" failed messages, but it eventually succeeded.
Comment 4 Bill Nottingham 2008-10-24 16:48:14 EDT
Does 'chckonfig NetworkManager resetpriorities' fix it?
Comment 5 Bill Nottingham 2008-10-24 16:48:30 EDT
Whoops, crossed streams.
Comment 6 Orion Poplawski 2008-10-27 18:15:25 EDT
(In reply to comment #4)
> Does 'chckonfig NetworkManager resetpriorities' fix it?

Doesn't change anything, stop order is the same.

I'm also still seeing the hang with autofs being stopped before NM.
Comment 7 Bill Nottingham 2008-10-28 11:59:27 EDT
Just to make sure - do you have NFS filesystems outside of autofs?
Comment 8 Orion Poplawski 2008-10-28 13:27:09 EDT
No.  I suppose it could be argued the autofs should be taking care of this and this is an autofs bug.
Comment 9 Bill Nottingham 2008-10-28 13:45:39 EDT
What's the current stop priorities you have for NetworkManager, autofs, and netfs?
Comment 10 Orion Poplawski 2008-10-28 13:53:53 EDT
K72autofs
K75netfs
K84NetworkManager
K86nfslock
K90network
Comment 11 Bill Nottingham 2008-10-28 14:28:00 EDT
Dan - does NM yank the interface before it itself shuts down if HAL goes away?
Comment 12 Orion Poplawski 2008-10-28 14:51:20 EDT
One thing that may have changed is that autofs will leave mounts up on autofs shutdown.  Ian?

Perhaps KDE needs to be better about killing user processes as well.

But it seems somebody ultimately needs to be responsible for unmounting without hanging even if it means resorting to -l lazy.
Comment 13 Ian Kent 2008-10-28 21:42:55 EDT
(In reply to comment #12)
> One thing that may have changed is that autofs will leave mounts up on autofs
> shutdown.  Ian?

Version 5 will leave "in use" mounts mounted at exit.

> 
> Perhaps KDE needs to be better about killing user processes as well.
> 
> But it seems somebody ultimately needs to be responsible for unmounting without
> hanging even if it means resorting to -l lazy.

But there have been NFS changes. The options are now passed to
the kernel as text and meaning that more is done in kernel. Even
on F-9 I'm seeing much longer delays when things like
"port=<invalid port>" are used at mount.
Comment 14 Dan Williams 2008-10-30 02:01:41 EDT
(In reply to comment #11)
> Dan - does NM yank the interface before it itself shuts down if HAL goes away?

No, NM will survive HAL hiccups, and when HAL comes back it'll compare it's device list with HALs, deactivate and drop devices HAL no longer knows about and add new devices.  Device UDIs that persist across HAL crash/restart are not touched.

NM will only bring down interfaces for 3 reasons:

1) something told it to over D-Bus
2) The connection is no longer valid (no carrier, lost association to AP, supplicant crashed)
3) When it quits or is told to quit
Comment 15 Bill Nottingham 2008-10-30 10:06:05 EDT
Orion - is the netfs stop actually running on your system? Are the NFS filesystems ending up in mtab when autofs mounts them?

From re-reading, the errors you're getting are from init.d/halt - at that point, the networking is down no matter which system you use, and filesystems should have already been unmounted by netfs.bbb
Comment 16 Orion Poplawski 2008-10-30 11:24:43 EDT
I'm so sorry, this is all my fault.  I disabled the netfs script thinking I didn't need it, and because of this:

Oct 30 09:18:52 cynosure nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/05-netfs' exited with error status 1.

which occurs if netfs is enabled and NM brings up a second interface.

05-netfs does:

if [ "$2" = "up" ]; then
        /sbin/ip -o route show dev "$1" | grep -q '^default' && {
                /sbin/chkconfig netfs && /etc/rc.d/init.d/netfs start
        }
fi

which will return 1 if NM brings up a new interface that is not the default route.

I filed bug 469197 for the NM script return code issue(s).  I'll close this.

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