From e855036c2d79198b643c359ac1f869df519bee6f Mon Sep 17 00:00:00 2001 From: Ion Badulescu Date: Sat, 25 Jan 2003 01:35:09 +0000 Subject: [PATCH] -linux and darwin tcp reconnect bug -resync with trunk --- BUGS | 36 ++++++++++++++++++++++++++---------- 1 file changed, 26 insertions(+), 10 deletions(-) diff --git a/BUGS b/BUGS index 618a69e..42b50c5 100644 --- a/BUGS +++ b/BUGS @@ -33,7 +33,7 @@ CC='cc -64' instead to get the desired ABI and ISA. (2) alpha-unknown-linux-gnu (RedHat Linux 4.2) -hasmntopt(mnt, opt) can goes into an infinite loop if opt is any substring +hasmntopt(mnt, opt) can go into an infinite loop if opt is any substring of mnt->mnt_opts. Redhat 5.0 does not have this libc bug. Here is an example program: @@ -109,7 +109,7 @@ Upgrade to gcc 2.8.x or use IBM's xlC compiler. in strlen inside strdup inside svc_register(). -(5) *-linux-gnu (RedHat Linux 5.1) +(5) *-linux-rh51 (RedHat Linux 5.1) There's a UDP file descriptor leak in libnsl in RedHat Linux 5.1. This library part of glibc2. Am-utils currently declares redhat 5.1 systems as @@ -139,19 +139,19 @@ plock on aix-4.3: set it to plock=no in amd.conf (which is the default if you do nothing). -(8) *-linux-gnu (systems using glibc 2.1, such as RedHat-6.1) +(8) *-linux (systems using glibc 2.1, such as RedHat-6.x) -There's a UDP file descriptor leak in the nis routines in glibc, especially +There's a UDP file descriptor leak in the NIS routines in glibc, especially those that do yp_bind. Until this is bug fixed, do not set nis_domain in amd.conf, but let the system pick up the default domain name as set by your system. That would avoid using the buggy yp_bind routines in libc. -(9) *-linux-gnu (SuSE systems using unfsd) +(9) *-linux (SuSE systems using unfsd) -The user-level nfsd (2.2beta44) on SuSE Linux systems (and possibly others) -dies with a SEGV when amd tries to contact it for access to a volume that -does not exist, or one for which there is no permission to mount. +The user-level nfsd (2.2beta44) on older SuSE Linux systems (and possibly +others) dies with a SEGV when amd tries to contact it for access to a volume +that does not exist, or one for which there is no permission to mount. (10) *-*-hpux11 @@ -160,13 +160,14 @@ If you're using NFSv3, you must install HP patches PHNE_20344 and PHNE_20371. If you don't, and you try to use amd with NFSv3 over TCP, your kernel will panic. + (11) *-linux* (any system using a 2.2.18+ kernel) The Linux kernels don't support Amd's direct mounts very well, leading to erratic behavior: shares that don't get remounted after the first timeout, inability to restart Amd because its mount points cannot be unmounted, etc. There are some kernel patches on the am-utils Web site, which solve -these problems. +these problems. See http://www.am-utils.org/patches/. UPDATE: kernels 2.4.10 and later completely disallow the direct mount hack, so direct mounts are simply not possible on those Linux kernels. @@ -178,5 +179,20 @@ to use /bin/ksh instead. The buildall script will do it for you; if for some reason you need to run configure directly, run it using 'ksh configure' instead of just 'configure'. +13) *-linux and *-darwin6.0 + +Certain linux kernels (2.4.18+ are fine, 2.4.10- are probably bad, those in +between have not been tested) have a bug which causes them to reconnect +broken NFS/TCP connections using unprivileged ports (greater than 1024), +unlike the initial connections which do originate from privileged +ports. This can upset quite a few NFS servers and causes accesses to the +mounted shares to fail with "Operation not permitted" (EPERM). + +The darwin (MacOS X) kernel defaults to using unprivileged ports, but that +can be changed by setting the resvport mount flag (which amd sets by +default). Nonetheless, if a TCP connection breaks, under certain unclear +circumstances the kernel might "forget" about that flag and start using +unprivileged ports, causing the same EPERM error above. + -Erez. +Erez & Ion -- 2.43.0