RPCPROG_MNT: RPC: Timed out / receiving NFS error when trying to
O. Hartmann
since today I get this error when trying to mount a NFS filesystem from
NFS server:
[udp] foo:/home: RPCPROG_MNT: RPC: Timed out
Both boxes, cleint and server, are most recent FreeBSD 8.0-CURRENT/amd64
from today's buildworld/make kernel.
nfsd is up and running and worked that way days before.
I saw commitments of new NFSv4 code, are these causing this issue? Is
8.0 supposed to be offering nfsv4-server capabilities which I need to
switch on anyway?
I also tried mount -t newnfs on that NFS filesystem but without any
success. Is this a fault of mine or are temporarely not-working-condition?
I tried both ZFS and UFS2 NFS exports to get mounted, both are unwilling
to mount with the above showed error.
Regards,
Oliver
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Rick Macklem
On Tue, 2 Jun 2009, O. Hartmann wrote:
> Hello,
> since today I get this error when trying to mount a NFS filesystem from NFS
> server:
>
> [udp] foo:/home: RPCPROG_MNT: RPC: Timed out
>
> Both boxes, cleint and server, are most recent FreeBSD 8.0-CURRENT/amd64 from
> today's buildworld/make kernel.
>
> nfsd is up and running and worked that way days before.
>
> I saw commitments of new NFSv4 code, are these causing this issue? Is 8.0
> supposed to be offering nfsv4-server capabilities which I need to switch on
> anyway?
>
By default, everything should work just like before, using the vanilla NFS
server, etc. The message indicates that mountd wasn't responding. So,
first off, check that it is running.
I did integrate some changes into mountd for the new experimental nfs
subsystem, but those should only be invoked if "-e" was provided on its
command line.
I'll go through the changes I made to mountd.c again, but it has been
working ok for me.
> I also tried mount -t newnfs on that NFS filesystem but without any success.
> Is this a fault of mine or are temporarely not-working-condition?
>
Using "mount -t newnfs" uses the experimental nfs client instead of the
regular one, but they should both work. The problem seems to be an
unresponsive mountd.
Let us know if you find out anything more about it, rick
O. Hartmann
Mounting via '-o nfsv3,tcp' in addition, everthing works all right
again. I do not know why udp is invoked automatically by now.
But for short, we always did NFS mounts over tcp AND udp, so for tcp it
worked again!
Oliver
Rick Macklem
On Tue, 2 Jun 2009, O. Hartmann wrote:
> Hello,
> since today I get this error when trying to mount a NFS filesystem from NFS
> server:
>
> [udp] foo:/home: RPCPROG_MNT: RPC: Timed out
>
> Both boxes, cleint and server, are most recent FreeBSD 8.0-CURRENT/amd64 from
> today's buildworld/make kernel.
>
What's the expression you guys use? "The pointy hat points at me."
It looks like I broke parsing of /etc/exports for the case where there
are continuation lines (I didn't have any of those in my test examples,
but do now;-).
Sorry about that. I'll be looking it over more carefully, but I'll bet
that the following patch fixes the problem (and I'm guessing you do have
contnuation lines in your /etc/exports?).
Please try this patch and see if it helps, rick
--- test patch for mountd.c ---
--- mountd.c.sav 2009-06-02 11:28:19.000000000 -0400
+++ mountd.c 2009-06-02 11:36:53.000000000 -0400
@@ -1191,12 +1191,12 @@
got_nondir = 0;
opt_flags = 0;
ep = (struct exportlist *)NULL;
- dirp = NULL;
/*
* Handle the V4 root dir.
*/
if (*cp == 'V' && *(cp + 1) == '4' && *(cp + 2) == ':') {
+ dirp = NULL;
/*
* V4: just indicates that it is the v4 root point,
* so skip over that and set v4root_phase.
Rick Macklem
On Tue, 2 Jun 2009, O. Hartmann wrote:
>
> Mounting via '-o nfsv3,tcp' in addition, everthing works all right again. I
> do not know why udp is invoked automatically by now.
>
> But for short, we always did NFS mounts over tcp AND udp, so for tcp it
> worked again!
>
Hmm, weird. udp mounts work here for me (except NFSv4, where tcp is
required, but you'd only get that if you had used "-o nfsv4" in your
mount).
I'll take another look at mount_nfs.c too (already caught a problem I
introduced in mountd.c). Maybe I unintentionally changed one of the
defaults. (I think the default is supposed to be nfsv3,tcp but I'll look.)
For udp to work, nfsd must have the "-u" argument. That might be why it
wouldn't work? (Still doesn't explain why the default was udp and not
tcp.)
Anyhow, thanks for doing the testing and I'll email again if I find
that I've screwed up the defaults for mount_nfs too. (Is that a
"big pointy hat"?:-)
Arnar Mar Sig
> On Tue, 2 Jun 2009, O. Hartmann wrote:
>
>>
>> Mounting via '-o nfsv3,tcp' in addition, everthing works all right
>> again. I do not know why udp is invoked automatically by now.
>>
>> But for short, we always did NFS mounts over tcp AND udp, so for
>> tcp it worked again!
>>
> Hmm, weird. udp mounts work here for me (except NFSv4, where tcp is
> required, but you'd only get that if you had used "-o nfsv4" in your
> mount).
>
> I'll take another look at mount_nfs.c too (already caught a problem I
> introduced in mountd.c). Maybe I unintentionally changed one of the
> defaults. (I think the default is supposed to be nfsv3,tcp but I'll
> look.)
>
> For udp to work, nfsd must have the "-u" argument. That might be why
> it
> wouldn't work? (Still doesn't explain why the default was udp and not
> tcp.)
>
> Anyhow, thanks for doing the testing and I'll email again if I find
> that I've screwed up the defaults for mount_nfs too. (Is that a
> "big pointy hat"?:-)
I'm having troubles with nfsroot on avr32 after updating my dev box to
HEAD on May 31.
I can see MNT RPC packet coming from the avr32 board and running
mountd -d shows "mountd: mount successful" when the packet is received
but no answer is transmitted, rpc is sent with udp.
I can mount the same export from my osx workstation when using tcp.
Arnar Mar Sig
Rick Macklem
On Tue, 2 Jun 2009, Arnar Mar Sig wrote:
>
>
> I'm having troubles with nfsroot on avr32 after updating my dev box to HEAD
> on May 31.
>
> I can see MNT RPC packet coming from the avr32 board and running mountd -d
> shows "mountd: mount successful" when the packet is received but no answer is
> transmitted, rpc is sent with udp.
> I can mount the same export from my osx workstation when using tcp.
>
Ok, I've poked at it a little more and the case that seems to be broken
is the "-h nfs-server.cis.uoguelph.ca" option on nfsd. Without "-h" or
with "-h 131.104.49.243" it seems to work. (This affects udp but not tcp.)
I haven't yet figured out why that case is broken, but I'll keep fiddling
with it. (For me the getaddrinfo() fails for this case.)
If you are not using the "-h" option on nfsd and udp isn't working, I
haven't got an explanation, because it seems to work for me?
rick
Robert Watson
On Tue, 2 Jun 2009, Rick Macklem wrote:
>> Mounting via '-o nfsv3,tcp' in addition, everthing works all right again. I
>> do not know why udp is invoked automatically by now.
>>
>> But for short, we always did NFS mounts over tcp AND udp, so for tcp it
>> worked again!
>>
> Hmm, weird. udp mounts work here for me (except NFSv4, where tcp is
> required, but you'd only get that if you had used "-o nfsv4" in your mount).
>
> I'll take another look at mount_nfs.c too (already caught a problem I
> introduced in mountd.c). Maybe I unintentionally changed one of the
> defaults. (I think the default is supposed to be nfsv3,tcp but I'll look.)
I'm running into a similar-sounding but odd problem on a diskless NFS client
test box running 8.0, but talking to a server running 7.0:
cheetah# mount -o rw -u /
[udp] zoo:/zoo/cheetah: RPCPROG_NFS: RPC: Port mapper failure - RPC: Unable to
send
If I do a fresh file system mount it works fine:
cheetah# mount 192.168.5.1:/zoo /zoo
cheetah# mount
192.168.5.1:/zoo/cheetah on / (nfs, read-only)
devfs on /dev (devfs, local)
/dev/md0 on /var (ufs, local)
/dev/md1 on /tmp (ufs, local)
192.168.5.1:/zoo on /zoo (nfs)
This is with an approximately 26 May userspace.
Robert N M Watson
Computer Laboratory
University of Cambridge
Arnar Mar Sig
On Jun 2, 2009, at 9:36 PM, Rick Macklem wrote:
>
>
> On Tue, 2 Jun 2009, Arnar Mar Sig wrote:
>
>>
>>
>> I'm having troubles with nfsroot on avr32 after updating my dev box
>> to HEAD on May 31.
>>
>> I can see MNT RPC packet coming from the avr32 board and running
>> mountd -d shows "mountd: mount successful" when the packet is
>> received but no answer is transmitted, rpc is sent with udp.
>> I can mount the same export from my osx workstation when using tcp.
>>
> Ok, I've poked at it a little more and the case that seems to be
> broken
> is the "-h nfs-server.cis.uoguelph.ca" option on nfsd. Without "-h" or
> with "-h 131.104.49.243" it seems to work. (This affects udp but not
> tcp.)
>
> I haven't yet figured out why that case is broken, but I'll keep
> fiddling
> with it. (For me the getaddrinfo() fails for this case.)
>
> If you are not using the "-h" option on nfsd and udp isn't working, I
> haven't got an explanation, because it seems to work for me?
>
> rick
>
I'm using the default "-u -t -n 4". I rebuilt everything with checkout
from today and tested with osx and linux clients. both show the same
results, viewing traffic with wireshark shows no response packet sent
when using udp.
osx:
dumb:~ antab$ mount_nfs -o udp 192.168.1.254:/home/antab/avr32-root
test/
mount_nfs: bad MNT RPC: RPC: Timed out\n
mount_nfs: bad MNT RPC: RPC: Timed out\n
mount_nfs: can't access /home/antab/avr32-root: Permission denied
dumb:~ antab$ mount_nfs -o tcp 192.168.1.254:/home/antab/avr32-root
test/
dumb:~ antab$ umount test/
Bad MNT RPC: RPC: Timed out
(osx seems to always send the UMNT rpc with udp)
linux:
antab@thordis:~$ sudo mount -t nfs -o udp 192.168.1.254:/home/antab/
avr32-root test/
mount.nfs: mount system call failed
antab@thordis:~$ sudo mount -t nfs -o tcp 192.168.1.254:/home/antab/
avr32-root test/
antab@thordis:~$ umount test/
Arnar Mar Sig
Rick Macklem
On Tue, 2 Jun 2009, Rick Macklem wrote:
>>
>>
>> I'm having troubles with nfsroot on avr32 after updating my dev box to HEAD
>> on May 31.
>>
>> I can see MNT RPC packet coming from the avr32 board and running mountd -d
>> shows "mountd: mount successful" when the packet is received but no answer
>> is transmitted, rpc is sent with udp.
>> I can mount the same export from my osx workstation when using tcp.
>>
> Ok, I've poked at it a little more and the case that seems to be broken
> is the "-h nfs-server.cis.uoguelph.ca" option on nfsd. Without "-h" or
> with "-h 131.104.49.243" it seems to work. (This affects udp but not tcp.)
>
> I haven't yet figured out why that case is broken, but I'll keep fiddling
> with it. (For me the getaddrinfo() fails for this case.)
>
> If you are not using the "-h" option on nfsd and udp isn't working, I
> haven't got an explanation, because it seems to work for me?
>
I typed the above (and the bit about /etc/exports continuation lines)
before I had poked around with it enough. The continuation lines seem
to work and the "-h nfs-server.cis.uoguelph.ca" message logged is just
because I'm using ipv4 only.
I seem to get udp mounts to work fine, but...
I've seen what Robert mentioned. I had just assumed it was some weirdness
in my local lan. I've found that, if you "ping <server>" before doing the
mount, it seems to always work. (I usually see it when mounting a
Solaris10 client to the FreeBSD8 server and it eventually times out and
retries successfully. I normally use tcp mounts, so I didn't "connect"
that with this problem.)
So, maybe it's some network interaction issue and not an obvious goof up
by me w.r.t. changes in the utilities? (The changes I did shouldn't have
had anything to do with the mount protocol code in them.)
rick
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Rick Macklem
On Tue, 2 Jun 2009, Robert Watson wrote:
>
> I'm running into a similar-sounding but odd problem on a diskless NFS client
> test box running 8.0, but talking to a server running 7.0:
>
> cheetah# mount -o rw -u /
> [udp] zoo:/zoo/cheetah: RPCPROG_NFS: RPC: Port mapper failure - RPC: Unable
> to send
>
> If I do a fresh file system mount it works fine:
>
I just saw one almost the same as this. When I did an nfsv3,tcp mount I
got a similar message, but it was for the NFS NULL RPC.
I left it and after a while it retried and succeeded.
I tried rebooting the client and server a couple of times, but wasn't
able to get it to happen again.
So, I wonder if what the others were seeing was something similar? rick
(ps: I'm running a current kernel and nfs related utilities, but really
old Feb. userland for the rest.)
Arnar Mar Sig
>
>
> On Tue, 2 Jun 2009, Robert Watson wrote:
>
>>
>> I'm running into a similar-sounding but odd problem on a diskless
>> NFS client test box running 8.0, but talking to a server running 7.0:
>>
>> cheetah# mount -o rw -u /
>> [udp] zoo:/zoo/cheetah: RPCPROG_NFS: RPC: Port mapper failure -
>> RPC: Unable to send
>>
>> If I do a fresh file system mount it works fine:
>>
> I just saw one almost the same as this. When I did an nfsv3,tcp
> mount I
> got a similar message, but it was for the NFS NULL RPC.
>
> I left it and after a while it retried and succeeded.
>
> I tried rebooting the client and server a couple of times, but wasn't
> able to get it to happen again.
>
> So, I wonder if what the others were seeing was something similar?
> rick
> (ps: I'm running a current kernel and nfs related utilities, but
> really
> old Feb. userland for the rest.)
I'm able to use udp mounts again after reverting to r192672. I also
tried r192927 and it did not work.
I did complete world when updating.
Arnar Mar Sig
Dmitry Marakasov
Just my 2 cents: the same behaviour, and while mount -o tcp succeeds,
umounting behaves strangely: if I umount nfs filesystem, umount
process hangs for some time, then exits with `umount: hive:
RPCMNT_UMOUNT: RPC: Timed out', while the filesystem is actually
umounted immediately after umount is called. This all also breaks
amd severely (however it already haven't been working on current
for a long time for me).
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
amd...@amdmi3.ru ..: jabber: amd...@jabber.ru http://www.amdmi3.ru
Rick Macklem
On Thu, 4 Jun 2009, Dmitry Marakasov wrote:
> * O. Hartmann (ohar...@zedat.fu-berlin.de) wrote:
>
> Just my 2 cents: the same behaviour, and while mount -o tcp succeeds,
> umounting behaves strangely: if I umount nfs filesystem, umount
> process hangs for some time, then exits with `umount: hive:
> RPCMNT_UMOUNT: RPC: Timed out', while the filesystem is actually
> umounted immediately after umount is called. This all also breaks
> amd severely (however it already haven't been working on current
> for a long time for me).
>
That would be consistent with the problem being udp specific. An NFS
server for v2,3 (NFSv4 is a different story) is "stateless" and doesn't
know what mounted on it. All the "umount" does is tell the server's
mountd daemon it has unmounted, so the server's mountd can maintain a
table of mounts that can be queried via "showmount". The -current
umount.c always does this via "udp", so it would fail. The only effect
is that "showmount" might reply bogus info.
It seems that the problem is specific to "udp" and some arches. (I can't
reproduce it on i386 and at least one person sees it on amd64.)
Maybe people who see the problem can post to the -current list, noting
what arch they are using and network config (running virtualized, what
net hardware, multiple net interfaces, etc).
Hopefully there is some commonality among them?
Thanks in advance for any help tracking this down, rick
Martin
schrieb Rick Macklem <rmac...@uoguelph.ca>:
> It seems that the problem is specific to "udp" and some arches. (I
> can't reproduce it on i386 and at least one person sees it on amd64.)
>
> Maybe people who see the problem can post to the -current list, noting
> what arch they are using and network config (running virtualized, what
> net hardware, multiple net interfaces, etc).
>
> Hopefully there is some commonality among them?
>
> Thanks in advance for any help tracking this down, rick
Hi Rick.
I've got also a problem mounting nfs over tcp on my amd64 (kernel of
yesterday).
I tried to find out what is happening and noticed that I don't get a
response back from rpcbind. This is being caused by my unusual
configuration. I've got a public IP and an internal one (2 NICs).
Packets sometimes arrive at one NIC and are being sent back over the
other.
The real problem is that rpcbind throws away the second "-h" parameter
so it does not listen and use the second NIC. I verified it by rpcinfo.
It does not use any ports on my second NIC that I specified in rc.conf.
As a result, I removed all "-h" options, so rpcbind listens on "*.*".
Using this configuration, it works.
Please also be careful with the code. I've seen rpcbind adds 127.0.0.1
automatically. Please make it a warning when someone adds localhost
addresses instead of showing bind errors on the interface address. It's
confusing, because one may think that some other tool blocks the port
or stuff like that. And... yeah... I RTFM. Still, it's confusing when
you forget it.
I hope, I could help you a bit.
Rick Macklem
>
> Hi Rick.
>
> I've got also a problem mounting nfs over tcp on my amd64 (kernel of
> yesterday).
>
Are you using a recently built userland? I ask because there have been
some recent changes to the rpc routines in libc related to routing
replies.
One of them used a uint32_t argument to _setsockopt() until it
was changed to "int" on May 28.
The changes I put in nfsd.c had nothing to do with the "-h" option
or use of rpcbind(), so I don't think my changes would be the culprit.
rick
Martin
schrieb Rick Macklem <rmac...@uoguelph.ca>:
> Are you using a recently built userland? I ask because there have been
> some recent changes to the rpc routines in libc related to routing
> replies.
>
> One of them used a uint32_t argument to _setsockopt() until it
> was changed to "int" on May 28.
>
> The changes I put in nfsd.c had nothing to do with the "-h" option
> or use of rpcbind(), so I don't think my changes would be the culprit.
>
> rick
Hi Rick,
I've rebuilt the userland, of course.
# ls -l /lib/libc.so*
-r--r--r-- 1 root wheel 1234432 Jun 15 01:04 /lib/libc.so.7
# ls -l /boot/kernel/kernel
-r-xr-xr-x 1 root wheel 12010608 Jun 15 01:38 /boot/kernel/kernel
Further info to diagnose the problem:
I've got 3 NICs on 35, 135 and 235 (different subnets).
Netmasks are:
- xx.xx.xx.35/25
- xx.xx.xx.135/26
- xx.xx.xx.235/26
Client is xx.xx.xx.150/26. But you can try it with a single server.
A mount on 127.0.0.1 won't work either.
Here relevant part of rc.conf:
nfs_server_flags="-t -n 4 -h xx.xx.xx.35 -h xx.xx.xx.135"
mountd_flags="-l -r -h xx.xx.xx.35 -h xx.xx.xx.135"
/etc/exports:
/usr/export/src -maproot=root -ro -network xx.xx.xx.128 -mask 255.255.255.192
And here what I changed (rpcbind_flags) and the effects.
Notice, I executed rpcinfo each time before restarting nfsd and mountd.
Maybe I don't understand the rpcinfo output, because it differs from sockstat.
------------------------------
rpcbind_flags="-h xx.xx.xx.35 -h xx.xx.xx.135"
# rpcinfo
program version netid address service owner
100000 4 tcp xx.xx.xx.35.0.111 rpcbind superuser
100000 3 tcp xx.xx.xx.35.0.111 rpcbind superuser
100000 2 tcp xx.xx.xx.35.0.111 rpcbind superuser
100000 4 udp xx.xx.xx.35.0.111 rpcbind superuser
100000 3 udp xx.xx.xx.35.0.111 rpcbind superuser
100000 2 udp xx.xx.xx.35.0.111 rpcbind superuser
100000 4 tcp6 ::1.0.111 rpcbind superuser
100000 3 tcp6 ::1.0.111 rpcbind superuser
100000 4 udp6 ::1.0.111 rpcbind superuser
100000 3 udp6 ::1.0.111 rpcbind superuser
100000 4 local /var/run/rpcbind.sock rpcbind superuser
100000 3 local /var/run/rpcbind.sock rpcbind superuser
100000 2 local /var/run/rpcbind.sock rpcbind superuser
# sockstat | grep rpcbind
root rpcbind 28763 4 udp6 *:* *:*
root rpcbind 28763 5 stream /var/run/rpcbind.sock
root rpcbind 28763 6 udp6 ::1:111 *:*
root rpcbind 28763 7 udp6 *:1008 *:*
root rpcbind 28763 8 tcp6 ::1:111 *:*
root rpcbind 28763 9 udp4 127.0.0.1:111 *:*
root rpcbind 28763 10 udp4 xx.xx.xx.135:111 *:*
root rpcbind 28763 11 udp4 xx.xx.xx.35:111 *:*
root rpcbind 28763 12 udp4 *:842 *:*
root rpcbind 28763 13 tcp4 127.0.0.1:111 *:*
root rpcbind 28763 14 tcp4 xx.xx.xx.135:111 *:*
root rpcbind 28763 15 tcp4 xx.xx.xx.35:111 *:*
client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src
[tcp] xx.xx.xx.35:/usr/export/src: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out
mount_nfs: Cannot immediately mount xx.xx.xx.35:/usr/export/src, backgrounding
--------------------------------------
rpcbind_flags="-h xx.xx.xx.135 -h xx.xx.xx.35"
# rpcinfo
program version netid address service owner
100000 4 tcp xx.xx.xx.135.0.111 rpcbind superuser
100000 3 tcp xx.xx.xx.135.0.111 rpcbind superuser
100000 2 tcp xx.xx.xx.135.0.111 rpcbind superuser
100000 4 udp xx.xx.xx.135.0.111 rpcbind superuser
100000 3 udp xx.xx.xx.135.0.111 rpcbind superuser
100000 2 udp xx.xx.xx.135.0.111 rpcbind superuser
100000 4 tcp6 ::1.0.111 rpcbind superuser
100000 3 tcp6 ::1.0.111 rpcbind superuser
100000 4 udp6 ::1.0.111 rpcbind superuser
100000 3 udp6 ::1.0.111 rpcbind superuser
100000 4 local /var/run/rpcbind.sock rpcbind superuser
100000 3 local /var/run/rpcbind.sock rpcbind superuser
100000 2 local /var/run/rpcbind.sock rpcbind superuser
# sockstat | grep rpcbind
root rpcbind 28591 4 udp6 *:* *:*
root rpcbind 28591 5 stream /var/run/rpcbind.sock
root rpcbind 28591 6 udp6 ::1:111 *:*
root rpcbind 28591 7 udp6 *:825 *:*
root rpcbind 28591 8 tcp6 ::1:111 *:*
root rpcbind 28591 9 udp4 127.0.0.1:111 *:*
root rpcbind 28591 10 udp4 xx.xx.xx.35:111 *:*
root rpcbind 28591 11 udp4 xx.xx.xx.135:111 *:*
root rpcbind 28591 12 udp4 *:1009 *:*
root rpcbind 28591 13 tcp4 127.0.0.1:111 *:*
root rpcbind 28591 14 tcp4 xx.xx.xx.35:111 *:*
root rpcbind 28591 15 tcp4 xx.xx.xx.135:111 *:*
client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src
[tcp] xx.xx.xx.35:/usr/export/src: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out
mount_nfs: Cannot immediately mount xx.xx.xx.35:/usr/export/src, backgrounding
--------------------------------------
rpcbind_flags="-h xx.xx.xx.135 -h xx.xx.xx.35 -h xx.xx.xx.235"
# rpcinfo
program version netid address service owner
100000 4 tcp xx.xx.xx.135.0.111 rpcbind superuser
100000 3 tcp xx.xx.xx.135.0.111 rpcbind superuser
100000 2 tcp xx.xx.xx.135.0.111 rpcbind superuser
100000 4 udp xx.xx.xx.135.0.111 rpcbind superuser
100000 3 udp xx.xx.xx.135.0.111 rpcbind superuser
100000 2 udp xx.xx.xx.135.0.111 rpcbind superuser
100000 4 tcp6 ::1.0.111 rpcbind superuser
100000 3 tcp6 ::1.0.111 rpcbind superuser
100000 4 udp6 ::1.0.111 rpcbind superuser
100000 3 udp6 ::1.0.111 rpcbind superuser
100000 4 local /var/run/rpcbind.sock rpcbind superuser
100000 3 local /var/run/rpcbind.sock rpcbind superuser
100000 2 local /var/run/rpcbind.sock rpcbind superuser
# sockstat |grep rpcbind
root rpcbind 28564 4 udp6 *:* *:*
root rpcbind 28564 5 stream /var/run/rpcbind.sock
root rpcbind 28564 6 udp6 ::1:111 *:*
root rpcbind 28564 7 udp6 *:892 *:*
root rpcbind 28564 8 tcp6 ::1:111 *:*
root rpcbind 28564 9 udp4 127.0.0.1:111 *:*
root rpcbind 28564 10 udp4 xx.xx.xx.235:111 *:*
root rpcbind 28564 11 udp4 xx.xx.xx.35:111 *:*
root rpcbind 28564 12 udp4 xx.xx.xx.135:111 *:*
root rpcbind 28564 13 udp4 *:630 *:*
root rpcbind 28564 14 tcp4 127.0.0.1:111 *:*
root rpcbind 28564 15 tcp4 xx.xx.xx.235:111 *:*
root rpcbind 28564 16 tcp4 xx.xx.xx.35:111 *:*
root rpcbind 28564 17 tcp4 xx.xx.xx.135:111 *:*
client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src
[tcp] xx.xx.xx.35:/usr/export/src: RPCPROG_NFS: RPC: Port mapper failure - RPC: Timed out
mount_nfs: Cannot immediately mount xx.xx.xx.35:/usr/export/src, backgrounding
--------------------------------------
rpcbind_flags=""
# rpcinfo
program version netid address service owner
100000 4 tcp 0.0.0.0.0.111 rpcbind superuser
100000 3 tcp 0.0.0.0.0.111 rpcbind superuser
100000 2 tcp 0.0.0.0.0.111 rpcbind superuser
100000 4 udp 0.0.0.0.0.111 rpcbind superuser
100000 3 udp 0.0.0.0.0.111 rpcbind superuser
100000 2 udp 0.0.0.0.0.111 rpcbind superuser
100000 4 tcp6 ::.0.111 rpcbind superuser
100000 3 tcp6 ::.0.111 rpcbind superuser
100000 4 udp6 ::.0.111 rpcbind superuser
100000 3 udp6 ::.0.111 rpcbind superuser
100000 4 local /var/run/rpcbind.sock rpcbind superuser
100000 3 local /var/run/rpcbind.sock rpcbind superuser
100000 2 local /var/run/rpcbind.sock rpcbind superuser
# sockstat | grep rpcbind
root rpcbind 28735 4 udp6 *:* *:*
root rpcbind 28735 5 stream /var/run/rpcbind.sock
root rpcbind 28735 6 udp6 *:111 *:*
root rpcbind 28735 7 udp6 *:718 *:*
root rpcbind 28735 8 tcp6 *:111 *:*
root rpcbind 28735 9 udp4 *:111 *:*
root rpcbind 28735 10 udp4 *:870 *:*
root rpcbind 28735 11 tcp4 *:111 *:*
client# mount_nfs -o ro,tcp,intr,soft,bg,nfsv3 xx.xx.xx.35:/usr/export/src /usr/src
client# umount /usr/src
umount: xx.xx.xx.35: RPCMNT_UMOUNT: RPC: Timed out
---------------------------------
Hmm... the mount has been successful, but I wonder why umount still gets a time out...
Need more info?
--
Martin
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Martin
schrieb Rick Macklem <rmac...@uoguelph.ca>:
> I suspect it's a recent rpc libc and/or networking change. If you know
> when your configuration last worked (rNNNNNN or date you took the code
> off of head), that might help people figure out what broke it. (nb:
> Note that I said "people" and not me.
Hi Rick,
I'm talking to you, because you seem to try to resolve the problem in
this discussion. Of course I know that you are not responsible for
everything. I never expect anyone to solve my personal problems with
FreeBSD, I just want to at least mention them. I hope, it's still
helpful for developers here.
> I don't know diddly about rpc
> libc or networking stack changes. I just went to:
> http://svn.freebsd.org/viewvc/base/
> and then looked at when stuff had changed.
>
> If you could post to -current again with the last version that worked
> vs doesn't work now, hopefully someone will spot the problem, rick
I've looked up the date that is encoded in my kernel.old build.
FreeBSD 8.0-CURRENT #0: Fri May 15 10:57:37 CEST 2009
I'm sure it worked at this point. Also nfs filesystems that have
been already mounted survived the change, but when I started to
remount them, the problems have begun to appear, so I suppose that nfsd
itself is functioning well, but mountd or rpcbind are somehow affected.
The version I'm using now, that shows the issue, is of Jun 14 19:50
CET.
I usually update shortly before I compile. It could have been one day
earlier that I csup'ed, but I don't think it's more than that.
Fortunatelly there are not many changes in libc/rpc in this
time interval.
Rick Macklem
On Tue, 16 Jun 2009, Martin wrote:
[assorted bits deleted for brevity]
>> If you could post to -current again with the last version that worked
>> vs doesn't work now, hopefully someone will spot the problem, rick
>
> I've looked up the date that is encoded in my kernel.old build.
> FreeBSD 8.0-CURRENT #0: Fri May 15 10:57:37 CEST 2009
>
> I'm sure it worked at this point. Also nfs filesystems that have
> been already mounted survived the change, but when I started to
> remount them, the problems have begun to appear, so I suppose that nfsd
> itself is functioning well, but mountd or rpcbind are somehow affected.
>
Yep, mountd only gets involved at mount time. (It does suggest that the
/etc/exports stuff is ok, since mountd does push that down into the
kernel and it gets used by nfsd.)
> The version I'm using now, that shows the issue, is of Jun 14 19:50
> CET.
>
>
> Fortunatelly there are not many changes in libc/rpc in this
> time interval.
>
One that might be worth trying is a pre-r192913 svc_dg.c. I'll email
you a copy of that, in case you don't have an easy way to get one.
rick
ps: This is related to Martin's problem posted recently, as follows:
------------------------------
--------------------------------------
--------------------------------------
--------------------------------------
rpcbind_flags=""
# rpcinfo
---------------------------------
Zachary Loafman
> One that might be worth trying is a pre-r192913 svc_dg.c. I'll email
> you a copy of that, in case you don't have an easy way to get one.
This was my rev, and may have some subtle issues on 8.0 (it was
originally a 6.x based patch). I've attached a lib/libc/rpc/svc_dg.c
patch from Rachel Hestilow that may fix your issue. Martin, can you test
it in your environment? I'll get it approved / checked in soon.
--
Zach Loafman | Staff Engineer | Isilon Systems
Martin
schrieb Zachary Loafman <z...@FreeBSD.org>:
Hi Zachary,
I doubt anything will change, because your patch only inserted a
comment in svc_dg.c.
I've got this patch already in my svc_dg.c:
- if (laddr->sa_family == AF_INET) {
+ if (laddr->sa_family == AF_INET && lin->s_addr != INADDR_ANY) {
--
Martin