[arch-dev-public] netfs daemon script failing on shutdown
I've noticed lately that netfs always fails to shut down correctly, and I was wondering if this is just my system or if others are also noticing this. An easy way to check: sudo /etc/rc.d/netfs restart If you see a [FAIL], you're in the same boat as me. Let me know and I'll file a bug report if more people have the same issue. -Dan
With no network filesystems mounted, it succeeds. I'm at home, so none of my nfs mounts are usable. // jeff -- .: [ + carpe diem totus tuus + ] :.
On Jan 2, 2008 2:49 PM, Dan McGee <dpmcgee@gmail.com> wrote:
I've noticed lately that netfs always fails to shut down correctly, and I was wondering if this is just my system or if others are also noticing this. An easy way to check: sudo /etc/rc.d/netfs restart
If you see a [FAIL], you're in the same boat as me. Let me know and I'll file a bug report if more people have the same issue.
What netfs filesystems do you have mounted? samba? nfs?
On Jan 3, 2008 9:54 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Jan 2, 2008 2:49 PM, Dan McGee <dpmcgee@gmail.com> wrote:
I've noticed lately that netfs always fails to shut down correctly, and I was wondering if this is just my system or if others are also noticing this. An easy way to check: sudo /etc/rc.d/netfs restart
If you see a [FAIL], you're in the same boat as me. Let me know and I'll file a bug report if more people have the same issue.
What netfs filesystems do you have mounted? samba? nfs?
$ mount ... nfsd on /proc/fs/nfsd type nfsd (rw,noexec,nosuid,nodev) cork:/home/dmcgee on /home/dmcgee/cork type nfs (rw,addr=192.168.1.101) That is it. cork is always up when I'm trying to shutdown, so that isn't the problem. An "lsof | grep cork" right before I run "/etc/rc.d/netfs restart" yields no results, and yet the shutdown still fails (but the startup is a success). Running the umount command manually from the daemon script, as root, yields a return value of 1 (although the NFS mount is unmounted according to mount output). Running mount returns 0 (and the NFS share is remounted). Vaguely related, but it is also odd that mount has its path fully spelled out (/bin/mount) while umount does not. That doesn't make a difference though. -Dan
On Wed, Jan 02, 2008 at 02:49:05PM -0600, Dan McGee wrote:
I've noticed lately that netfs always fails to shut down correctly, and I was wondering if this is just my system or if others are also noticing this. An easy way to check: sudo /etc/rc.d/netfs restart
If you see a [FAIL], you're in the same boat as me. Let me know and I'll file a bug report if more people have the same issue.
-Dan
It works for me (/etc/rc.d/netfs stop mind you) but I have a couple things different from most people probably: I use cifs and I don't mount the filesystem with the "defaults" option (ie. noauto). Jason
On Jan 3, 2008 10:51 AM, Jason Chu <jason@archlinux.org> wrote:
On Wed, Jan 02, 2008 at 02:49:05PM -0600, Dan McGee wrote:
I've noticed lately that netfs always fails to shut down correctly, and I was wondering if this is just my system or if others are also noticing this. An easy way to check: sudo /etc/rc.d/netfs restart
If you see a [FAIL], you're in the same boat as me. Let me know and I'll file a bug report if more people have the same issue.
-Dan
It works for me (/etc/rc.d/netfs stop mind you) but I have a couple things different from most people probably: I use cifs and I don't mount the filesystem with the "defaults" option (ie. noauto).
Ah, does netfs only handle the 'auto' ones? Probably why I didn't notice this. I mount my nfs when I need it...
On Jan 3, 2008 11:31 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Jan 3, 2008 10:51 AM, Jason Chu <jason@archlinux.org> wrote:
On Wed, Jan 02, 2008 at 02:49:05PM -0600, Dan McGee wrote:
I've noticed lately that netfs always fails to shut down correctly, and I was wondering if this is just my system or if others are also noticing this. An easy way to check: sudo /etc/rc.d/netfs restart
If you see a [FAIL], you're in the same boat as me. Let me know and I'll file a bug report if more people have the same issue.
-Dan
It works for me (/etc/rc.d/netfs stop mind you) but I have a couple things different from most people probably: I use cifs and I don't mount the filesystem with the "defaults" option (ie. noauto).
Ah, does netfs only handle the 'auto' ones? Probably why I didn't notice this. I mount my nfs when I need it...
So the first command below returns 1, even though it appears it was successful. The second command returns 0, and it was also successful (the "nothing was mounted" line is a lie, as far as I can tell). I do see some weird port stuff there. I also can't find any documentation anywhere on umount return codes. [root@dublin ~]# /bin/umount -v -a -t nfs,smbfs,codafs,ncpfs,cifs,shfs,fuse,fuseblk mount: trying 192.168.1.101 prog 100005 vers 3 prot tcp port 48308 cork:/home/dmcgee umounted [root@dublin ~]# /bin/mount -v -a -t nfs,smbfs,codafs,ncpfs,cifs,shfs,fuse,fuseblk mount: trying 192.168.1.101 prog 100003 vers 3 prot tcp port 2049 mount: trying 192.168.1.101 prog 100005 vers 3 prot udp port 32775 nothing was mounted Both commands below return 0, which is interesting. Umount bug, perhaps? [root@dublin ~]# umount -v /home/dmcgee/cork mount: trying 192.168.1.101 prog 100005 vers 3 prot tcp port 48308 cork:/home/dmcgee umounted Could not find /home/dmcgee/cork in mtab [root@dublin ~]# mount -v /home/dmcgee/cork mount: trying 192.168.1.101 prog 100003 vers 3 prot tcp port 2049 mount: trying 192.168.1.101 prog 100005 vers 3 prot udp port 32775 -Dan
On Thu, 2008-01-03 at 11:43 -0600, Dan McGee wrote:
On Jan 3, 2008 11:31 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Jan 3, 2008 10:51 AM, Jason Chu <jason@archlinux.org> wrote:
On Wed, Jan 02, 2008 at 02:49:05PM -0600, Dan McGee wrote:
I've noticed lately that netfs always fails to shut down correctly, and I was wondering if this is just my system or if others are also noticing this. An easy way to check: sudo /etc/rc.d/netfs restart
If you see a [FAIL], you're in the same boat as me. Let me know and I'll file a bug report if more people have the same issue.
-Dan
It works for me (/etc/rc.d/netfs stop mind you) but I have a couple things different from most people probably: I use cifs and I don't mount the filesystem with the "defaults" option (ie. noauto).
Ah, does netfs only handle the 'auto' ones? Probably why I didn't notice this. I mount my nfs when I need it...
So the first command below returns 1, even though it appears it was successful. The second command returns 0, and it was also successful (the "nothing was mounted" line is a lie, as far as I can tell).
I do see some weird port stuff there. I also can't find any documentation anywhere on umount return codes.
[root@dublin ~]# /bin/umount -v -a -t nfs,smbfs,codafs,ncpfs,cifs,shfs,fuse,fuseblk mount: trying 192.168.1.101 prog 100005 vers 3 prot tcp port 48308 cork:/home/dmcgee umounted
[root@dublin ~]# /bin/mount -v -a -t nfs,smbfs,codafs,ncpfs,cifs,shfs,fuse,fuseblk mount: trying 192.168.1.101 prog 100003 vers 3 prot tcp port 2049 mount: trying 192.168.1.101 prog 100005 vers 3 prot udp port 32775 nothing was mounted
Both commands below return 0, which is interesting. Umount bug, perhaps?
[root@dublin ~]# umount -v /home/dmcgee/cork mount: trying 192.168.1.101 prog 100005 vers 3 prot tcp port 48308 cork:/home/dmcgee umounted Could not find /home/dmcgee/cork in mtab
[root@dublin ~]# mount -v /home/dmcgee/cork mount: trying 192.168.1.101 prog 100003 vers 3 prot tcp port 2049 mount: trying 192.168.1.101 prog 100005 vers 3 prot udp port 32775
The wierd port stuff is set up by portmapper. An rpcinfo on your client and server will should show these ports. Also nmap data files list: [22:42 kpiche@puffin lust_for_blood]$ grep 32775 /usr/share/nmap/nmap-services sometimes-rpc13 32775/tcp # Sometimes an RPC port on my Solaris box (status) sometimes-rpc14 32775/udp # Sometimes an RPC port on my Solaris box (status) [22:42 kpiche@puffin lust_for_blood]$ grep 2049 /usr/share/nmap/nmap-services nfs 2049/tcp # networked file system nfs 2049/udp # networked file system Nmap's services file is very detailed.
-Dan
-- K. Piche <kpiche@rogers.com>
participants (5)
-
Aaron Griffin
-
Dan McGee
-
Jason Chu
-
Jeff 'codemac' Mickey
-
K. Piche