BUGS revision 41142
138494Sobrien# -*- text -*- 238494Sobrien 338494Sobrien LIST OF KNOWN BUGS IN AM-UTILS OR OPERATING SYSTEMS 438494Sobrien 538494Sobrien 638494Sobrien(1) mips-sgi-irix* 738494Sobrien 838494Sobrien[1A] known to have flakey NFS V.3 and TCP. Amd tends to hang or spin 938494Sobrieninfinitely after a few hours or days of use. Users must install recommended 1038494Sobrienpatches from vendor. Patches help, but not all the time. Otherwise avoid 1138494Sobrienusing NFS V.3 and TCP on these systems, by setting 1238494Sobrien 1338494Sobrien /defaults opts:=vers=2,proto=udp 1438494Sobrien 1538494Sobrien[1B] yp_all() leaks a file descriptor. Eventually amd runs out of file 1638494Sobriendescriptors and hangs. Am-utils circumvents this by using its own version 1738494Sobrienof yp_all which uses udp and iterats over NIS maps. The latter isn't as 1838494Sobrienreliable as yp_all() which uses TCP, but it is better than hanging. 1938494Sobrien 2038494Sobrien 2138494Sobrien(2) alpha-unknown-linux-gnu (RedHat Linux 4.2) 2238494Sobrien 2338494Sobrienhasmntopt(mnt, opt) can goes into an infinite loop if opt is any substring 2438494Sobrienof mnt->mnt_opts. Redhat 5.0 does not have this libc bug. Here is an 2538494Sobrienexample program: 2638494Sobrien 2738494Sobrien#include <stdio.h> 2838494Sobrien#include <mntent.h> 2938494Sobrienmain() 3038494Sobrien{ 3138494Sobrien struct mntent mnt; 3238494Sobrien char *cp; 3338494Sobrien mnt.mnt_opts = "intr,rw,port=1023,timeo=8,foo=br,retrans=110,indirect,map=/usr/local/AMD/etc/amd.proj,boo"; 3438494Sobrien cp = hasmntopt(&mnt, "ro"); 3538494Sobrien printf("cp = %s\n", cp); 3638494Sobrien exit(0); 3738494Sobrien} 3838494Sobrien 3938494Sobrien 4038494Sobrien(3) mips-dec-ultrix4.3 4138494Sobrien 4238494SobrienRainer Orth <ro@TechFak.Uni-Bielefeld.DE> reports 4338494Sobrien 4438494Sobrien[3A] At least the gcc 2.7.0 fixincludes-mangled <sys/utsname.h> needs a 4538494Sobrienforward declaration of struct utsname to avoid lots of gcc warnings: 4638494Sobrien 4738494SobrienRCS file: RCS/utsname.h,v 4838494Sobrienretrieving revision 1.1 4938494Sobriendiff -u -r1.1 utsname.h 5038494Sobrien--- utsname.h 1995/06/19 13:07:01 1.1 5138494Sobrien+++ utsname.h 1998/01/27 12:34:26 5238494Sobrien@@ -59,6 +59,7 @@ 5338494Sobrien #ifdef KERNEL 5438494Sobrien #include "../h/limits.h" 5538494Sobrien #else /* user mode */ 5638494Sobrien+struct utsname; 5738494Sobrien extern int uname _PARAMS((struct utsname *)); 5838494Sobrien #endif 5938494Sobrien #define __SYS_NMLN 32 6038494Sobrien 6138494Sobrien[3B] It autoconfigures and compiles cleanly, but currently hangs after a 6238494Sobriencouple of hours without leaving any traces in the syslog output. 6338494Sobrien 6438494Sobrien 6538494Sobrien(4) powerpc-ibm-aix4.2.1.0 6638494Sobrien 6738494Sobrien[4A] "Randall S. Winchester" <rsw@Glue.umd.edu> reports that for amd to 6838494Sobrienstart, you need to kill and restart rpc.mountd and possibly also make sure 6938494Sobrienthat nfsd is running. Normally these are not required. 7038494Sobrien 7138494Sobrien[4B] "Stefan Vogel" <vogel@physik.unizh.ch> reports that if your amq 7238494Sobrienexecutable dump core unexpectedly, then it may be a bug in gcc 2.7.x. 7338494SobrienUpgrade to gcc 2.8.x or use IBM's xlC compiler. 7441142Sobrien 7541142Sobrien 7641142Sobrien(5) *-linux-gnu (RedHat Linux 5.1) 7741142Sobrien 7841142SobrienThere's a UDP file descriptor leak in libnsl in RedHat Linux 5.1. This 7941142Sobrienlibrary part of glibc2. Am-utils currently declares redhat 5.1 systems as 8041142Sobrienhaving a "broken yp_all" and using an internal, slower, leak-free version. 8141142SobrienThe leak is known to the glibc maintainers and a fix from them is due soon, 8241142Sobrienbut it is not yet in the glibc-2.0.7-19 RPM. 8341142Sobrien 8441142Sobrien 8541142Sobrien(6) rs6000-ibm-aix4.1.x 8641142Sobrien 8741142SobrienA bug in libc results in an amq binary that doesn't work; amq -v dumps core 8841142Sobrienin xdr_string. There is no known fix (source code or vendor patch) at this 8941142Sobrientime. (Please let amd-dev know if you know of a fix.) 90