From: Hemmo Nieminen <hemmo.nieminen@iki.fi>

Instead of closing the sockets before requesting a new one, keep them
open until a suitable one is found. Otherwise bindresvport will return
the same port over and over again.

Signed-off-by: Steve Dickson <steved@redhat.com>

Some init systems actually expect daemons to return 0 on success.

Signed-off-by: Steve Dickson <steved@redhat.com>

This patch is essentially the same as the previous version, but has
been respun to fix up some merge conflicts with some of Chuck's
recent changes.

When we first added tirpc support, we took a "big hammer" approach, and
had it add libtirpc to $LIBS. That had the effect of making it so that
that library was linked into every binary. That's unnecessary, and
wasteful with memory.

Don't let AC_CHECK_LIB add -ltirpc to $LIBS. Instead, have the autoconf
tests set $(LIBTIRPC) in the makefiles, and have the programs that
need it explicitly include that library. In the event that we're not
using libtirpc, then set $LIBTIRPC to a blank string.

This necessitates a change to the bindresvport_sa check too. Since that
library is no longer included in $LIBS, we need to convert that check
to use AC_CHECK_LIB instead of AC_CHECK_FUNCS.

This patch also fixes a subtle bug. If the library was usable, but the
includes were not, the test would set $enable_tirpc to "no", but
HAVE_LIBTIRPC would still be true. That configuration would likely
fail to build.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve Dickson <steved@redhat.com>

sm-notify fails to remove monitor records from sm.bak when it has
finally notified a host.  This is because of a recent change to send
two SM_NOTIFY requests for each monitored peer: one with the local
host's FQDN, and one with an unqualified version of same.  This was
commit baa41b2c: "sm-notify: Send fully-qualified and unqualified
mon_names" (March 19, 2010).

Because of the March 2010 commit, sm-notify modifies the "my_name"
string during notification, but then uses this modified string to try
to find the monitor record to remove.  Of course the search for the
record fails.  So a persistent monitor record is left in sm.bak.

Aside from leaving trash around, this causes the same hosts to be
notified after every reboot, even if they successfully responded to
the previous SM_NOTIFY and they had no contact with us during the last
boot.

I also noticed that the trick of truncating the argument of SM_NOTIFY
doesn't work at all if a substitute "my_name" was specified via the "-v"
command line option.  This patch attempts to address that as well.

sm-notify should preserve the original my_name string so that
nsm_delete_host() can find the correct monitor record to delete.  Also
add some degree of protection to the mon_name and my_name strings in
each nsm_host record to prevent a future change from breaking this
dependency.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>

The logic in notify_host() watches the host->retries counter to see if
progress is not being made.  If progress stalls, notify_host() tries
another IP address.  This means sm-notify will generate a fresh
rpcbind query.

After an RPC succeeds, be sure to reset host->retries so sm-notify
doesn't start walking down the host's addrinfo list when we _are_
making progress.  In the common case, if the host responds, we avoid
extra rpcbind queries and send all requests for the host to the same
IP address.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>

An RPC retransmit timeout should start out the same for each new RPC
request.  Don't increase the retransmit timeout after receiving the
reply to the rpcbind query.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>

Clean up: refactor the logic in recv_rpcbind_reply() that re-schedules
an nsm_host into a separate helper function

Adjust debugging messages so it's always apparent when an nsm_host is
rescheduled.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>

It looks like the existing algorithm for verifying the passed-in bind
address is as broken as statd_matchhostname() used to be: for IP
addresses, AI_CANONNAME is useless.  We need to have getnameinfo(3) or
equivalent in there.

Clean up: extract the logic that verifies the command line bind
address into its own function, and make it handle canonical name
lookup correctly.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>

The job of statd_matchhostname() is to work hard at matching two
hostnames or presentation IP addresses that may refer to the same
host.

statd_matchhostname() turns the hostname of the local system into a
list of addresses containing only the loopback address.  The actual
DNS registered address of the system does not appear in that list.

Presentation IP addresses, on the other hand, are soundly ignored by
the AI_CANONNAME option of getaddrinfo(3).  The ai_canonname string
that is returned is just the same presentation IP address.  And the
resulting list of addresses contains just that IP address.

So if the DNS registered IP address of the local host is passed in as
one argument, and the local hostname is passed as the other argument,
statd_matchhostname() whiffs and believes there is no match.  To fix
this, the logic needs to be smarter about deriving a hostname from an
IP address.

This appears to cause no end of trouble: monitor records pile up in
/var/lib/nfs/sm and sm.bak, notifications are missed, and so on.  This
has likely been around since commit cbd3a131 "statd: Introduce statd
version of matchhostname()" (Jan 14, 2010).

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>

statd's "-F" flag disables syslog output, and specifies sm-notify's
"-d" option when it runs it.  sm-notify's "-d" option should therefore
also disable syslog output.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Steve Dickson <steved@redhat.com>