-linux and darwin tcp reconnect bug
authorIon Badulescu <ib42@cs.columbia.edu>
Sat, 25 Jan 2003 01:35:09 +0000 (01:35 +0000)
committerIon Badulescu <ib42@cs.columbia.edu>
Sat, 25 Jan 2003 01:35:09 +0000 (01:35 +0000)
-resync with trunk

BUGS

diff --git a/BUGS b/BUGS
index 618a69e0543078cfbd849984d20ad251df241e1c..42b50c57923716522f6b295902f62993d2d23e55 100644 (file)
--- 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