/run is guaranteed to be available and writeable at any time, whereas
/var might be on a separate partition and hence not available during
early boot. By moving the socket from /var to /run we are able to use
rpcbind earlier, which would in particular make a difference in case
/var is on an nfs mount, something I am currently seeing bug reports
about.
This change should not make a difference to software that currently
works as intended, as /var/run should be a symlink or bindmounted
to /run, so anyone relying on the socket being in /var/run will
still find it there.
The /run directory is supported by all the major distributions
(at least Debian, Fedora, Suse, Ubuntu and Arch from what I can gather).
See http://wiki.debian.org/ReleaseGoals/RunDirectory and
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976 for some
more details.
Cc: Kay Sievers <[email protected]>
Signed-off-by: Tom Gundersen <[email protected]>
---
tirpc/rpc/rpcb_prot.h | 2 +-
tirpc/rpc/rpcb_prot.x | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tirpc/rpc/rpcb_prot.h b/tirpc/rpc/rpcb_prot.h
index 7ae48b8..63b4a2c 100644
--- a/tirpc/rpc/rpcb_prot.h
+++ b/tirpc/rpc/rpcb_prot.h
@@ -476,7 +476,7 @@ extern bool_t xdr_netbuf(XDR *, struct netbuf *);
#define RPCBVERS_3 RPCBVERS
#define RPCBVERS_4 RPCBVERS4
-#define _PATH_RPCBINDSOCK "/var/run/rpcbind.sock"
+#define _PATH_RPCBINDSOCK "/run/rpcbind.sock"
#else /* ndef _KERNEL */
#ifdef __cplusplus
diff --git a/tirpc/rpc/rpcb_prot.x b/tirpc/rpc/rpcb_prot.x
index b21ac3d..ebe1e60 100644
--- a/tirpc/rpc/rpcb_prot.x
+++ b/tirpc/rpc/rpcb_prot.x
@@ -410,7 +410,7 @@ program RPCBPROG {
%#define RPCBVERS_3 RPCBVERS
%#define RPCBVERS_4 RPCBVERS4
%
-%#define _PATH_RPCBINDSOCK "/var/run/rpcbind.sock"
+%#define _PATH_RPCBINDSOCK "/run/rpcbind.sock"
%
%#else /* ndef _KERNEL */
%#ifdef __cplusplus
--
1.7.8
On Thursday 08 December 2011, Tom Gundersen wrote:
> /run is guaranteed to be available and writeable at any time, whereas
> /var might be on a separate partition and hence not available during
> early boot. By moving the socket from /var to /run we are able to use
> rpcbind earlier, which would in particular make a difference in case
> /var is on an nfs mount, something I am currently seeing bug reports
> about.
I don't have /run on any system so IMHO it's not really guaranteed. Does
it will be created if not existent? I hope not.
cu,
Rudi
Hi Chuck,
On Thu, Dec 8, 2011 at 10:40 PM, Chuck Lever <[email protected]> wrote:
>
> On Dec 8, 2011, at 2:19 PM, Tom Gundersen wrote:
>
>> /run is guaranteed to be available and writeable at any time, whereas
>> /var might be on a separate partition and hence not available during
>> early boot. By moving the socket from /var to /run we are able to use
>> rpcbind earlier, which would in particular make a difference in case
>> /var is on an nfs mount, something I am currently seeing bug reports
>> about.
>
> I don't understand this part. /var should be mounted with "nolock" so there should not be a need to have rpcbind running. Can you explain what this is about?
You are right, this particular problem can be written off as a
configuration error. However, if I understand correctly moving
/var/run and /var/lock off of /var would eliminate the need to mount
/var with nolock, and things would "just work", regardless of the
mount options.
Another reason to want the sockets in /run would be the desire to
start using rpcbind before /var is mounted (even if /var does not
itself rely on rpcbind). E.g. to start mounting a remote /home while
the local /var is still being fsck'ed.
>> This change should not make a difference to software that currently
>> works as intended, as /var/run should be a symlink or bindmounted
>> to /run, so anyone relying on the socket being in /var/run will
>> still find it there.
>
> Even the kernel?
Good question, it had not occurred to me that the kernel might resolve
the paths differently than userspace programs. I'll have to look into
that.
Thanks for the feedback!
Tom
On Dec 8, 2011, at 6:05 PM, Tom Gundersen wrote:
> Hi Chuck,
>
> On Thu, Dec 8, 2011 at 10:40 PM, Chuck Lever <[email protected]> wrote:
>>
>> On Dec 8, 2011, at 2:19 PM, Tom Gundersen wrote:
>>
>>> /run is guaranteed to be available and writeable at any time, whereas
>>> /var might be on a separate partition and hence not available during
>>> early boot. By moving the socket from /var to /run we are able to use
>>> rpcbind earlier, which would in particular make a difference in case
>>> /var is on an nfs mount, something I am currently seeing bug reports
>>> about.
>>
>> I don't understand this part. /var should be mounted with "nolock" so there should not be a need to have rpcbind running. Can you explain what this is about?
>
> You are right, this particular problem can be written off as a
> configuration error. However, if I understand correctly moving
> /var/run and /var/lock off of /var would eliminate the need to mount
> /var with nolock, and things would "just work", regardless of the
> mount options.
/var/lib/nfs is another reason why you can't do locking on /var.
> Another reason to want the sockets in /run would be the desire to
> start using rpcbind before /var is mounted (even if /var does not
> itself rely on rpcbind). E.g. to start mounting a remote /home while
> the local /var is still being fsck'ed.
>
>>> This change should not make a difference to software that currently
>>> works as intended, as /var/run should be a symlink or bindmounted
>>> to /run, so anyone relying on the socket being in /var/run will
>>> still find it there.
>>
>> Even the kernel?
>
> Good question, it had not occurred to me that the kernel might resolve
> the paths differently than userspace programs. I'll have to look into
> that.
>
> Thanks for the feedback!
>
> Tom
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
On Dec 8, 2011, at 2:19 PM, Tom Gundersen wrote:
> /run is guaranteed to be available and writeable at any time, whereas
> /var might be on a separate partition and hence not available during
> early boot. By moving the socket from /var to /run we are able to use
> rpcbind earlier, which would in particular make a difference in case
> /var is on an nfs mount, something I am currently seeing bug reports
> about.
I don't understand this part. /var should be mounted with "nolock" so there should not be a need to have rpcbind running. Can you explain what this is about?
> This change should not make a difference to software that currently
> works as intended, as /var/run should be a symlink or bindmounted
> to /run, so anyone relying on the socket being in /var/run will
> still find it there.
Even the kernel?
> The /run directory is supported by all the major distributions
> (at least Debian, Fedora, Suse, Ubuntu and Arch from what I can gather).
> See http://wiki.debian.org/ReleaseGoals/RunDirectory and
> http://thread.gmane.org/gmane.linux.redhat.fedora.devel/146976 for some
> more details.
>
> Cc: Kay Sievers <[email protected]>
> Signed-off-by: Tom Gundersen <[email protected]>
> ---
> tirpc/rpc/rpcb_prot.h | 2 +-
> tirpc/rpc/rpcb_prot.x | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tirpc/rpc/rpcb_prot.h b/tirpc/rpc/rpcb_prot.h
> index 7ae48b8..63b4a2c 100644
> --- a/tirpc/rpc/rpcb_prot.h
> +++ b/tirpc/rpc/rpcb_prot.h
> @@ -476,7 +476,7 @@ extern bool_t xdr_netbuf(XDR *, struct netbuf *);
> #define RPCBVERS_3 RPCBVERS
> #define RPCBVERS_4 RPCBVERS4
>
> -#define _PATH_RPCBINDSOCK "/var/run/rpcbind.sock"
> +#define _PATH_RPCBINDSOCK "/run/rpcbind.sock"
>
> #else /* ndef _KERNEL */
> #ifdef __cplusplus
> diff --git a/tirpc/rpc/rpcb_prot.x b/tirpc/rpc/rpcb_prot.x
> index b21ac3d..ebe1e60 100644
> --- a/tirpc/rpc/rpcb_prot.x
> +++ b/tirpc/rpc/rpcb_prot.x
> @@ -410,7 +410,7 @@ program RPCBPROG {
> %#define RPCBVERS_3 RPCBVERS
> %#define RPCBVERS_4 RPCBVERS4
> %
> -%#define _PATH_RPCBINDSOCK "/var/run/rpcbind.sock"
> +%#define _PATH_RPCBINDSOCK "/run/rpcbind.sock"
> %
> %#else /* ndef _KERNEL */
> %#ifdef __cplusplus
> --
> 1.7.8
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com