From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/20080208 Fedora/188.8.131.52-1.fc8 Firefox/184.108.40.206
Description of problem:
The systems hangs on the message "Unmounting NCP filesystems" when a shutdown or reboot is issued.
This is caused by an NCP mount that was mounted, but not unmounted before the ethernet network-cable of the laptop was disconnected.
Version-Release number of selected component (if applicable):
util-linux-ng-2.13.1-1.fc8 initscripts-8.60-1 kernel-220.127.116.11-2.fc8xen
Steps to Reproduce:
1. Mount an NCP filesystem (automatically using /etc/fstab) or using a normal mount command
2. Disconnect the ethernet cable of the machine
3. Initiate a normal shutdown of the machine (poweroff)
The system hangs on the unmount of the NCP filesystem
A timeout should occur on the NCP filesystem and the shutdown-sequence should continue the normal way.
Contents of /etc/fstab:
NWALR/.EKA.CONSUMENT&BELEIDSINFORMATIE.NCCW.ALMERE.WRG /mnt/nwalr ncp ipserver=nwalr.ict-beheer.local,volume=USR,uid=eka,gid=users,passwdfile=/etc/ncp.passwd,tcp,user,rw,auto 0 0
I see init scripts umounting NCP by
[ -n "$NCPMTAB" ] && action $"Unmounting NCP filesystems: " umount -a -t ncpfs
I think the problem is mismatch between your /etc/fstab where is "ncp" and
/etc/init.d/netfs init scipt where is "ncpfs".
BTW, is it really possible to umount NCP by umount(8), I see there is
/usr/bin/ncpumount too. (I've zero experience with NCP/IPX)
Manual mounts and unmounts of the ncp filesystem do work nicely.
Only the unmount with a disconnected network fails.
I changed the filesystem-type in /etc/fstab from 'ncp' to 'ncpfs'.
I can still mount and unmount the filesystem, but the mentioned problem still
occurs when the network is disconnected before the unmount.
(In reply to comment #2)
> Manual mounts and unmounts of the ncp filesystem do work nicely.
> Only the unmount with a disconnected network fails.
Please, try (with disconnected network):
strace -f -o umount.log umount -v /mountpoint
I'd like to see the log file.
You can also try to use force umount (umount -f).
> I changed the filesystem-type in /etc/fstab from 'ncp' to 'ncpfs'.
> I can still mount and unmount the filesystem, but the mentioned problem still
well, the FS name is important for "umount -a -t ncpfs", because umount(8) is
trying to found relevant mountpoints in /etc/mtab by the FS name.
> occurs when the network is disconnected before the unmount.
It doesn't seem like a umount(8) bug, I guess it's any disadvantage in your
setting or NCP filesystem driver.
I made the requested strace for a normal unmount, a hanging unmount and a
hanging forced unmount. (see attachments)
And (maybe) some extra useful information:
[root@pc02019666 bin]# ll /sbin/mount*
-rwxr-xr-x 1 root root 23672 2007-12-10 17:03 /sbin/mount.cifs
lrwxrwxrwx 1 root root 19 2007-12-20 12:02 /sbin/mount.ncp -> ../usr/bin/ncpmount
lrwxrwxrwx 1 root root 19 2007-12-20 12:02 /sbin/mount.ncpfs ->
-rwsr-xr-x 1 root root 55456 2007-10-18 01:34 /sbin/mount.nfs
lrwxrwxrwx 1 root root 9 2007-12-05 09:19 /sbin/mount.nfs4 -> mount.nfs
[root@pc02019666 bin]# ll /sbin/umount*
-rwxr-xr-x 1 root root 10700 2007-12-10 17:03 /sbin/umount.cifs
-rwxr-xr-x 1 root root 7644 2007-10-12 00:59 /sbin/umount.hal
lrwxrwxrwx 1 root root 9 2007-12-05 09:19 /sbin/umount.nfs -> mount.nfs
lrwxrwxrwx 1 root root 9 2007-12-05 09:19 /sbin/umount.nfs4 -> mount.nfs
[root@pc02019666 bin]# ll /usr/bin/ncp*
-rwsr-xr-x 1 root root 285668 2007-08-23 14:08 /usr/bin/ncplogin
lrwxrwxrwx 1 root root 9 2007-12-20 12:02 /usr/bin/ncplogout -> ncpumount
-rwsr-xr-x 1 root root 281412 2007-08-23 14:08 /usr/bin/ncpmap
-rwxr-xr-x 1 root root 283100 2007-08-23 14:08 /usr/bin/ncpmount
-rwxr-xr-x 1 root root 254236 2007-08-23 14:08 /usr/bin/ncpumount
Created attachment 297766 [details]
Strace output of normal working unmount (with network connected)
Created attachment 297767 [details]
Strace output of hanging unmount (with network disconnected)
Created attachment 297768 [details]
Strace output of hanging unmount (with network disconnected and forced unmount)
It hangs on oldumount() and also in umount() syscalls. Reassigning to kernel.
Do other network filesystems time out after a while, or do they hang too?
(In reply to comment #7)
> Created an attachment (id=297768) 
> Strace output of hanging unmount (with network disconnected and forced unmount)
What is the status of the hanging process (from ps)
I don't have any other network-based mounts, so I can't tell if other network
filesystems hang as well.
And this is the process status of the hanging unmount:
[eka@pc02019666 ~]$ ps aux|grep nwalr
root 8601 0.0 0.0 4316 748 pts/1 S+ 21:04 0:00 umount -f
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.