rpc.statd in /sbin or /usr/sbin ??

rpc.statd in /sbin or /usr/sbin ??

[Neil Brown]

Hi,
 I have noticed that some distros like to install statd in /sbin
 rather than /usr/sbin.
 I would like to know why.

 If it is generally agreed that it needs to be in /sbin, then I'll
 change nfs-utils to install it there, but as yet I am unconvinced.

 The only reason I can see for putting statd in /sbin is if it were
 needed for mounting /usr (in cases where /usr is accessed via NFS).

 However in that case (as in the case for an NFS root), I think it is
 appropriate to use the "nolock" flag on the basis that /usr is not
 expected to be share-writeable (i.e. either readonly or
 single-client).  In that case there is no need for locking requests
 to go over the network, and no need for statd to be running before
 /usr is mounted.

 So: can anyone try to convince me that rpc.statd should go in /sbin??

Thanks,
NeilBrown

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.statd in /sbin or /usr/sbin ??

[Olaf Kirch]

On Monday 19 March 2007 02:14, Neil Brown wrote:
>  The only reason I can see for putting statd in /sbin is if it were
>  needed for mounting /usr (in cases where /usr is accessed via NFS).

Can't speak for others, but this is the reason why Suse put it into /sbin too,
as long as they shipped it.

Olaf
-- 
Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
okir@lst.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.statd in /sbin or /usr/sbin ??

[Steve Dickson]

Olaf Kirch wrote:
> On Monday 19 March 2007 02:14, Neil Brown wrote:
>>  The only reason I can see for putting statd in /sbin is if it were
>>  needed for mounting /usr (in cases where /usr is accessed via NFS).
> 
> Can't speak for others, but this is the reason why Suse put it into /sbin too,
> as long as they shipped it.
I can only assuming this was the case as well... Red Hat has
been putting both rpc.lockd and rpc.statd in /sbin
since at least RH 7.1

steved.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.statd in /sbin or /usr/sbin ??

[Neil Brown]

On Monday March 19, SteveD@redhat.com wrote:
> 
> 
> Olaf Kirch wrote:
> > On Monday 19 March 2007 02:14, Neil Brown wrote:
> >>  The only reason I can see for putting statd in /sbin is if it were
> >>  needed for mounting /usr (in cases where /usr is accessed via NFS).
> > 
> > Can't speak for others, but this is the reason why Suse put it into /sbin too,
> > as long as they shipped it.
> I can only assuming this was the case as well... Red Hat has
> been putting both rpc.lockd and rpc.statd in /sbin
> since at least RH 7.1
> 

Ok.... so the only reason for moving to /sbin is a reason that I don't
think is a good one.  I think I won't move it in 'upstream'.

So people should really mount '/usr' (and '/var') with 'nolock' (which
should really be spelt 'locallocks' or similar).  But they probably
don't.

So how about this: In a similar way that we now try to start statd if
'nolock' is not set, we could set 'nolock' if we fail to start statd
(and it isn't already running).  What do people think of that?
I should probably add an rpc ping to check if statd is running rather
than just looking in /var/run/rpc.statd.pid, but the principle seems
sound.... 

NeilBrown

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.statd in /sbin or /usr/sbin ??

[Talpey, Thomas]

At 01:12 AM 3/22/2007, Neil Brown wrote:
>So how about this: In a similar way that we now try to start statd if
>'nolock' is not set, we could set 'nolock' if we fail to start statd
>(and it isn't already running).  What do people think of that?

Gack. At worst, the mount should fail, instead of silently changing the
mount to one which may break application semantics! This would change
the default behavior in a way the admin couldn't override. Besides,
what's to say statd won't die later?

Tom.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: rpc.statd in /sbin or /usr/sbin ??

[Neil Brown]

On Thursday March 22, Thomas.Talpey@netapp.com wrote:
> At 01:12 AM 3/22/2007, Neil Brown wrote:
> >So how about this: In a similar way that we now try to start statd if
> >'nolock' is not set, we could set 'nolock' if we fail to start statd
> >(and it isn't already running).  What do people think of that?
> 
> Gack. At worst, the mount should fail, instead of silently changing the

Yes, failing would be adequate, and safer.

> mount to one which may break application semantics! This would change
> the default behavior in a way the admin couldn't override. Besides,
> what's to say statd won't die later?

The point is not to be alert for system malfunctions so much as to be
alert for mis-configurations.
Mounting an NFS filesystem with remote-locking enabled but without
having started statd is the wrong thing to do.  It seems that people
discover that and then want to start statd earlier.  I want to make
sure that when they discover that, they are encouraged to use local
locking if appropriate.

Thanks,
NeilBrown

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs