Red Hat Bugzilla – Bug 32749
glibc-2.2.2-8 (qa0322) breaks am-utils!
Last modified: 2016-11-24 10:11:51 EST
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
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
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.
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()'.
glibc-2.2.2-9 has the sunrpc changed backed out anyway.
fixed with 2.2.2-9.