Bug 53251 - am-utils stopped to work
am-utils stopped to work
Product: Red Hat Linux
Classification: Retired
Component: am-utils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-09-05 11:55 EDT by Michal Jaegermann
Modified: 2007-04-18 12:36 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-09-15 21:33:24 EDT
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 Michal Jaegermann 2001-09-05 11:55:08 EDT
Description of Problem:

'amd' daemon seems to be quite broken in RC2.

The same machine, with the same configuration, can be booted either
into RH 7.1 based system or into a test installation of RC2.  Network
works and an explicit mount via NFS from another host 'zeno' works
fine in both cases. 'amd' is running and 'mount' shows its presence
in both cases.

This is a fragment of 'strace' which shows effects of 'ls /net/zeno'
from 7.1:

lstat64("/net/zeno", {st_mode=S_IFLNK|0777, st_size=21, ...}) = 0
readlink("/net/zeno", "/.automount/zeno/root", 4096) = 21
stat64("/.automount/zeno/root", {st_mode=S_IFDIR|0755, st_size=1024, ...})
= 0
open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a
open("/.automount/zeno/root", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)
= 3
fstat64(3, {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC)   = 0
getdents64(3, /* 31 entries */, 4096) = 816
brk(0x8059000)                    = 0x8059000
getdents64(3, /* 0 entries */, 4096) = 0
close(3)                          = 0

and so on, followed for a listing of a directory on my screen.

These are effects of the same command when RC2 is used:

lstat64("/net/zeno", 0x8055c7c)   = -1 ENOENT (No such file or directory)

and an error message is printed.

Unfortunately 'autofs' is still not a suitable replacement for 'amd';
at least not in all situations.

Comment 1 Glen Foster 2001-09-05 14:34:22 EDT
If it's as broken as Michal reports, this is a definite errata candidate.
Comment 2 Nalin Dahyabhai 2001-09-06 10:26:11 EDT
My first guess is that this has something to do with the kernel/automounter
Comment 3 Michal Jaegermann 2001-09-06 10:39:15 EDT
If you think about autofs interference then I tried with this on and off,
just in case, and this did not make any difference.
Comment 4 Michal Jaegermann 2001-09-06 11:19:10 EDT
Just booted RH 7.1 system using 2.4.7-6 kernel from RC2.  'amd' still works
like before.
Comment 5 Enrico Scholz 2001-09-06 13:48:18 EDT
Don't know if related, but amd has a known issue causing bad errno-values (see
bug #44005).

I think the new 6.0.7 version would be worth a try...
Comment 6 Michal Jaegermann 2001-09-15 21:33:19 EDT
Sigh!  My fault.  I failed to notice that update created
/etc/sysconfig/amd.rpmnew and options are slightly different.  After fixing
that 'amd' started to work again.

But default "medium security" firewall created by lokkit will also
lock out 'amd' and failures look disturbingly similar. A bunch of
ports in eighthundreds is needed.
Comment 7 Bill Nottingham 2001-09-26 10:58:32 EDT
It's really impossible to programatically add RPC-based services, as they aren't
bound to sepcific ports. Closing as NOTABUG for the original amd issue.

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