No amd mount points work at all in qa0322, using am-utils-6.0.4-7 and kernel-2.4.2-0.1.32. There are several errors emitted by the kernel after killing the (non-working) amd process: ... scratchy kernel: nfs_get_root: getattr error = 512 ... scratchy kernel: nfs_read_super: get root inode failed This repeats once for each mount point. Falling back to glibc-2.2.2-7 lets amd work as correctly as it did before.
I too am experiencing this problem. It might be the SunRPC implementation in glibc, or am-utils borkage revealed by glibc changes. Here's the information I have so far: The main (post-daemonize) amd process forks off an initialization helper process, then goes into a select() loop waiting for action. The helper process tries to do an NFS mount() from the pseudo-filesystem that the main process serves. The helper process does this by specifying in its mount() call the port number of a UDP port that the main process is listening on. However, the main process has not select()'d on the file descriptor that is bound to that UDP port, so things hang. The fdset it selects on is formed by taking th e svc_fdset provided by glibc and adding one of its fd's to that set.
(Comment continuation follows due to mozilla breakage mid-debugging). I can verify that things do work properly with glibc-2.2.2-7. ...It is also apparently not the svc_fdset that is at fault, since this remains the same between the two glibc versions. Sorry, somewhat of a red herring, although that doesn't explain why in neither of the two glibc's is amd select()'ing on the fd that the kernel will be talking to to mount from... Comparing the mount data that is passed to each mount() call (as indicated by the amd debug logs) seems to show basically the same thing being passed in each case. Sorry, this doesn't help provide much info on the actual problem, but perhaps the information of the location of the symptoms will be helpful: amd/nfs_start.c:run_rpc() is the select() loop in the main process. libamu/mountutils.c:mount_linux() is the function that does the actual mount() call in the child process. </disinformation>
I see the same problem. Extra info: after an attempt to start amd, which pretends that it is ok, attempts to mount NFS file systems block on 'down_failed()'. If I tried to attach strace to a blocked mount then strace blocked, without any output on 'wait4()'.
See http://sources.redhat.com/ml/libc-hacker/2001-03/msg00106.html glibc-2.2.2-9 has the sunrpc changed backed out anyway.
fixed with 2.2.2-9.