Path: csiph.com!tncsrv06.tnetconsulting.net!newsfeed.endofthelinebbs.com!news.corradoroberto.it!gothmog.csi.it!bofh.it!news.nic.it!robomod From: "Debian Bug Tracking System" Newsgroups: linux.debian.kernel Subject: Bug#711021: marked as done (mount.nfs timeout for GETPORT is much too short) Date: Sun, 22 Sep 2024 23:20:01 +0200 Message-ID: References: X-Original-To: Ben Hutchings X-Mailbox-Line: From debian-kernel-request@lists.debian.org Sun Sep 22 21:15:22 2024 Old-Return-Path: X-Amavis-Spam-Status: No, score=-112.51 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, BODY_INCLUDES_PACKAGE=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FOURLA=0.1, LDO_WHITELIST=-5, MD5_SHA1_SUM=-1, PGPSIGNATURE=-5, USER_IN_DKIM_WELCOMELIST=-0.01, USER_IN_DKIM_WHITELIST=-100, YOURMESSAGEBOD=2.5] autolearn=ham autolearn_force=no MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) X-Debian-Pr-Message: closed 711021 X-Debian-Pr-Package: nfs-common X-Debian-Pr-Source: nfs-utils Reply-To: 711021@bugs.debian.org Content-Type: multipart/mixed; boundary="----------=_1727039702-1492650-0" X-Mailing-List: archive/latest/144558 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/handler.711021.D711021.17270395271490811.ackdone@bugs.debian.org Approved: robomod@news.nic.it Lines: 338 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Sun, 22 Sep 2024 21:15:02 +0000 X-Original-Message-ID: X-Original-References: <1370314197.21654.23.camel@deadeye.wl.decadent.org.uk> Xref: csiph.com linux.debian.kernel:84080 This is a multi-part message in MIME format... ------------=_1727039702-1492650-0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your message dated Sun, 22 Sep 2024 23:12:00 +0200 with message-id and subject line Re: mount.nfs timeout for GETPORT is much too short has caused the Debian Bug report #711021, regarding mount.nfs timeout for GETPORT is much too short to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) --=20 711021: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D711021 Debian Bug Tracking System Contact owner@bugs.debian.org with problems ------------=_1727039702-1492650-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by bugs.debian.org; 4 Jun 2013 02:50:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2-bugs.debian.org_2005_01_02 (2011-06-06) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-13.7 required=4.0 tests=BAYES_00,DIGITS_LETTERS, FOURLA,HAS_PACKAGE,PGPSIGNATURE,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 18; hammy, 151; neutral, 302; spammy, 0. spammytokens: hammytokens:0.000-+--H*c:pgp-sha512, 0.000-+--H*F:D*decadent.org.uk, 0.000-+--H*RU:sk:shadbol, 0.000-+--HX-SA-Exim-Scanned:sk:shadbol, 0.000-+--H*r:sk:shadbol Return-path: Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]) by buxtehude.debian.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UjhK7-0005Av-O7 for submit@bugs.debian.org; Tue, 04 Jun 2013 02:50:12 +0000 Received: from [192.168.4.101] (helo=deadeye.wl.decadent.org.uk) by shadbolt.decadent.org.uk with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1UjhK4-00035n-Jc for submit@bugs.debian.org; Tue, 04 Jun 2013 03:50:08 +0100 Received: from ben by deadeye.wl.decadent.org.uk with local (Exim 4.80) (envelope-from ) id 1UjhJz-000741-20 for submit@bugs.debian.org; Tue, 04 Jun 2013 03:50:03 +0100 Message-ID: <1370314197.21654.23.camel@deadeye.wl.decadent.org.uk> Subject: mount.nfs timeout for GETPORT is much too short From: Ben Hutchings To: submit@bugs.debian.org Date: Tue, 04 Jun 2013 03:49:57 +0100 Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-7j7x6Fll0b60/NIUbv6J" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 192.168.4.101 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Delivered-To: submit@bugs.debian.org --=-7j7x6Fll0b60/NIUbv6J Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Package: nfs-common Version: 1:1.2.6-3 Severity: important This NFS client stopped being able to mount from my NFS server at boot time, around the time I upgraded them both to wheezy. I think the problem started when only the server was upgraded and was ultimately triggered by avahi-daemon being installed. Since cups now recommends avahi-daemon, this can be considered a common configuration. I took a packet capture on both sides (which matched, so no packets are being lost) and saw that: - The client makes a GETPORT call - The client retries a few times at 1 second intervals, then (if using TCP) closes the connection - About 5 seconds after the first call from the client, the server sends a reply. (strace-ing rpcbind showed it requesting a reverse DNS lookup from avahi, which apparently has a 5 second timeout for mDNS lookups. The client should have had a proper reverse DNS entry, but didn't.) - The client sends a RST (TCP) or ICMP port unreachable error (UDP) when receiving the reply The relevant functions include nfs_pmap_getport() in support/nfs/getport.c, which even has a comment to say: * 2. This version times out quickly by default. It time-limits the * connect process as well as the actual RPC call, and even allows the * caller to specify the timeout. I don't know why it does this, though perhaps the intent was to fail-over quickly when auto-detecting whether the remote portmap/rpcbind uses TCP or UDP. But having failed to query on both protocols, the timeout ought to be increased when retrying. Ben. -- Package-specific info: -- rpcinfo -- program vers proto port 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 46254 status 100024 1 tcp 58492 status 100021 1 udp 33374 nlockmgr 100021 3 udp 33374 nlockmgr 100021 4 udp 33374 nlockmgr 100021 1 tcp 40195 nlockmgr 100021 3 tcp 40195 nlockmgr 100021 4 tcp 40195 nlockmgr -- /etc/default/nfs-common -- NEED_STATD=3D STATDOPTS=3D NEED_IDMAPD=3D NEED_GSSD=3D -- /etc/idmapd.conf -- [General] Verbosity =3D 0 Pipefs-Directory =3D /var/lib/nfs/rpc_pipefs [Mapping] Nobody-User =3D nobody Nobody-Group =3D nogroup -- /etc/fstab -- shadbolt:/home /home nfs nfsvers=3D3,nodev,nosuid,mountproto= =3Dtcp 0 0 shadbolt:/usr/local /usr/local nfs nfsvers=3D3,nodev,nosuid,mountproto= =3Dtcp 0 0 -- /proc/mounts -- rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0 shadbolt:/home /home nfs rw,nosuid,nodev,relatime,vers=3D3,rsize=3D262144,w= size=3D262144,namlen=3D255,hard,proto=3Dtcp,timeo=3D600,retrans=3D2,sec=3Ds= ys,mountaddr=3D192.168.2.1,mountvers=3D3,mountport=3D33045,mountproto=3Dtcp= ,local_lock=3Dnone,addr=3D192.168.2.1 0 0 shadbolt:/usr/local /usr/local nfs rw,nosuid,nodev,relatime,vers=3D3,rsize= =3D262144,wsize=3D262144,namlen=3D255,hard,proto=3Dtcp,timeo=3D600,retrans= =3D2,sec=3Dsys,mountaddr=3D192.168.2.1,mountvers=3D3,mountport=3D33045,moun= tproto=3Dtcp,local_lock=3Dnone,addr=3D192.168.2.1 0 0 -- System Information: Debian Release: 7.0 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'proposed-upd= ates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=3Den_GB.UTF-8, LC_CTYPE=3Den_GB.UTF-8 (charmap=3DUTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nfs-common depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-41 ii libc6 2.13-38 ii libcap2 1:2.22-1.2 ii libcomerr2 1.42.5-1.1 ii libdevmapper1.02.1 2:1.02.74-7 ii libevent-2.0-5 2.0.19-stable-3 ii libgssglue1 0.4-2 ii libk5crypto3 1.10.1+dfsg-5 ii libkeyutils1 1.5.5-3 ii libkrb5-3 1.10.1+dfsg-5 ii libmount1 2.20.1-5.3 ii libnfsidmap2 0.25-4 ii libtirpc1 0.2.2-5 ii libwrap0 7.6.q-24 ii lsb-base 4.1+Debian8 ii rpcbind 0.2.0-8 ii ucf 3.0025+nmu3 Versions of packages nfs-common recommends: ii python 2.7.3-4 Versions of packages nfs-common suggests: pn open-iscsi pn watchdog -- no debconf information --=-7j7x6Fll0b60/NIUbv6J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIVAwUAUa1V1ee/yOyVhhEJAQr15Q//Q6T4oKnpEgkr28+Ebrx5PIUlumhO4Xaz RUdmAFHPkfvdUv8N1WSWHozMKWxBad97Du4uE9c7h5vz1GUguZm6tU0oWzpUa+Ql Zqim/Z14Ik8Ef4sBmXpxB6dy+3mABiMdCxG0Lbl6ov9HKFJq/cLuZfXlEYLMfBmk 0xWXTUIr1/JtOMPG1RX/khjyzlrEWliBrDVP7Yt6rqJq+3du76A+Y3OFCXkfaEw/ KEauAjZAcnwF7jj+sFyyv9D7MBORs1R+BCa6ScZxEb2zc9ogx6mCd3AKl7C1dcHO bBc4p7DYihAS0JZ54so4Xc9U1Sq8CRA9j+fS5emEMObaO4dNJKL7LKMWlKgmeE8d /wLbe88Agq9GvobRIUS1XzN3GhVqpQSC0apE3ijLgmIYUn6FULXTCVOmahOaKsCM d7a4S47pcWljlcCy2gNg8wdN4BNgVsFjCJZ7K593z61yTaXtTw+EH77prfcTbRpd nvGliL4nG//eqKBYZGdvyhbyfT0dsXlDVgv6EcUY9lUw78iF9dBd9/WNWEKCK0QK tYAE6H3lQwNiZqdRI271rLiyjzs0xiIExPJ/NcD2QtbMxe/2F66DNAHd3jc0oVvl joBIePevzyTjeCjTjofE9EQAKdsGWO6Ttchyj3ebqon3j/MfjxB50CpD7e2TwtQo eRlJTsinKIE= =HtNq -----END PGP SIGNATURE----- --=-7j7x6Fll0b60/NIUbv6J-- ------------=_1727039702-1492650-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 711021-done) by bugs.debian.org; 22 Sep 2024 21:12:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.6-bugs.debian.org_2005_01_02 (2021-04-09) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-9.0 required=4.0 tests=BAYES_00,PGPSIGNATURE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 14; hammy, 150; neutral, 54; spammy, 0. spammytokens: hammytokens:0.000-+--H*u:Evolution, 0.000-+--H*F:D*decadent.org.uk, 0.000-+--H*rp:D*decadent.org.uk, 0.000-+--H*r:sk:ben@dec, 0.000-+--HX-SA-Exim-Mail-From:sk:ben@dec Return-path: Received: from maynard.decadent.org.uk ([65.21.191.19]:33176) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1ssTsG-006Fos-Nb for 711021-done@bugs.debian.org; Sun, 22 Sep 2024 21:12:07 +0000 Received: from [2a02:578:851f:1502:391e:c5f5:10e2:b9a3] (helo=deadeye) by maynard with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1ssTsD-009MIe-0B for 711021-done@bugs.debian.org; Sun, 22 Sep 2024 21:12:05 +0000 Received: from ben by deadeye with local (Exim 4.98) (envelope-from ) id 1ssTsC-00000005xDf-0TqB for 711021-done@bugs.debian.org; Sun, 22 Sep 2024 23:12:04 +0200 Message-ID: Subject: Re: mount.nfs timeout for GETPORT is much too short From: Ben Hutchings To: 711021-done@bugs.debian.org Date: Sun, 22 Sep 2024 23:12:00 +0200 In-Reply-To: <24c58743e5f509ac39dd6f23a3f80f86a4c2ca5f.camel@decadent.org.uk> References: <1370314197.21654.23.camel@deadeye.wl.decadent.org.uk> <24c58743e5f509ac39dd6f23a3f80f86a4c2ca5f.camel@decadent.org.uk> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Tgxy4ZHkrTcgNhFsCNTR" User-Agent: Evolution 3.53.3-1 MIME-Version: 1.0 X-SA-Exim-Connect-IP: 2a02:578:851f:1502:391e:c5f5:10e2:b9a3 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on maynard); SAEximRunCond expanded to false --=-Tgxy4ZHkrTcgNhFsCNTR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wrote: > I'm not sure that this bug was ever fixed. >=20 > 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. This analysis was wrong. nfs_getport() first calls nfs_gp_get_rpcbclient() -> nfs_get_rpcclient() -> nfs_get_tcpclient() or nfs_get_udpclient(), and those last two function update the timeout to be 10 seconds (TCP) or 3 seconds (UDP). That hasn't changed between the version I reported against (1.2.6-3) and the current 2.7.1-3. Salvatore Bonaccorso wrote: [...] > Is this still something we need to report upstream? (And if so, could > you do it?). I can't find the bug, and I don't particularly to care to investigate any more, so I'm closing this report. Ben. --=20 Ben Hutchings The two most common things in the universe are hydrogen and stupidity. --=-Tgxy4ZHkrTcgNhFsCNTR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCspvTSmr92z9o8157/I7JWGEQkFAmbwiCAACgkQ57/I7JWG EQmuHw/+LKl4sz73sO9LGmCLFL6b+Wiq8qd74YS6GBM0SlDaWA7TK3DD3Tox4K7J Pfx6ITANkuC77/W0+CK/JAmhSDeieKbmSe5u52cEBniYCI5xOXf9DMOAOI2iVw/e ie+WeSTHXs6a5AXC7pqnumx+jzj8KfUIjqNN0rmDSUUIQuBOfiMFZqbHrAC5Mq4Y nh7G/uZ1UZ3TjF3bVI7eRWMLsw1N6bYa5lQ0kmVcB8m3VhdaBa6JxiSrB/wsjPKb +vqcQUuC4/pbINng+aRpTHnzCYnR78HYqlW6eZ90dw0GTPGF6BWEGwaZPr7BFY56 FUIOhshG+0hhOHeeNTAzRCNRSobi9QDie1oEpPA0IKzfqn1Sq4iyzG5KEmXrcQIW lPZw+dtd9dv5oh9ny1O4nTTmzuwyrlgzx7Fwm7QtpFUTyndPfy+fLFhma26kHHmC bLirnCo7zLkWeLXRFNez15G9M+Dkt9hbhxn+WxzNOucNzetFPj89gvsVdzT3Br2A JG2gVvrJ/TVNKscBYcwgf4lXx8Vk6ZMEoHq3r2UJ/gW0pmDXcdg/kKFAxsf5faoX BdXnAdf1fJqqkiuQZ5Kxr5j2INHaO7YZC3pCFr8B3Re1+Qqxa9Kz8ulF2ewa4Q8q sbnVeU0mMAmqAPSJwYiWhdbQD3IQO9Spwhbk9j2He/MmmEqWqeM= =6e+j -----END PGP SIGNATURE----- --=-Tgxy4ZHkrTcgNhFsCNTR-- ------------=_1727039702-1492650-0--