* clients cannot reconnect to mounted nfs shares after server restart [not found] <AANLkTinD01zA=DTXEDG5pXVYcrEGsWOyXcMta0rzvB6n@mail.gmail.com> @ 2011-02-01 3:24 ` camden lindsay 2011-02-01 18:15 ` J. Bruce Fields 0 siblings, 1 reply; 4+ messages in thread From: camden lindsay @ 2011-02-01 3:24 UTC (permalink / raw) To: linux-nfs Having an issue i believe is an NFS bug, but would like someone to verify as well as... point me the correct direction to submit a bug as needed if it indeed is. Situation: NFS server running Client connected with mounted share NFS server is shut down -- (halt or /etc/init.d/nfs stop) NFS server is turned on (booted or /etc/init.d/nfs start) Outcome: NFS client that was connected does not reconnect to that share automatically NFS client that was connected cannot reconnect via umount then mount again No other nfs client can connect to that share, before or after origial NFS clients attempts to connect/reconnect NFS clients CAN connect to a different share. Details/logs: Server shows that client is authenticating: Feb 1 03:01:47 BigBox mountd[6557]: authenticated mount request from 192.168.11.49:674 for /mnt/store/public (/mnt/store/public) Feb 1 03:01:48 BigBox mountd[6557]: authenticated mount request from 192.168.11.49:763 for /mnt/store/public (/mnt/store/public) Feb 1 03:01:50 BigBox mountd[6557]: authenticated mount request from 192.168.11.49:932 for /mnt/store/public (/mnt/store/public) Feb 1 03:01:54 BigBox mountd[6557]: authenticated mount request from 192.168.11.49:942 for /mnt/store/public (/mnt/store/public) Client shows retransmission: dylan@shobuntu:~$ sudo mount -v -t nfs bigbox:/mnt/store/public Public/ mount.nfs: timeout set for Mon Jan 31 19:09:32 2011 mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: text-based options: 'addr=192.168.11.10' Server Version: net-fs/nfs-utils Latest version available: 1.1.4-r1 Latest version installed: 1.1.4-r1 Size of files: 574 kB Homepage: http://linux-nfs.org/ Description: NFS client and server daemons License: GPL-2 (server is on Gentoo, client on Ubuntu) Thanks! Camden ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: clients cannot reconnect to mounted nfs shares after server restart 2011-02-01 3:24 ` clients cannot reconnect to mounted nfs shares after server restart camden lindsay @ 2011-02-01 18:15 ` J. Bruce Fields 2011-02-04 9:31 ` camden lindsay 0 siblings, 1 reply; 4+ messages in thread From: J. Bruce Fields @ 2011-02-01 18:15 UTC (permalink / raw) To: camden lindsay; +Cc: linux-nfs On Mon, Jan 31, 2011 at 07:24:30PM -0800, camden lindsay wrote: > Having an issue i believe is an NFS bug, but would like someone to > verify as well as... point me the correct direction to submit a bug as > needed if it indeed is. > Situation: > NFS server running > Client connected with mounted share > NFS server is shut down -- (halt or /etc/init.d/nfs stop) > NFS server is turned on (booted or /etc/init.d/nfs start) > > Outcome: > NFS client that was connected does not reconnect to that share automatically > NFS client that was connected cannot reconnect via umount then mount again > No other nfs client can connect to that share, before or after origial How long have you waited? > NFS clients attempts to connect/reconnect > NFS clients CAN connect to a different share. > Details/logs: > Server shows that client is authenticating: > Feb 1 03:01:47 BigBox mountd[6557]: authenticated mount request from > 192.168.11.49:674 for /mnt/store/public (/mnt/store/public) > Feb 1 03:01:48 BigBox mountd[6557]: authenticated mount request from > 192.168.11.49:763 for /mnt/store/public (/mnt/store/public) > Feb 1 03:01:50 BigBox mountd[6557]: authenticated mount request from > 192.168.11.49:932 for /mnt/store/public (/mnt/store/public) > Feb 1 03:01:54 BigBox mountd[6557]: authenticated mount request from > 192.168.11.49:942 for /mnt/store/public (/mnt/store/public) A network trace (tcpdump -s0 -wtmp.pcap, then reproduce the problem, then ^C tcpdump, then send us tmp.pcap) might help. > > Client shows retransmission: > dylan@shobuntu:~$ sudo mount -v -t nfs bigbox:/mnt/store/public Public/ > mount.nfs: timeout set for Mon Jan 31 19:09:32 2011 > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: text-based options: 'addr=192.168.11.10' > > Server Version: > net-fs/nfs-utils > Latest version available: 1.1.4-r1 > Latest version installed: 1.1.4-r1 > Size of files: 574 kB > Homepage: http://linux-nfs.org/ > Description: NFS client and server daemons > License: GPL-2 > (server is on Gentoo, client on Ubuntu) Note most of the NFS code is actually in the kernel, so the kernel version(s) involved would be useful too. --b. > Thanks! > Camden > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: clients cannot reconnect to mounted nfs shares after server restart 2011-02-01 18:15 ` J. Bruce Fields @ 2011-02-04 9:31 ` camden lindsay 2011-02-06 20:47 ` J. Bruce Fields 0 siblings, 1 reply; 4+ messages in thread From: camden lindsay @ 2011-02-04 9:31 UTC (permalink / raw) To: J. Bruce Fields; +Cc: linux-nfs Thanks for the response: I have waited quite some time-- many minutes-- and still cannot reconnect. Server --> BigBox dylan # uname -a Linux BigBox 2.6.36-gentoo-r5 #5 SMP Tue Feb 1 06:57:03 PST 2011 x86_64 Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz GenuineIntel GNU/Linux What i have found is that, with a newer client, i get slightly more information at the command line, pointing to stale nfs filehandle: Client1: Linux shobuntu 2.6.24-28-generic #1 SMP Wed Nov 24 09:30:14 UTC 2010 i686 GNU/Linux mount.nfs: timeout set for Fri Feb 4 01:19:37 2011 mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: text-based options: 'addr=192.168.11.10' Client2: Linux core2buntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 UTC 2011 x86_64 GNU/Linux mount.nfs: timeout set for Fri Feb 4 01:18:17 2011 mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: mount(2): Stale NFS file handle mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: mount(2): Stale NFS file handle mount.nfs: text-based options: 'addr=192.168.11.10' mount.nfs: mount(2): Stale NFS file handle Should this automatically converge at some point? If so, how long should i expect for convergence? Thanks! Camden On Tue, Feb 1, 2011 at 10:15 AM, J. Bruce Fields <bfields@fieldses.org> wrote: > > On Mon, Jan 31, 2011 at 07:24:30PM -0800, camden lindsay wrote: > > Having an issue i believe is an NFS bug, but would like someone to > > verify as well as... point me the correct direction to submit a bug as > > needed if it indeed is. > > Situation: > > NFS server running > > Client connected with mounted share > > NFS server is shut down -- (halt or /etc/init.d/nfs stop) > > NFS server is turned on (booted or /etc/init.d/nfs start) > > > > Outcome: > > NFS client that was connected does not reconnect to that share automatically > > NFS client that was connected cannot reconnect via umount then mount again > > No other nfs client can connect to that share, before or after origial > > How long have you waited? > > > NFS clients attempts to connect/reconnect > > NFS clients CAN connect to a different share. > > Details/logs: > > Server shows that client is authenticating: > > Feb 1 03:01:47 BigBox mountd[6557]: authenticated mount request from > > 192.168.11.49:674 for /mnt/store/public (/mnt/store/public) > > Feb 1 03:01:48 BigBox mountd[6557]: authenticated mount request from > > 192.168.11.49:763 for /mnt/store/public (/mnt/store/public) > > Feb 1 03:01:50 BigBox mountd[6557]: authenticated mount request from > > 192.168.11.49:932 for /mnt/store/public (/mnt/store/public) > > Feb 1 03:01:54 BigBox mountd[6557]: authenticated mount request from > > 192.168.11.49:942 for /mnt/store/public (/mnt/store/public) > > A network trace (tcpdump -s0 -wtmp.pcap, then reproduce the problem, > then ^C tcpdump, then send us tmp.pcap) might help. > > > > > Client shows retransmission: > > dylan@shobuntu:~$ sudo mount -v -t nfs bigbox:/mnt/store/public Public/ > > mount.nfs: timeout set for Mon Jan 31 19:09:32 2011 > > mount.nfs: text-based options: 'addr=192.168.11.10' > > mount.nfs: text-based options: 'addr=192.168.11.10' > > mount.nfs: text-based options: 'addr=192.168.11.10' > > mount.nfs: text-based options: 'addr=192.168.11.10' > > mount.nfs: text-based options: 'addr=192.168.11.10' > > > > Server Version: > > net-fs/nfs-utils > > Latest version available: 1.1.4-r1 > > Latest version installed: 1.1.4-r1 > > Size of files: 574 kB > > Homepage: http://linux-nfs.org/ > > Description: NFS client and server daemons > > License: GPL-2 > > (server is on Gentoo, client on Ubuntu) > > Note most of the NFS code is actually in the kernel, so the kernel > version(s) involved would be useful too. > > --b. > > > Thanks! > > Camden > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: clients cannot reconnect to mounted nfs shares after server restart 2011-02-04 9:31 ` camden lindsay @ 2011-02-06 20:47 ` J. Bruce Fields 0 siblings, 0 replies; 4+ messages in thread From: J. Bruce Fields @ 2011-02-06 20:47 UTC (permalink / raw) To: camden lindsay; +Cc: linux-nfs On Fri, Feb 04, 2011 at 01:31:05AM -0800, camden lindsay wrote: > Thanks for the response: > I have waited quite some time-- many minutes-- and still cannot reconnect. The wait shouldn't be more than a minute or two after the nfs server is back up and running. And mount should pretty much never see a stale filehandle error. A network trace showing the stale errors after reboot, together with the output of cat /proc/net/rpc/nfsd.*/content blkid on the server, could be useful. --b. > > Server --> BigBox dylan # uname -a > Linux BigBox 2.6.36-gentoo-r5 #5 SMP Tue Feb 1 06:57:03 PST 2011 > x86_64 Intel(R) Core(TM) i3 CPU 540 @ 3.07GHz GenuineIntel GNU/Linux > > What i have found is that, with a newer client, i get slightly more > information at the command line, pointing to stale nfs filehandle: > Client1: > Linux shobuntu 2.6.24-28-generic #1 SMP Wed Nov 24 09:30:14 UTC 2010 > i686 GNU/Linux > mount.nfs: timeout set for Fri Feb 4 01:19:37 2011 > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: text-based options: 'addr=192.168.11.10' > > Client2: > Linux core2buntu 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 23:42:43 > UTC 2011 x86_64 GNU/Linux > mount.nfs: timeout set for Fri Feb 4 01:18:17 2011 > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: mount(2): Stale NFS file handle > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: mount(2): Stale NFS file handle > mount.nfs: text-based options: 'addr=192.168.11.10' > mount.nfs: mount(2): Stale NFS file handle > > > Should this automatically converge at some point? > If so, how long should i expect for convergence? > > Thanks! > Camden > > On Tue, Feb 1, 2011 at 10:15 AM, J. Bruce Fields <bfields@fieldses.org> wrote: > > > > On Mon, Jan 31, 2011 at 07:24:30PM -0800, camden lindsay wrote: > > > Having an issue i believe is an NFS bug, but would like someone to > > > verify as well as... point me the correct direction to submit a bug as > > > needed if it indeed is. > > > Situation: > > > NFS server running > > > Client connected with mounted share > > > NFS server is shut down -- (halt or /etc/init.d/nfs stop) > > > NFS server is turned on (booted or /etc/init.d/nfs start) > > > > > > Outcome: > > > NFS client that was connected does not reconnect to that share automatically > > > NFS client that was connected cannot reconnect via umount then mount again > > > No other nfs client can connect to that share, before or after origial > > > > How long have you waited? > > > > > NFS clients attempts to connect/reconnect > > > NFS clients CAN connect to a different share. > > > Details/logs: > > > Server shows that client is authenticating: > > > Feb 1 03:01:47 BigBox mountd[6557]: authenticated mount request from > > > 192.168.11.49:674 for /mnt/store/public (/mnt/store/public) > > > Feb 1 03:01:48 BigBox mountd[6557]: authenticated mount request from > > > 192.168.11.49:763 for /mnt/store/public (/mnt/store/public) > > > Feb 1 03:01:50 BigBox mountd[6557]: authenticated mount request from > > > 192.168.11.49:932 for /mnt/store/public (/mnt/store/public) > > > Feb 1 03:01:54 BigBox mountd[6557]: authenticated mount request from > > > 192.168.11.49:942 for /mnt/store/public (/mnt/store/public) > > > > A network trace (tcpdump -s0 -wtmp.pcap, then reproduce the problem, > > then ^C tcpdump, then send us tmp.pcap) might help. > > > > > > > > Client shows retransmission: > > > dylan@shobuntu:~$ sudo mount -v -t nfs bigbox:/mnt/store/public Public/ > > > mount.nfs: timeout set for Mon Jan 31 19:09:32 2011 > > > mount.nfs: text-based options: 'addr=192.168.11.10' > > > mount.nfs: text-based options: 'addr=192.168.11.10' > > > mount.nfs: text-based options: 'addr=192.168.11.10' > > > mount.nfs: text-based options: 'addr=192.168.11.10' > > > mount.nfs: text-based options: 'addr=192.168.11.10' > > > > > > Server Version: > > > net-fs/nfs-utils > > > Latest version available: 1.1.4-r1 > > > Latest version installed: 1.1.4-r1 > > > Size of files: 574 kB > > > Homepage: http://linux-nfs.org/ > > > Description: NFS client and server daemons > > > License: GPL-2 > > > (server is on Gentoo, client on Ubuntu) > > > > Note most of the NFS code is actually in the kernel, so the kernel > > version(s) involved would be useful too. > > > > --b. > > > > > Thanks! > > > Camden > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > > > the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-02-06 20:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <AANLkTinD01zA=DTXEDG5pXVYcrEGsWOyXcMta0rzvB6n@mail.gmail.com>
2011-02-01 3:24 ` clients cannot reconnect to mounted nfs shares after server restart camden lindsay
2011-02-01 18:15 ` J. Bruce Fields
2011-02-04 9:31 ` camden lindsay
2011-02-06 20:47 ` J. Bruce Fields
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).