Bug 53251 - am-utils stopped to work
Summary: am-utils stopped to work
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: am-utils   
(Show other bugs)
Version: 7.3
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-09-05 15:55 UTC by Michal Jaegermann
Modified: 2007-04-18 16:36 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-09-16 01:33:24 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2001-09-05 15:55:08 UTC
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 18:34:22 UTC
If it's as broken as Michal reports, this is a definite errata candidate.

Comment 2 Nalin Dahyabhai 2001-09-06 14:26:11 UTC
My first guess is that this has something to do with the kernel/automounter

Comment 3 Michal Jaegermann 2001-09-06 14:39:15 UTC
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 15:19:10 UTC
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 17:48:18 UTC
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-16 01:33:19 UTC
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 14:58:32 UTC
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.