BUGS revision 174294
138494Sobrien LIST OF KNOWN BUGS IN AM-UTILS OR OPERATING SYSTEMS 238494Sobrien 3174294SobrienNote: report am-utils bugs via Bugzilla to https://bugzilla.am-utils.org/ or 4174294Sobrienby email to the am-utils@am-utils.org mailing list. 538494Sobrien 6174294Sobrien 738494Sobrien(1) mips-sgi-irix* 838494Sobrien 952894Sobrien[1A] known to have flaky NFS V.3 and TCP. Amd tends to hang or spin 1038494Sobrieninfinitely after a few hours or days of use. Users must install recommended 1138494Sobrienpatches from vendor. Patches help, but not all the time. Otherwise avoid 1238494Sobrienusing NFS V.3 and TCP on these systems, by setting 1338494Sobrien 1438494Sobrien /defaults opts:=vers=2,proto=udp 1538494Sobrien 1638494Sobrien[1B] yp_all() leaks a file descriptor. Eventually amd runs out of file 1738494Sobriendescriptors and hangs. Am-utils circumvents this by using its own version 1852894Sobrienof yp_all which uses udp and iterates over NIS maps. The latter isn't as 1938494Sobrienreliable as yp_all() which uses TCP, but it is better than hanging. 2038494Sobrien 2151591Sobrien(I have some reports that older version of hpux-9, with older libc, also 2251591Sobrienleak file descriptors.) 2338494Sobrien 24119679Smbr[1C] SGI's MIPSpro C compiler on IRIX 6 has the unfortunate habit of 25119679Smbrcreating code specificially for the machine it runs on. The ABI and ISA 26119679Smbrused depend very much on the OS version and compiler release used. This 27119679Smbrmeans that the resulting amd binary won't run on machines different from 28119679Smbrthe build host, particularly older ones. Older versions of am-utils 29119679Smbrenforced the O32 ABI when compiling with cc to work around this, but this 30119679SmbrABI is deprecated in favor of the N32 ABI now, so we use -n32 -mips3 to 31119679Smbrensure that the binaries run on every host capable of running IRIX 6 at 32119679Smbrall. If this is not appropriate for you, configure with something like 33119679SmbrCC='cc -64' instead to get the desired ABI and ISA. 3451591Sobrien 3538494Sobrien(2) alpha-unknown-linux-gnu (RedHat Linux 4.2) 3638494Sobrien 37119679Smbrhasmntopt(mnt, opt) can go into an infinite loop if opt is any substring 3838494Sobrienof mnt->mnt_opts. Redhat 5.0 does not have this libc bug. Here is an 3938494Sobrienexample program: 4038494Sobrien 4138494Sobrien#include <stdio.h> 4238494Sobrien#include <mntent.h> 4338494Sobrienmain() 4438494Sobrien{ 4538494Sobrien struct mntent mnt; 4638494Sobrien char *cp; 4738494Sobrien mnt.mnt_opts = "intr,rw,port=1023,timeo=8,foo=br,retrans=110,indirect,map=/usr/local/AMD/etc/amd.proj,boo"; 4838494Sobrien cp = hasmntopt(&mnt, "ro"); 4938494Sobrien printf("cp = %s\n", cp); 5038494Sobrien exit(0); 5138494Sobrien} 5238494Sobrien 5351292SobrienIt is possible that sufficiently newer version of libc for RH4.2 fix this 5451292Sobrienproblem. 5538494Sobrien 5651292Sobrien 5738494Sobrien(3) mips-dec-ultrix4.3 5838494Sobrien 5938494SobrienRainer Orth <ro@TechFak.Uni-Bielefeld.DE> reports 6038494Sobrien 6151292Sobrien[3A] One needs the Kernel Config Files (UDTBIN430) subset installed to 6251292Sobriencompile am-utils, otherwise essential header files (net/if.h, net/route.h, 6351292Sobrienrpcsvc/mount.h, rpcsvc/yp_prot.h, rpcsvc/ypclnt.h, sys/proc.h) are 6451292Sobrienmissing. 6551292Sobrien 6651292Sobrien[3B] It's probably impossible to build am-utils with DEC C on Ultrix V4.3. 6751292SobrienThis compiler is pseudo-ANSI only. Maybe the new ANSI C compiler in V4.3A 6851292Sobrienand beyond will do. I successfully used gcc 2.8.1. 6951292Sobrien 7051292Sobrien[3C] You need to build against a recent libhesiod (I used 3.0.2) and 7151292Sobrienlibresolv/lib44bsd (I used BIND 4.9.5-P1). The resolver routines in 7251292Sobrienlibc seem to cause random memory corruption. It is necessary to specify 7351292SobrienLIBS=-l44bsd. lib44bsd is a helper library of libresolv used to supply 7451292Sobrienfunctions like strdup which are missing on the host system. This isn't 7551292Sobriencurrently autoconfiscated. 7651292Sobrien 7751292Sobrien[3D] You need to configure with CONFIG_SHELL=/bin/sh5 /bin/sh5 buildall; 7851292Sobrien/bin/sh cannot handle the shell functions used in buildall and is both 7951292Sobrienbuggy and slow. 8051292Sobrien 8151292Sobrien[3E] At least the gcc 2.7.0 fixincludes-mangled <sys/utsname.h> needs a 8238494Sobrienforward declaration of struct utsname to avoid lots of gcc warnings: 8338494Sobrien 8438494SobrienRCS file: RCS/utsname.h,v 8538494Sobrienretrieving revision 1.1 8638494Sobriendiff -u -r1.1 utsname.h 8738494Sobrien--- utsname.h 1995/06/19 13:07:01 1.1 8838494Sobrien+++ utsname.h 1998/01/27 12:34:26 8938494Sobrien@@ -59,6 +59,7 @@ 9038494Sobrien #ifdef KERNEL 9138494Sobrien #include "../h/limits.h" 9238494Sobrien #else /* user mode */ 9338494Sobrien+struct utsname; 9438494Sobrien extern int uname _PARAMS((struct utsname *)); 9538494Sobrien #endif 9638494Sobrien #define __SYS_NMLN 32 9738494Sobrien 9838494Sobrien 9938494Sobrien(4) powerpc-ibm-aix4.2.1.0 10038494Sobrien 10138494Sobrien[4A] "Randall S. Winchester" <rsw@Glue.umd.edu> reports that for amd to 10238494Sobrienstart, you need to kill and restart rpc.mountd and possibly also make sure 10338494Sobrienthat nfsd is running. Normally these are not required. 10438494Sobrien 10538494Sobrien[4B] "Stefan Vogel" <vogel@physik.unizh.ch> reports that if your amq 10638494Sobrienexecutable dump core unexpectedly, then it may be a bug in gcc 2.7.x. 10738494SobrienUpgrade to gcc 2.8.x or use IBM's xlC compiler. 10841142Sobrien 10942629Sobrien[C] Do not link amd with libnsl. It is buggy and causes amd to core dump 11042629Sobrienin strlen inside strdup inside svc_register(). 11141142Sobrien 11242629Sobrien 113119679Smbr(5) *-linux-rh51 (RedHat Linux 5.1) 11441142Sobrien 11541142SobrienThere's a UDP file descriptor leak in libnsl in RedHat Linux 5.1. This 11641142Sobrienlibrary part of glibc2. Am-utils currently declares redhat 5.1 systems as 11741142Sobrienhaving a "broken yp_all" and using an internal, slower, leak-free version. 11841142SobrienThe leak is known to the glibc maintainers and a fix from them is due soon, 11941142Sobrienbut it is not yet in the glibc-2.0.7-19 RPM. 12041142Sobrien 12141142Sobrien 12241142Sobrien(6) rs6000-ibm-aix4.1.x 12341142Sobrien 12441142SobrienA bug in libc results in an amq binary that doesn't work; amq -v dumps core 12541142Sobrienin xdr_string. There is no known fix (source code or vendor patch) at this 126131702Smbrtime. (Please let am-utils@am-utils.org know if you know of a fix.) 12752894Sobrien 12852894Sobrien 12952894Sobrien(7) *-aix4.3.2.0 13052894Sobrien 13182794SobrienThe plock() function will pre-reserve all of the memory up to the maximum 13282794Sobrienlisted in the ulimit. If the ulimit is infinite, plock() will try to take 13382794Sobrienall of the system's memory, and fail with ENOMEM (Not Enough Space). 13482794SobrienNormally ulimit may be set to a few gigs of max memory usage, but even that 13582794Sobrienis too much; Amd doesn't need more than a few megs of resident memory size 13682794Sobrien(depending on the particular usage, number of maps, etc.) Solution: lower 13782794Sobrienyour ulimit before starting amd. This can be done inside the ctl-amd 13882794Sobrienscript, but be careful not to limit it too low. Alternatively, don't use 13982794Sobrienplock on aix-4.3: set it to plock=no in amd.conf (which is the default if 14082794Sobrienyou do nothing). 14152894Sobrien 14282794Sobrien 143119679Smbr(8) *-linux (systems using glibc 2.1, such as RedHat-6.x) 14482794Sobrien 145119679SmbrThere's a UDP file descriptor leak in the NIS routines in glibc, especially 14682794Sobrienthose that do yp_bind. Until this is bug fixed, do not set nis_domain in 14782794Sobrienamd.conf, but let the system pick up the default domain name as set by your 14882794Sobriensystem. That would avoid using the buggy yp_bind routines in libc. 14982794Sobrien 15082794Sobrien 151119679Smbr(9) *-linux (SuSE systems using unfsd) 15282794Sobrien 153119679SmbrThe user-level nfsd (2.2beta44) on older SuSE Linux systems (and possibly 154119679Smbrothers) dies with a SEGV when amd tries to contact it for access to a volume 155119679Smbrthat does not exist, or one for which there is no permission to mount. 15682794Sobrien 15782794Sobrien 15882794Sobrien(10) *-*-hpux11 15982794Sobrien 16082794SobrienIf you're using NFSv3, you must install HP patches PHNE_20344 and 16182794SobrienPHNE_20371. If you don't, and you try to use amd with NFSv3 over TCP, your 16282794Sobrienkernel will panic. 16382794Sobrien 164119679Smbr 16582794Sobrien(11) *-linux* (any system using a 2.2.18+ kernel) 16682794Sobrien 16782794SobrienThe Linux kernels don't support Amd's direct mounts very well, leading to 16882794Sobrienerratic behavior: shares that don't get remounted after the first timeout, 169174294Sobrieninability to restart Amd because its mount points cannot be unmounted, etc. 170174294SobrienThere are some kernel patches on the am-utils Web site, which solve these 171174294Sobrienproblems. See http://www.am-utils.org/patches/. 17282794Sobrien 173174294SobrienLater 2.4.x kernels completely disallow the hack amd was using for direct 174174294Sobrienmounts, so another solution will have to be found. 17582794Sobrien 176174294SobrienNote: the above is for the old-style amd mount_type = nfs. The autofs mounts 177174294Sobriendon't support direct mounts at all (due to lack of kernel support). 178174294Sobrien 179119679Smbr(12) *-aix5.1.0.0 and *-hpux9* 180119679Smbr 181119679Smbr/bin/sh is broken and fails to run the configure script properly. You need 182119679Smbrto use /bin/ksh instead. The buildall script will do it for you; if for some 183119679Smbrreason you need to run configure directly, run it using 'ksh configure' 184119679Smbrinstead of just 'configure'. 185119679Smbr 186174294Sobrien[12A] *-aix5.2.* 187119679Smbr 188119679SmbrApparently there is an NFS client side bug in vmount() which causes amd to 189119679Smbrhang when it starts (and tries to NFS-mount itself). According to IBM 190119679Smbrengineers, this has to do with partial support code for IPv6: the NFS kernel 191119679Smbrcode doesn't appear to recognize the sin_family of the amd vmount(), 192174294Sobrienalthough amd does the right thing. The bug doesn't appear to be in 5.1 or 193174294Sobrien4.3.3. A fix from IBM is available, APAR number IY41417. 194119679Smbr 195174294SobrienA binary built on 4.3.3 will not work on 5.2, because the kernel ABIs have 196174294Sobrienchanged. 197174294Sobrien 198174294Sobrien[12C] *-aix* 199174294Sobrien 200174294SobrienIt is important that you install bos.net.nfs.adt before configuring and 201174294Sobrienbuilding am-utils. If you don't, you will get compile-time or 202174294Sobrienconfigure-time errors, especially when configure tries to find AIX's 203174294Sobriendefinition of struct nfs_args. 204174294Sobrien 205119679Smbr(13) *-linux and *-darwin6.0 206119679Smbr 207119679SmbrCertain linux kernels (2.4.18+ are fine, 2.4.10- are probably bad, those in 208119679Smbrbetween have not been tested) have a bug which causes them to reconnect 209119679Smbrbroken NFS/TCP connections using unprivileged ports (greater than 1024), 210119679Smbrunlike the initial connections which do originate from privileged 211119679Smbrports. This can upset quite a few NFS servers and causes accesses to the 212119679Smbrmounted shares to fail with "Operation not permitted" (EPERM). 213119679Smbr 214119679SmbrThe darwin (MacOS X) kernel defaults to using unprivileged ports, but that 215119679Smbrcan be changed by setting the resvport mount flag (which amd sets by 216119679Smbrdefault). Nonetheless, if a TCP connection breaks, under certain unclear 217119679Smbrcircumstances the kernel might "forget" about that flag and start using 218119679Smbrunprivileged ports, causing the same EPERM error above. 219119679Smbr 220174294Sobrien(14) Solaris 221119679Smbr 222174294SobrienThe line "%option" in *.l files may cause Solaris /usr/ccs/bin/lex to abort 223174294Sobrienwith the error "missing translation value." This is a bug in Solaris lex. 224119679Smbr 225174294SobrienMoreover, both Solaris yacc and lex produce code that does not pass strict 226174294Sobriencompilation such as "gcc -Wall -Werror". 227174294Sobrien 228174294SobrienUse GNU Flex and Bison instead. You can download ready-made binaries from 229174294Sobrienwww.sunfreeware.com. Note, however, that sometimes the binaries on 230174294Sobriensunfreeware.com don't seem to work, often because they are built against an 231174294Sobrienolder revision of Solaris or build tools. In that case, build a fresh 232174294Sobrienversion of GNU flex and/or bison from the latest stable sources. See 233174294Sobrienhttp://www.gnu.org/software/flex/ and http://www.gnu.org/software/bison/. 234174294Sobrien 235174294Sobrien(15) Solaris 8 + patch 10899[34]-xx (18 <= xx < 25) or patch 11260[56]-xx 236174294Sobrien 237174294SobrienWith this patch, Sun updated the autofs kernel module and automountd 238174294Sobrienuserspace daemon from version 3 to version 4. They also updated the 239174294Sobrien/usr/include/rpcsvc/autofs_prot.x file, but forgot to regenerate the 240174294Sobrienautofs_prot.h file. Thus, when amd is compiled, it uses the old header and 241174294Sobrienthinks it should use autofs version 3, when in fact the kernel now supports 242174294Sobrien(and expects) only version 4. 243174294Sobrien 244174294SobrienThe workaround is to run 'rpcgen -C -h /usr/include/rpcsvc/autofs_prot.x > 245174294Sobrien/usr/include/rpcsvc/autofs_prot.h' and completely reconfigure and rebuild 246174294Sobrienam-utils (removing config.cache before running configure). 247174294Sobrien 248174294SobrienThe problem is fixed in patch revisions 10899[34]-25 and up. 249174294Sobrien 250174294Sobrien 251174294Sobrien(16) Linux kernel 2.4+ and lofs mounts 252174294Sobrien 253174294SobrienLofs mounts are not supported by the linux kernel, at all, but since 2.4.0 254174294Sobrienthe kernel supports a similar type of mount called a bind mount. Its 255174294Sobriensemantics are closer to those of a hardlink than to those of lofs, and one 256174294Sobrienof the results is that bind mounts ignore any mount options paseed to them. 257174294Sobrien 258174294SobrienAmd uses bind mounts internally to emulate lofs mounts, which means that 259174294Sobrienlofs mounts on linux will effectively ignore their mount parameters and 260174294Sobrieninherit whatever options the original filesystem mounted upon had. 261174294Sobrien 262174294Sobrien 263174294Sobrien(17) autoconf 2.57 264174294Sobrien 265174294SobrienIf you see configure warnings of the following kind: 266174294Sobrien 267174294Sobrienconfigure: WARNING: sys/proc.h: present but cannot be compiled 268174294Sobrienconfigure: WARNING: sys/proc.h: check for missing prerequisite headers? 269174294Sobrienconfigure: WARNING: sys/proc.h: proceeding with the preprocessor's result 270174294Sobrienconfigure: WARNING: ## ------------------------------------ ## 271174294Sobrienconfigure: WARNING: ## Report this to bug-autoconf@gnu.org. ## 272174294Sobrienconfigure: WARNING: ## ------------------------------------ ## 273174294Sobrien 274174294Sobrienplease ignore them. They are not real errors, and neither 275174294Sobrienbug-autoconf@gnu.org nor the am-utils maintainers are interested in hearing 276174294Sobrienabout them. Autoconf simply tries to do more than we need and attempts to 277174294Sobriencompile each header in isolation, which fails for many system headers. 278174294SobrienThat's ok, because we only need to know if a header file exists -- we know 279174294Sobrienhow to use it properly ourselves. 280174294Sobrien 281174294SobrienWhile autoconf does offer a way to specify other files to be included with 282174294Sobrienthe tested header, in order to avoid these warnings, using it would enlarge 283174294Sobrienthe resulting configure script by an order of magnitude, and for no real 284174294Sobriengain. Configure is big enough as it is, we don't need any more useless 285174294Sobrienbaggage in it. 286174294Sobrien 287174294Sobrien(18) NetBSD 2.0.2, FreeBSD 5.4, OpenBSD 3.7, and quite possibly most other 288174294Sobrien BSDs and other OSs (as of September 2005) 289174294Sobrien 290174294SobrienSome BSD kernels don't have a way to turn off the NFS attribute cache. They 291174294Sobriendon't have a 'noac' mount flag, and setting various cache timeout fields in 292174294Sobrienstruct nfs_args doesn't turn off the attribute cache; instead, it sets the 293174294Sobrienattribute cache timeout to some internal hard-coded default (usually 294174294Sobrienanywhere from 5-30 seconds). If Amd cannot turn off the NFS attribute 295174294Sobriencache, under heavy Amd usage, users could get ESTALE errors from automounted 296174294Sobriensymlinks, or find that those symlinks point to the wrong place. One 297174294Sobrienworkaround which would minimize this effect is to set auto_attrcache=1 in 298174294Sobrienyour amd.conf, but it doesn't eliminate the problem! The best solutions are 299174294Sobrien(1) to use Amd in Autofs mode, if it's supported in your OS, and (2) talk to 300174294Sobrienyour OS vendor to support a true "noac" flag. See README.attrcache for more 301174294Sobriendetails. 302174294Sobrien 303174294SobrienErez & the am-utils team. 304