[chip@debian.org: Debian Bug#203918 - statd request on eth interface, not localhost?]

[chip@debian.org: Debian Bug#203918 - statd request on eth interface, not localhost?]

[Chip Salzenberg]

HEY NEIL.  HEY EVERYBODY ELSE TOO.

Could you please give me some reply to this issue?  The beginning of
the bug report looks boring but it's actually weird.  To me anyway.  :-/


----- Forwarded message from Chip Salzenberg <chip@debian.org> -----

Subject: [NFS] Debian Bug#203918 - statd request on eth interface, not localhost?
From: Chip Salzenberg <chip@debian.org>
To: nfs@lists.sourceforge.net
Cc: 
Date: Mon, 4 Aug 2003 20:48:53 -0400

OK, guys, I've got an interesting bug here.  The server kernel is
2.4.20, the client is 2.6.0 (I think test2).  The first mount attempt
succeeds, and things seem to work.  But unmount requests fail.  And
there's a statd anomaly along the way.

The server is "natura" (213.96.69.115) and the client is "nubol" (IP
unknown).

Here's the /etc/exports:
> /var/cache/apt/archives *.int.oskuro.net(rw,async,no_root_squash)
> /home *.int.oskuro.net(rw,async,no_root_squash)

And here's the intriguing server log message:

> Aug  3 18:22:42 natura rpc.statd[467]: Call to statd from non-local host 213.96.69.115
> Aug  3 18:22:42 natura rpc.statd[467]: STAT_FAIL to natura for SM_MON of 192.168.1.3
> 
> This is the first mount. If you remember, it worked ok the first time I
> apt-get'ed. 213.96.69.115 is the public ip of the nfs server.

So let's get this straight.  The server's kernel is apparently sending
an SM_MON request to its own statd, but not using the loopback address,
but rather the public ethernet address.

Can I get a "Huh?!" from the congregation?  How does that even happen?

Subsequent trouble is perhaps a result of the first problem, somehow?

> Bah, now it won't umount.
> Aug  3 18:29:58 nubol automount[457]: shutdown failed: filesystem still busy
> 
> But nothing is using it.
> 65567:jordi@nubol:~$ sudo lsof |grep autofs
> zsh: done       sudo lsof | 
> zsh: exit 1     grep autofs
> 65568:jordi@nubol:~$ sudo umount  /var/autofs/natura/archives
> umount: /var/autofs/natura/archives: device is busy
> 
> So I can't umount right now. Now, it stays mounted, and it works, but
> it'd be nice if I could get rid of it too :)
> 
> The other day, it would umount and I got the connection refused error.

adTHANKSvance for debugging info.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs



----- End forwarded message -----

-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [chip@debian.org: Debian Bug#203918 - statd request on eth interface, not localhost?]

[Neil Brown]

On Tuesday August 12, chip@pobox.com wrote:
> HEY NEIL.  HEY EVERYBODY ELSE TOO.
> 
> Could you please give me some reply to this issue?  The beginning of
> the bug report looks boring but it's actually weird.  To me anyway.  :-/
> 

There are two issues here which are possibly quite separate.

The first is the "Call to statd from non-local host".
Given that the in-kernel lockd *always* uses 127.0.0.1 to talk to
statd, this request cannot have come from there.  
So it must have come from elsewhere.
Finding out where would not be easy.
You would want to modify statd so that it reports the source port
number as well as ip address, and then doesn't send a reply (so the
source will keep waiting).
Then cause the problem to re-appear and use lsof to hunt around and
find who has the offending port open.

I don't suppose there is any chance that a user-space nfsd is running
as well as the kernel one?

The second problem relates to the filesystem not being unmountable.
This could be the bug that Mark Hemmet recently reported.  Look for
the subject:
   "lockd fails to purge blocked NLM_LOCKs"

in the archives of this list.  Or it could be some simlar bug that
hasn't yet been found.
Without a "how-to-reproduce" it is hard to know.

NeilBrown


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [chip@debian.org: Debian Bug#203918 - statd request on eth interface, not localhost?]

[Jordi Mallach]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]

On Wed, Aug 13, 2003 at 02:06:43PM +1000, Neil Brown wrote:
> I don't suppose there is any chance that a user-space nfsd is running
> as well as the kernel one?

I am 100% sure that I only have ther kernel daemon installed.

I told Chip I'd try to upgrade to the latest 2.6.0 kernel soon. If this
makes it improve, I'll tell you.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [chip@debian.org: Debian Bug#203918 - statd request on eth interface, not localhost?]

[Chip Salzenberg]

According to Jordi Mallach:
> I told Chip I'd try to upgrade to the latest 2.6.0 kernel soon. If this
> makes it improve, I'll tell you.

So, what news?

If you're still getting invalid statd requests from an IP other than
127.0.0.1, they're not from the kernel.  Can you use tcpdump to find
out where the statd requests are coming from?
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [chip@debian.org: Debian Bug#203918 - statd request on eth interface, not localhost?]

[Jordi Mallach]

[-- Attachment #1: Type: text/plain, Size: 989 bytes --]

On Wed, Aug 20, 2003 at 01:59:51PM -0400, Chip Salzenberg wrote:
> So, what news?

News are that I can't compile 2.6.0-test3, so I have no more info :(

> If you're still getting invalid statd requests from an IP other than
> 127.0.0.1, they're not from the kernel.  Can you use tcpdump to find
> out where the statd requests are coming from?

From the server's log:

Aug 20 02:02:24 natura rpc.statd[467]: Call to statd from non-local host 213.96.69.115
Aug 20 02:02:24 natura rpc.statd[467]: STAT_FAIL to natura for SM_MON of 192.168.1.3

So, yes.. I'm still getting those 2.5 minutes after the apt-get cronjob
starts.

I have never used tcpdump more than to play a little, so I could use
some pointers about what I should look at.

Thanks,
Jordi
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [chip@debian.org: Debian Bug#203918 - statd request on eth interface, not localhost?]

[Chip Salzenberg]

According to Jordi Mallach:
> I have never used tcpdump more than to play a little, so I could use
> some pointers about what I should look at.

First you use 'rpcinfo -p' to see which ports statd is listening to
on the machine where statd is complaining:

   $ rpcinfo -p | grep status
       100024    1   udp    936  status
       100024    1   tcp    939  status

That's udp port 936 and tcp port 939.  Then you want to watch all
traffic to/from those ports:

   # tcpdump udp port 936 or tcp port 939

You may also need to specify "-i eth1" or whatever if the IP address
you're seeing isn't on your eth0.

Then you sit and watch.  A combination of "screen" and "script" may
also be helpful.  The man page for tcpdump, section "OUTPUT FORMAT",
explains how to interpret the output.

The key thing is the source IP and port of whoever's talking to statd.
Then you go to the source machine and use 'lsof' to see what program
has bound to that port.  If the program is gone by the time you get
there, you'll need to prevent statd from answering the request, which
will entail compiling a custom statd or perhaps using iptables to kill
any outgoing answer packets.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: [chip@debian.org: Debian Bug#203918 - statd request on eth interface, not localhost?]

[Jordi Mallach]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

On Thu, Aug 21, 2003 at 09:58:26AM +0200, Jordi Mallach wrote:
> News are that I can't compile 2.6.0-test3, so I have no more info :(

I finally got test3 under control, rebooted into it and...

Aug 22 19:29:31 nubol automount[3476]: running expiration on path /var/autofs/natura/archives
Aug 22 19:29:31 nubol rpc.statd[1909]: Received erroneous SM_UNMON request from nubol for 192.168.1.1
Aug 22 19:29:31 nubol automount[3476]: expired /var/autofs/natura/archives

I still get the weird messages at the server though:

Aug 22 19:22:43 natura ippl: sunrpc connection attempt from 192.168.1.3
Aug 22 19:22:43 natura rpc.statd[1982]: Call to statd from non-local host 213.96.69.115
Aug 22 19:22:43 natura rpc.statd[1982]: STAT_FAIL to natura for SM_MON of 192.168.1.3

So, the original problem of "busy mounts" has gone, apparently it was a
bug in -test2 fixed in -test3. I still get these logs that seem to make
you wonder a bit ;) but in general, my setup works ok again.

Jordi
-- 
Jordi Mallach Pérez  --  Debian developer     http://www.debian.org/
jordi@sindominio.net     jordi@debian.org     http://www.sindominio.net/
GnuPG public key information available at http://oskuro.net/~jordi/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Debian bug #165744 - 'Received erroneous SM_UNMON request'

[Chip Salzenberg]

According to Neil Brown:
> The first is the "Call to statd from non-local host".  Given that
> the in-kernel lockd *always* uses 127.0.0.1 to talk to statd, this
> request cannot have come from there.

Neil, would you be so kind as to examine this old (nearly a year now),
but still open, Debian bug report?

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=165744

This complaint *is* very rare, but it seems not to be specific to the
use of 2.6.  Or do you think you know what's up with this old report?
Please advise.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: Debian bug #165744 - 'Received erroneous SM_UNMON request'

[Neil Brown]

On Wednesday August 20, chip@debian.org wrote:
> According to Neil Brown:
> > The first is the "Call to statd from non-local host".  Given that
> > the in-kernel lockd *always* uses 127.0.0.1 to talk to statd, this
> > request cannot have come from there.
> 
> Neil, would you be so kind as to examine this old (nearly a year now),
> but still open, Debian bug report?
> 
>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=165744
> 
> This complaint *is* very rare, but it seems not to be specific to the
> use of 2.6.  Or do you think you know what's up with this old report?
> Please advise.

Sorry, but I'm at a bit of a loss.

It seems that 
   lockd asked statd to monitor some host.
   statd gets information that the host has restarted.
   statd tries to notify lockd about the restart
   statd fails to even send a message, and so forgets about that host
   lockd asked statd to unmonitor the host, and statd doesn't know
       what it is talking about

If you (or someone) could play around and find a sequence of events
that would reproduce the problem it would, of course, help a lot.

NeilBrown


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Debian bug #165744 - 'Received erroneous SM_UNMON request'

[Chip Salzenberg]

Thanks for the analysis, Neil.  I followed it up until this point:

>    statd tries to notify lockd about the restart
>    statd fails to even send a message, and so forgets about that host

Do you know that?  It seems all we can know for sure about this part
of the history is that the message wasn't received, but for all we
know it may have been sent.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: Debian bug #165744 - 'Received erroneous SM_UNMON request'

[Neil Brown]

On Friday August 22, chip@debian.org wrote:
> Thanks for the analysis, Neil.  I followed it up until this point:
> 
> >    statd tries to notify lockd about the restart
> >    statd fails to even send a message, and so forgets about that host
> 
> Do you know that?  It seems all we can know for sure about this part
> of the history is that the message wasn't received, but for all we
> know it may have been sent.

The 

  elrond rpc.statd[179]: notify_host: failed to notify 127.0.0.1

messages indicate that the "sendto" in utils/statd/rmtcall.c(xmit_call)
failed, which suggests that the message wasn't sent.
It might actually be sending a port-lookup call to portmap at this
point.  It is certainly odd that that fails....

NeilBrown


-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Debian bug #165744 - 'Received erroneous SM_UNMON request'

[Frans Pop]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Chip, Neil,

I think I may have found the source of this bug.
In Debian, rpc.statd is compiled with --enable-secure-statd; when I recompi=
le=20
with this option diabled, the error messages disapear!

I tried this after I took a look at the source for rpc.statd. I noticed tha=
t=20
in monitor.c there is the statement
   my_name =3D "127.0.0.1"
when servicing SM_MON requests with secure-statd enabled.
I think in my setup this causes the lookups in the run-time list (which use=
=20
my_name) to fail when servicing SM_UNMON requests if in my situation my_nam=
e=20
is equal to the real adresses of my boxes, causing the 'Received erroneous=
=20
SM_UNMON request' errors.

I think this would also explain the 'notify_host: failed to notify 127.0.0.=
1'=20
errors. This second error occurs when I reboot the server while a=20
NFS-connection was up: after restarting the server tries to notify the clie=
nt=20
it is back up, but can't because the client is not at localhost but at=20
10.19.66.21 and there is no NFS-client running on the server itself.

I think the reason the error appears in my setup could be because I have NF=
S=20
kernel-support compiled in both server and clients. In Debian, this means=20
rpc.lockd is not run from the init scripts. (In /etc/init.d/nfs-common 'gre=
p=20
=2D -q lockdctl /proc/ksyms' returns 1, so NEED_LOCKD is set to 'no'.)

I have (from ps alx):
  F   UID   PID  ... WCHAN  STAT ... COMMAND
140     1   129      poll   S        /sbin/portmap
040     0   135      rpciod SW       [rpciod]
040     0   136      svc_re SW       [lockd]
140     0   214      select S        /sbin/rpc.statd

I can easily reproduce the errors by restoring the original binary of=20
rpc.statd. Also, the error occurs on all - well both - my nfs-clients. The=
=20
error occurs very frequently when I am running with the original binaries.

Hope this information helps. I am willing to help any way I can to solve th=
is=20
bug.

Regards,

=46rans Pop

P.S. I already send a similar message to 165744@bugs.debian.org (CC Neil) o=
n=20
August 29, but as there was no reply to date I am trying again. I would=20
appreciate a reply.
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/Y3fkgm/Kwh6ICoQRApboAJ4gqgBY/KRL3WZg6QNu+jnni/5xwQCfTc6z
6/R4stFNt+a8EnlXjOp3NI8=3D
=3D/CN2
=2D----END PGP SIGNATURE-----



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Debian bug #165744 - 'Received erroneous SM_UNMON request'

[Chip Salzenberg]

According to Frans Pop:
> In monitor.c there is the statement
>    my_name = "127.0.0.1"
> when servicing SM_MON requests with secure-statd enabled.
> I think in my setup this causes the lookups in the run-time list (which use 
> my_name) to fail when servicing SM_UNMON requests if in my situation my_name 
> is equal to the real adresses of my boxes, causing the 'Received erroneous 
> SM_UNMON request' errors.

Interesting!

Neil, I'd seen the assignment to my_name but I figured it was just a
housekeeping variable for connections.  But if it's used in a later
lookup, assigning to my_name could be a Bad Thing.  I'm not sure
enough of my understanding of statd to answer this suggestion.

> I think this would also explain the 'notify_host: failed to notify 127.0.0.1' 
> errors. This second error occurs when I reboot the server while a 
> NFS-connection was up: after restarting the server tries to notify the client 
> it is back up, but can't because the client is not at localhost but at 
> 10.19.66.21 and there is no NFS-client running on the server itself.

You've lost me.

> I think the reason the error appears in my setup could be because I have NFS 
> kernel-support compiled in both server and clients. In Debian, this means 
> rpc.lockd is not run from the init scripts.

What does the timing of lockd have to do with it?  Because that's the
only difference between a user-space lockd and a kernel-thread lockd;
the kernel thread only starts up when something might need it, while
the user-space one starts up at boot time.
-- 
Chip Salzenberg               - a.k.a. -               <chip@pobox.com>
"I wanted to play hopscotch with the impenetrable mystery of existence,
    but he stepped in a wormhole and had to go in early."  // MST3K


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Debian bug #165744 - 'Received erroneous SM_UNMON request'

[Frans Pop]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

And here is the proof!
I added a simple log statement to the monitor.c source where SM_UNMON is=20
handled.

=3D=3D=3D SNIP FROM MONITOR.C =3D=3D=3D
* OK, we are.  Now look for appropriate entry in run-time list.
* There should only be *one* match on this, since I block "duplicate"
* SM_MON calls.  (Actually, duplicate calls are allowed, but only one
* entry winds up in the list the way I'm currently handling them.)
*/
while ((clnt =3D nlist_gethost(clnt, mon_name, 0))) {
+++++ ADDED LINES +++++
        log(L_WARNING, "Result of hostname lookup: %s is %s",
                my_name, NL_MY_NAME(clnt));
+++++ ADDED LINES END +++++
        if (matchhostname(NL_MY_NAME(clnt), my_name) &&
                NL_MY_PROC(clnt) =3D=3D id->my_proc &&
                NL_MY_PROG(clnt) =3D=3D id->my_prog &&
                NL_MY_VERS(clnt) =3D=3D id->my_vers) {
                /* Match! */
=3D=3D=3D END OF SNIP FROM MONITOR.C =3D=3D=3D

This results in my log in:
rpc.statd[3066]: Result of hostname lookup: galadriel is 127.0.0.1
rpc.statd[3066]: Received erroneous SM_UNMON request from galadriel for=20
10.19.66.2

On Monday 15 September 2003 04:23, Chip Salzenberg wrote:
> According to Frans Pop:
> > I think the reason the error appears in my setup could be because I have
> > NFS kernel-support compiled in both server and clients. In Debian, this
> > means rpc.lockd is not run from the init scripts.
>
> What does the timing of lockd have to do with it?  Because that's the
> only difference between a user-space lockd and a kernel-thread lockd;
> the kernel thread only starts up when something might need it, while
> the user-space one starts up at boot time.

I'm not sure how this would affect things. I was just looking for an=20
explanation why this problem has not been reported by many, many more peopl=
e=20
who use NFS.

=46rans Pop
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/Zezigm/Kwh6ICoQRAsBOAJ0aCpzc+i2BSx5DOccWRHFYeijclACgum3p
6ZlKRKULyVMcaL5LqQQj5GE=3D
=3DZkmx
=2D----END PGP SIGNATURE-----



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Debian bug #165744 - 'Received erroneous SM_UNMON request'

[Neil Brown]

On Sunday September 14, chip@pobox.com wrote:
> According to Frans Pop:
> > In monitor.c there is the statement
> >    my_name = "127.0.0.1"
> > when servicing SM_MON requests with secure-statd enabled.
> > I think in my setup this causes the lookups in the run-time list (which use 
> > my_name) to fail when servicing SM_UNMON requests if in my situation my_name 
> > is equal to the real adresses of my boxes, causing the 'Received erroneous 
> > SM_UNMON request' errors.
> 
> Interesting!
> 
> Neil, I'd seen the assignment to my_name but I figured it was just a
> housekeeping variable for connections.  But if it's used in a later
> lookup, assigning to my_name could be a Bad Thing.  I'm not sure
> enough of my understanding of statd to answer this suggestion.

There is definately something wrong here.
If my_name is forced to "127.0.0.1" in sm_mon_1_svc, then it should
also be force to that value in sm_unmon_1_svc.
However it is not clear to me that it needs to be forced to 127.0.0.1.
I guess it wouldn't hurt though.

I would suggest putting code in sm_unmon_1_svc to roughly match what
sm_mon_1_svc does in the RESTRICTED_STATD case.

NeilBrown


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs