Bug 32749 - glibc-2.2.2-8 (qa0322) breaks am-utils!
glibc-2.2.2-8 (qa0322) breaks am-utils!
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
high Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-03-22 18:18 EST by Joshua Buysse
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-23 11:17:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joshua Buysse 2001-03-22 18:18:27 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.
Comment 1 Elliot Lee 2001-03-22 21:11:09 EST
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 2 Elliot Lee 2001-03-22 22:10:56 EST
(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.
Comment 3 Michal Jaegermann 2001-03-23 04:40:29 EST
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()'.

Comment 4 Jakub Jelinek 2001-03-23 11:17:26 EST
See http://sources.redhat.com/ml/libc-hacker/2001-03/msg00106.html
glibc-2.2.2-9 has the sunrpc changed backed out anyway.
Comment 5 Preston Brown 2001-03-26 16:55:57 EST
fixed with 2.2.2-9.

Note You need to log in before you can comment on or make changes to this bug.