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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 <[email protected]> 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 - [email protected]
> 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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs