Bug#711021: mount.nfs timeout for GETPORT is much too short
- To: Ben Hutchings <ben@decadent.org.uk>, 711021@bugs.debian.org
- Subject: Bug#711021: mount.nfs timeout for GETPORT is much too short
- From: Salvatore Bonaccorso <carnil@debian.org>
- Date: Fri, 13 Sep 2024 23:04:47 +0200
- Message-id: <[🔎] ZuSo7xxKSq1kR7v4@eldamar.lan>
- Reply-to: Salvatore Bonaccorso <carnil@debian.org>, 711021@bugs.debian.org
- In-reply-to: <24c58743e5f509ac39dd6f23a3f80f86a4c2ca5f.camel@decadent.org.uk>
- References: <1370314197.21654.23.camel@deadeye.wl.decadent.org.uk> <1370314197.21654.23.camel@deadeye.wl.decadent.org.uk> <24c58743e5f509ac39dd6f23a3f80f86a4c2ca5f.camel@decadent.org.uk> <1370314197.21654.23.camel@deadeye.wl.decadent.org.uk>
Hi Ben,
On Sat, Mar 19, 2022 at 08:58:46PM +0100, Ben Hutchings wrote:
> I'm not sure that this bug was ever fixed.
>
> nfs-utils actually uses nfs_getport() to get the port. That passes a
> timeout of {-1, 0} to libtirpc, which is invalid and should result in
> using the rpcbind client's default timeout.
>
> The TCP client interface is implemented in src/clnt_vc.c. It has a
> default timeout (ct_wait field) that can be set with CLNT_CONTROL(...,
> CLSET_TIMEOUT, ...), but nfs-utils doesn't seem to do that. So it
> seems like there is a default timeout of 0!
Is this still something we need to report upstream? (And if so, could
you do it?).
Regards,
Salvatore
Reply to: