Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #83927 > unrolled thread
| Started by | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| First post | 2024-09-13 23:10 +0200 |
| Last post | 2024-09-13 23:10 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.debian.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Bug#711021: mount.nfs timeout for GETPORT is much too short Salvatore Bonaccorso <carnil@debian.org> - 2024-09-13 23:10 +0200
| From | Salvatore Bonaccorso <carnil@debian.org> |
|---|---|
| Date | 2024-09-13 23:10 +0200 |
| Subject | Bug#711021: mount.nfs timeout for GETPORT is much too short |
| Message-ID | <JmlId-c3Uz-5@gated-at.bofh.it> |
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
Back to top | Article view | linux.debian.kernel
csiph-web