Old versions of glibc (< 2.4) have a getaddrinfo(3) implementation, but
do not include public definitions of the AI_V4MAPPED, AI_ALL, and
AI_ADDRCONFIG flags because it was believed that these flags were not
standardized. However, these flags have standard definitions both in
POSIX 1003 and in RFCs, and were thus included in later releases of
glibc.
To allow the mount.nfs command to build on systems with these older
versions of glibc, add conditional definitions for these flags in
utils/mount/network.c.
Signed-off-by: Chuck Lever <[email protected]>
---
Steve, Gabor tested this and it fixes his build problem (glibc-2.2).
If you have no objections, please apply to your nfs-utils repo.
utils/mount/network.c | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/utils/mount/network.c b/utils/mount/network.c
index 75354a7..0023769 100644
--- a/utils/mount/network.c
+++ b/utils/mount/network.c
@@ -48,6 +48,24 @@
#include "mount_constants.h"
#include "network.h"
+/*
+ * Earlier versions of glibc's /usr/include/netdb.h exclude these
+ * definitions because it was thought they were not part of a stable
+ * POSIX standard. However, they are defined by RFC 2553 and 3493
+ * and in POSIX 1003.1-2001, so these definitions were added in later
+ * versions of netdb.h.
+ */
+#ifndef AI_V4MAPPED
+#define AI_V4MAPPED 0x0008 /* IPv4-mapped addresses are acceptable. */
+#endif /* AI_V4MAPPED */
+#ifndef AI_ALL
+#define AI_ALL 0x0010 /* Return both IPv4 and IPv6 addresses. */
+#endif /* AI_ALL */
+#ifndef AI_ADDRCONFIG
+#define AI_ADDRCONFIG 0x0020 /* Use configuration of this host to choose \
+ returned address type. */
+#endif /* AI_ADDRCONFIG */
+
#define PMAP_TIMEOUT (10)
#define CONNECT_TIMEOUT (20)
#define MOUNT_TIMEOUT (30)
Chuck Lever wrote:
> Old versions of glibc (< 2.4) have a getaddrinfo(3) implementation, but
> do not include public definitions of the AI_V4MAPPED, AI_ALL, and
> AI_ADDRCONFIG flags because it was believed that these flags were not
> standardized. However, these flags have standard definitions both in
> POSIX 1003 and in RFCs, and were thus included in later releases of
> glibc.
>
> To allow the mount.nfs command to build on systems with these older
> versions of glibc, add conditional definitions for these flags in
> utils/mount/network.c.
>
> Signed-off-by: Chuck Lever <[email protected]>
> ---
Committed....
steved.
On Wed, Jul 30, 2008 at 2:50 AM, Gabor Z. Papp <gzp-2g/[email protected]> wrote:
> | Untested. Gabor, can you please try this?
>
> Compiled fine.
Excellent, thanks for testing.
> utils/mountd/Makefile:
>
> LIBBLKID = -lblkid
>
> -lblkid doesn't enough in dependency, needs -luuid
>
> Is this problem in my e2fsprogs install?
This one I'm not an expert on, but it seems to me you might find some
relevant information by searching the archives of the linux-nfs
mailing list over the past year.
I thought libuuid was already called out in configure.ac, but I could
be completely wrong about that.
> BTW, I'm not sure about usage of sm-notify
>
> My nfs startup script looks like:
>
> idmapd
> exportfs -ar
> mountd
> statd #--no-notify
> nfsd 8
>
> $ ps fax
> 10860 ? Ss 0:00 mountd
> 10862 ? Ss 0:00 statd
> 10875 ? S 0:00 [nfsd]
> 10876 ? S 0:00 [nfsd]
> 10886 ? S 0:00 [lockd]
> 10887 ? S 0:00 \_ [rpciod]
> 10888 ? S 0:00 [nfsd]
> 10889 ? S 0:00 [nfsd]
> 10890 ? S 0:00 [nfsd]
> 10891 ? S 0:00 [nfsd]
> 10892 ? S 0:00 [nfsd]
> 10893 ? S 0:00 [nfsd]
>
> Looks like no sm-notify started, even I mount something from a remote
> host. If I start sm-notify by hand, it exist, strace output attached.
> Same apply on glibc 2.3.
That might take some debugging. There were some last minute changes
to sm-notify before 1.1.3 was released.
--
Chuck Lever
Gabor Z. Papp wrote:
> * Chuck Lever <[email protected]>:
>
> | Untested. Gabor, can you please try this?
>
> Compiled fine.
>
> utils/mountd/Makefile:
>
> LIBBLKID = -lblkid
>
> -lblkid doesn't enough in dependency, needs -luuid
>
> Is this problem in my e2fsprogs install?
At least in my world you also need the e2fsprogs-devel package
installed as well...
>
> BTW, I'm not sure about usage of sm-notify
>
> My nfs startup script looks like:
>
> idmapd
> exportfs -ar
> mountd
> statd #--no-notify
> nfsd 8
>
> $ ps fax
> 10860 ? Ss 0:00 mountd
> 10862 ? Ss 0:00 statd
> 10875 ? S 0:00 [nfsd]
> 10876 ? S 0:00 [nfsd]
> 10886 ? S 0:00 [lockd]
> 10887 ? S 0:00 \_ [rpciod]
> 10888 ? S 0:00 [nfsd]
> 10889 ? S 0:00 [nfsd]
> 10890 ? S 0:00 [nfsd]
> 10891 ? S 0:00 [nfsd]
> 10892 ? S 0:00 [nfsd]
> 10893 ? S 0:00 [nfsd]
>
> Looks like no sm-notify started, even I mount something from a remote
> host. If I start sm-notify by hand, it exist, strace output attached.
> Same apply on glibc 2.3.
Note that sm-notify is a very short lived process....
If have found using the -d flag is very handy when starting sm-notify
by hand... If there is no output, it means the /var/run/sm-notify.pid exists
which causes sm-notify to immediately exit. So remove that file and try
again...
In general, if there are file(s) in /var/lib/nfs/sm (or /var/lib/nfs/statd/sm
depending on your distro) means sm-notify did not work. With Fedora, doing
a 'service nfslock restart' will cause sm-notify to be rerun... I'm not
sure how to do that with other distros...
steved.
* Steve Dickson <[email protected]>:
| > -lblkid doesn't enough in dependency, needs -luuid
| >
| > Is this problem in my e2fsprogs install?
| At least in my world you also need the e2fsprogs-devel package
| installed as well...
libs and headers presents
| > Same apply on glibc 2.3.
| Note that sm-notify is a very short lived process....
| If have found using the -d flag is very handy when starting sm-notify
| by hand... If there is no output, it means the /var/run/sm-notify.pid exists
| which causes sm-notify to immediately exit. So remove that file and try
| again...
Sure done that first. Attached strace output happens on fresh start.
| In general, if there are file(s) in /var/lib/nfs/sm (or /var/lib/nfs/statd/sm
| depending on your distro) means sm-notify did not work. With Fedora, doing
| a 'service nfslock restart' will cause sm-notify to be rerun... I'm not
| sure how to do that with other distros...
Those dirs are empty.
Gabor Z. Papp wrote:
> * Steve Dickson <[email protected]>:
>
> | > -lblkid doesn't enough in dependency, needs -luuid
> | >
> | > Is this problem in my e2fsprogs install?
> | At least in my world you also need the e2fsprogs-devel package
> | installed as well...
>
> libs and headers presents
hmm... that's curious... I wonder if there is some type of dependences
in later lib versions that will automagically load the need libs...
>
> | > Same apply on glibc 2.3.
> | Note that sm-notify is a very short lived process....
>
> | If have found using the -d flag is very handy when starting sm-notify
> | by hand... If there is no output, it means the /var/run/sm-notify.pid exists
> | which causes sm-notify to immediately exit. So remove that file and try
> | again...
>
> Sure done that first. Attached strace output happens on fresh start.
Ah... I did notice that...
>
> | In general, if there are file(s) in /var/lib/nfs/sm (or /var/lib/nfs/statd/sm
> | depending on your distro) means sm-notify did not work. With Fedora, doing
> | a 'service nfslock restart' will cause sm-notify to be rerun... I'm not
> | sure how to do that with other distros...
>
> Those dirs are empty.
So either there were no locks to recover or sm-notify did indeed work...
steved.
* Steve Dickson <[email protected]>:
| > | In general, if there are file(s) in /var/lib/nfs/sm (or /var/lib/nfs/statd/sm
| > | depending on your distro) means sm-notify did not work. With Fedora, doing
| > | a 'service nfslock restart' will cause sm-notify to be rerun... I'm not
| > | sure how to do that with other distros...
| >
| > Those dirs are empty.
| So either there were no locks to recover or sm-notify did indeed work...
How sm-notify works in general? Called by statd?
If first time works, pid file left and second time didn't run as you
mentoided. So something wrong here...