[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amd-dev
Subject:    Re: amd
From:       Scott Sutherland <scott () math ! sunysb ! edu>
Date:       2001-03-15 22:27:57
[Download RAW message or body]

On Thu, 15 Mar 2001, Ion Badulescu wrote:

> On Thu, 15 Mar 2001, Peter Breitenlohner wrote:
> 
> > This usually is a (permanent or transient) NIS failure, most likely during
> > amd startup. Have you tried "amq -f", that might help. Otherwise just
> > shutting down and restarting amd should certainly help -- no need to reboot.
> > 
> > I think some time ago I had sent a patch to Erez which was supposed to fix
> > his problem, maybe the patch was not good (enough).
> 
> I don't think so, our boxes at Columbia used to have this problem a while 
> ago, but recent versions of am-utils have solved it.  Whether it was 
> your patch of something else, amd now recovers quite nicely from NIS 
> mix-ups.
> 
> However, he's running an ancient version of am-utils:
> 
> 61  Mar  5 06:29:30 ez29 amd[736]: am-utils version 6.0a16 (build 2).
> 62  Mar  5 06:29:30 ez29 amd[736]: Built by ezk@okeeffe.cs.columbia.edu on date Mon \
> Apr 20 09:01:15 EDT 1998. 
> 3 years is an eternity in our world. :-) Hartmut, please try to upgrade to 
> the latest release (6.0.5) and see if your problems go away or not.

If he is specifying the NIS domain in the amd.conf file  AND is running
Linux without the most recent glibc, there is a file descriptor leak in
the Linux yp code.  This can cause this sort of problem.  The work-around 
is simple:  don't specify the NIS domain in the amd.conf file.

(the problem was that if the NIS domain is specialized, amd initializes
the yp maps in such a way that the glibc code tries to cache the
connection.  Unfortunately, it forgets that the connection was cached, and
opens another anyway...)


[prev in list] [next in list] [prev in thread] [next in thread]