BUGS revision 119679
138494Sobrien LIST OF KNOWN BUGS IN AM-UTILS OR OPERATING SYSTEMS 238494Sobrien 338494Sobrien 438494Sobrien(1) mips-sgi-irix* 538494Sobrien 652894Sobrien[1A] known to have flaky NFS V.3 and TCP. Amd tends to hang or spin 738494Sobrieninfinitely after a few hours or days of use. Users must install recommended 838494Sobrienpatches from vendor. Patches help, but not all the time. Otherwise avoid 938494Sobrienusing NFS V.3 and TCP on these systems, by setting 1038494Sobrien 1138494Sobrien /defaults opts:=vers=2,proto=udp 1238494Sobrien 1338494Sobrien[1B] yp_all() leaks a file descriptor. Eventually amd runs out of file 1438494Sobriendescriptors and hangs. Am-utils circumvents this by using its own version 1552894Sobrienof yp_all which uses udp and iterates over NIS maps. The latter isn't as 1638494Sobrienreliable as yp_all() which uses TCP, but it is better than hanging. 1738494Sobrien 1851591Sobrien(I have some reports that older version of hpux-9, with older libc, also 1951591Sobrienleak file descriptors.) 2038494Sobrien 21119679Smbr[1C] SGI's MIPSpro C compiler on IRIX 6 has the unfortunate habit of 22119679Smbrcreating code specificially for the machine it runs on. The ABI and ISA 23119679Smbrused depend very much on the OS version and compiler release used. This 24119679Smbrmeans that the resulting amd binary won't run on machines different from 25119679Smbrthe build host, particularly older ones. Older versions of am-utils 26119679Smbrenforced the O32 ABI when compiling with cc to work around this, but this 27119679SmbrABI is deprecated in favor of the N32 ABI now, so we use -n32 -mips3 to 28119679Smbrensure that the binaries run on every host capable of running IRIX 6 at 29119679Smbrall. If this is not appropriate for you, configure with something like 30119679SmbrCC='cc -64' instead to get the desired ABI and ISA. 3151591Sobrien 3238494Sobrien(2) alpha-unknown-linux-gnu (RedHat Linux 4.2) 3338494Sobrien 34119679Smbrhasmntopt(mnt, opt) can go into an infinite loop if opt is any substring 3538494Sobrienof mnt->mnt_opts. Redhat 5.0 does not have this libc bug. Here is an 3638494Sobrienexample program: 3738494Sobrien 3838494Sobrien#include <stdio.h> 3938494Sobrien#include <mntent.h> 4038494Sobrienmain() 4138494Sobrien{ 4238494Sobrien struct mntent mnt; 4338494Sobrien char *cp; 4438494Sobrien mnt.mnt_opts = "intr,rw,port=1023,timeo=8,foo=br,retrans=110,indirect,map=/usr/local/AMD/etc/amd.proj,boo"; 4538494Sobrien cp = hasmntopt(&mnt, "ro"); 4638494Sobrien printf("cp = %s\n", cp); 4738494Sobrien exit(0); 4838494Sobrien} 4938494Sobrien 5051292SobrienIt is possible that sufficiently newer version of libc for RH4.2 fix this 5151292Sobrienproblem. 5238494Sobrien 5351292Sobrien 5438494Sobrien(3) mips-dec-ultrix4.3 5538494Sobrien 5638494SobrienRainer Orth <ro@TechFak.Uni-Bielefeld.DE> reports 5738494Sobrien 5851292Sobrien[3A] One needs the Kernel Config Files (UDTBIN430) subset installed to 5951292Sobriencompile am-utils, otherwise essential header files (net/if.h, net/route.h, 6051292Sobrienrpcsvc/mount.h, rpcsvc/yp_prot.h, rpcsvc/ypclnt.h, sys/proc.h) are 6151292Sobrienmissing. 6251292Sobrien 6351292Sobrien[3B] It's probably impossible to build am-utils with DEC C on Ultrix V4.3. 6451292SobrienThis compiler is pseudo-ANSI only. Maybe the new ANSI C compiler in V4.3A 6551292Sobrienand beyond will do. I successfully used gcc 2.8.1. 6651292Sobrien 6751292Sobrien[3C] You need to build against a recent libhesiod (I used 3.0.2) and 6851292Sobrienlibresolv/lib44bsd (I used BIND 4.9.5-P1). The resolver routines in 6951292Sobrienlibc seem to cause random memory corruption. It is necessary to specify 7051292SobrienLIBS=-l44bsd. lib44bsd is a helper library of libresolv used to supply 7151292Sobrienfunctions like strdup which are missing on the host system. This isn't 7251292Sobriencurrently autoconfiscated. 7351292Sobrien 7451292Sobrien[3D] You need to configure with CONFIG_SHELL=/bin/sh5 /bin/sh5 buildall; 7551292Sobrien/bin/sh cannot handle the shell functions used in buildall and is both 7651292Sobrienbuggy and slow. 7751292Sobrien 7851292Sobrien[3E] At least the gcc 2.7.0 fixincludes-mangled <sys/utsname.h> needs a 7938494Sobrienforward declaration of struct utsname to avoid lots of gcc warnings: 8038494Sobrien 8138494SobrienRCS file: RCS/utsname.h,v 8238494Sobrienretrieving revision 1.1 8338494Sobriendiff -u -r1.1 utsname.h 8438494Sobrien--- utsname.h 1995/06/19 13:07:01 1.1 8538494Sobrien+++ utsname.h 1998/01/27 12:34:26 8638494Sobrien@@ -59,6 +59,7 @@ 8738494Sobrien #ifdef KERNEL 8838494Sobrien #include "../h/limits.h" 8938494Sobrien #else /* user mode */ 9038494Sobrien+struct utsname; 9138494Sobrien extern int uname _PARAMS((struct utsname *)); 9238494Sobrien #endif 9338494Sobrien #define __SYS_NMLN 32 9438494Sobrien 9538494Sobrien 9638494Sobrien(4) powerpc-ibm-aix4.2.1.0 9738494Sobrien 9838494Sobrien[4A] "Randall S. Winchester" <rsw@Glue.umd.edu> reports that for amd to 9938494Sobrienstart, you need to kill and restart rpc.mountd and possibly also make sure 10038494Sobrienthat nfsd is running. Normally these are not required. 10138494Sobrien 10238494Sobrien[4B] "Stefan Vogel" <vogel@physik.unizh.ch> reports that if your amq 10338494Sobrienexecutable dump core unexpectedly, then it may be a bug in gcc 2.7.x. 10438494SobrienUpgrade to gcc 2.8.x or use IBM's xlC compiler. 10541142Sobrien 10642629Sobrien[C] Do not link amd with libnsl. It is buggy and causes amd to core dump 10742629Sobrienin strlen inside strdup inside svc_register(). 10841142Sobrien 10942629Sobrien 110119679Smbr(5) *-linux-rh51 (RedHat Linux 5.1) 11141142Sobrien 11241142SobrienThere's a UDP file descriptor leak in libnsl in RedHat Linux 5.1. This 11341142Sobrienlibrary part of glibc2. Am-utils currently declares redhat 5.1 systems as 11441142Sobrienhaving a "broken yp_all" and using an internal, slower, leak-free version. 11541142SobrienThe leak is known to the glibc maintainers and a fix from them is due soon, 11641142Sobrienbut it is not yet in the glibc-2.0.7-19 RPM. 11741142Sobrien 11841142Sobrien 11941142Sobrien(6) rs6000-ibm-aix4.1.x 12041142Sobrien 12141142SobrienA bug in libc results in an amq binary that doesn't work; amq -v dumps core 12241142Sobrienin xdr_string. There is no known fix (source code or vendor patch) at this 12341142Sobrientime. (Please let amd-dev know if you know of a fix.) 12452894Sobrien 12552894Sobrien 12652894Sobrien(7) *-aix4.3.2.0 12752894Sobrien 12882794SobrienThe plock() function will pre-reserve all of the memory up to the maximum 12982794Sobrienlisted in the ulimit. If the ulimit is infinite, plock() will try to take 13082794Sobrienall of the system's memory, and fail with ENOMEM (Not Enough Space). 13182794SobrienNormally ulimit may be set to a few gigs of max memory usage, but even that 13282794Sobrienis too much; Amd doesn't need more than a few megs of resident memory size 13382794Sobrien(depending on the particular usage, number of maps, etc.) Solution: lower 13482794Sobrienyour ulimit before starting amd. This can be done inside the ctl-amd 13582794Sobrienscript, but be careful not to limit it too low. Alternatively, don't use 13682794Sobrienplock on aix-4.3: set it to plock=no in amd.conf (which is the default if 13782794Sobrienyou do nothing). 13852894Sobrien 13982794Sobrien 140119679Smbr(8) *-linux (systems using glibc 2.1, such as RedHat-6.x) 14182794Sobrien 142119679SmbrThere's a UDP file descriptor leak in the NIS routines in glibc, especially 14382794Sobrienthose that do yp_bind. Until this is bug fixed, do not set nis_domain in 14482794Sobrienamd.conf, but let the system pick up the default domain name as set by your 14582794Sobriensystem. That would avoid using the buggy yp_bind routines in libc. 14682794Sobrien 14782794Sobrien 148119679Smbr(9) *-linux (SuSE systems using unfsd) 14982794Sobrien 150119679SmbrThe user-level nfsd (2.2beta44) on older SuSE Linux systems (and possibly 151119679Smbrothers) dies with a SEGV when amd tries to contact it for access to a volume 152119679Smbrthat does not exist, or one for which there is no permission to mount. 15382794Sobrien 15482794Sobrien 15582794Sobrien(10) *-*-hpux11 15682794Sobrien 15782794SobrienIf you're using NFSv3, you must install HP patches PHNE_20344 and 15882794SobrienPHNE_20371. If you don't, and you try to use amd with NFSv3 over TCP, your 15982794Sobrienkernel will panic. 16082794Sobrien 161119679Smbr 16282794Sobrien(11) *-linux* (any system using a 2.2.18+ kernel) 16382794Sobrien 16482794SobrienThe Linux kernels don't support Amd's direct mounts very well, leading to 16582794Sobrienerratic behavior: shares that don't get remounted after the first timeout, 16682794Sobrieninability to restart Amd because its mount points cannot be unmounted, 16782794Sobrienetc. There are some kernel patches on the am-utils Web site, which solve 168119679Smbrthese problems. See http://www.am-utils.org/patches/. 16982794Sobrien 170119679SmbrUPDATE: kernels 2.4.10 and later completely disallow the direct mount hack, 171119679Smbrso direct mounts are simply not possible on those Linux kernels. 17282794Sobrien 173119679Smbr(12) *-aix5.1.0.0 and *-hpux9* 174119679Smbr 175119679Smbr/bin/sh is broken and fails to run the configure script properly. You need 176119679Smbrto use /bin/ksh instead. The buildall script will do it for you; if for some 177119679Smbrreason you need to run configure directly, run it using 'ksh configure' 178119679Smbrinstead of just 'configure'. 179119679Smbr 180119679Smbr[12A] *-aix5.1.* 181119679Smbr 182119679SmbrApparently there is an NFS client side bug in vmount() which causes amd to 183119679Smbrhang when it starts (and tries to NFS-mount itself). According to IBM 184119679Smbrengineers, this has to do with partial support code for IPv6: the NFS kernel 185119679Smbrcode doesn't appear to recognize the sin_family of the amd vmount(), 186119679Smbralthough amd does the right thing. The bug appears to have been fixed in 187119679SmbrAIX 5.2. No known fix/patch is available for AIX 5.1 as of now (1/25/2003). 188119679Smbr 189119679Smbr(13) *-linux and *-darwin6.0 190119679Smbr 191119679SmbrCertain linux kernels (2.4.18+ are fine, 2.4.10- are probably bad, those in 192119679Smbrbetween have not been tested) have a bug which causes them to reconnect 193119679Smbrbroken NFS/TCP connections using unprivileged ports (greater than 1024), 194119679Smbrunlike the initial connections which do originate from privileged 195119679Smbrports. This can upset quite a few NFS servers and causes accesses to the 196119679Smbrmounted shares to fail with "Operation not permitted" (EPERM). 197119679Smbr 198119679SmbrThe darwin (MacOS X) kernel defaults to using unprivileged ports, but that 199119679Smbrcan be changed by setting the resvport mount flag (which amd sets by 200119679Smbrdefault). Nonetheless, if a TCP connection breaks, under certain unclear 201119679Smbrcircumstances the kernel might "forget" about that flag and start using 202119679Smbrunprivileged ports, causing the same EPERM error above. 203119679Smbr 204119679Smbr 205119679SmbrErez & Ion. 206119679Smbr 207