time after which statd gives up

time after which statd gives up

[mehta kiran]

Hi ,=20
      On RHEL4 U1 i have observed that statd
      sends notification only till the=20
      max(if cannot notify) time 30 seconds.
      Then statd gives
      up and no files are there in sm.bak.

      Is this the expected behavior ?
      Should statd try notifying indefinitely ?
      If this is the behavior , what is use of sm.bak
      dir ?

thanks,
 kiran
     =20
=20

    =20
    =20


	=09
__________________________________=20
Yahoo! Mail=20
Stay connected, organized, and protected. Take the tour:=20
http://tour.mail.yahoo.com/mailtour.html=20



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: time after which statd gives up

[Steve Dickson]

mehta kiran wrote:
> Hi , 
>       On RHEL4 U1 i have observed that statd
>       sends notification only till the 
>       max(if cannot notify) time 30 seconds.
To be clear, you saying when rpc.statd is started
it sends out SM_NOTIFY messages notifying the clients
this machine just rebooted and it seems to do this for
30 seconds?

> 
>       Is this the expected behavior ?
Again not knowing the type of message you seeing, its
hard to tell...

steved.


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: time after which statd gives up

[mehta kiran]

Hi Steve ,=20
 These are the messages on server side.
 Shouldnt statd mv file from sm to sm.bak
 if its not able to notify client and later
 try to notify client(files in sm.bak) with
 low frequency.

[root@vcslinux5 tmp]# uname -a
Linux vcslinux5.vxindia.veritas.com 2.6.9-6.37.ELsmp
#1 SMP Tue Mar 29 15:43:19
EST 2005 i686 i686 i386 GNU/Linux




[root@vcslinux5 ~]# rpc.statd -d -F
07/05/2005 20:03:10 rpc.statd[26896]: Version 1.0.6
Starting
07/05/2005 20:03:10 rpc.statd[26896]: Flags: No-Daemon
Log-STDERR
07/05/2005 20:03:10 rpc.statd[26896]: New state: 93
07/05/2005 20:03:10 rpc.statd[26896]: Waiting for
reply... (timeo 5)
07/05/2005 20:03:16 rpc.statd[26896]: Waiting for
reply... (timeo 5)
07/05/2005 20:03:20 rpc.statd[26896]: Waiting for
reply... (timeo 1)
07/05/2005 20:03:22 rpc.statd[26896]: Waiting for
reply... (timeo 5)
07/05/2005 20:03:26 rpc.statd[26896]: Waiting for
reply... (timeo 1)
07/05/2005 20:03:28 rpc.statd[26896]: Waiting for
reply... (timeo 5)
07/05/2005 20:03:34 rpc.statd[26896]: Waiting for
reply... (timeo 5)
07/05/2005 20:03:38 rpc.statd[26896]: Waiting for
reply... (timeo 1)
07/05/2005 20:03:40 rpc.statd[26896]: Cannot notify
10.212.99.95, giving up.

07/05/2005 20:03:40 rpc.statd[26896]: Can't notify
10.212.99.95, giving up.
07/05/2005 20:03:40 rpc.statd[26896]: Unlinked
/var/lib/nfs/statd/sm.bak/10.212.99.95
07/05/2005 20:03:40 rpc.statd[26896]: Waiting for
client connections.
07/05/2005 20:03:44 rpc.statd[26896]: Caught signal 2,
un-registering and exitin

thanks,
 kiran

--- Steve Dickson <SteveD@redhat.com> wrote:

> mehta kiran wrote:
> > Hi ,=20
> >       On RHEL4 U1 i have observed that statd
> >       sends notification only till the=20
> >       max(if cannot notify) time 30 seconds.
> To be clear, you saying when rpc.statd is started
> it sends out SM_NOTIFY messages notifying the
> clients
> this machine just rebooted and it seems to do this
> for
> 30 seconds?
>=20
> >=20
> >       Is this the expected behavior ?
> Again not knowing the type of message you seeing,
> its
> hard to tell...
>=20
> steved.
>=20
>=20
>
-------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> informative Webcasts and more! Get everything you
> need to get up to
> speed, fast.
>
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs
>=20



	=09
____________________________________________________=20
Yahoo! Sports=20
Rekindle the Rivalries. Sign up for Fantasy Football=20
http://football.fantasysports.yahoo.com


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs