On Fri, Jul 07, 2000 at 01:59:13PM -0400, Brian Ristuccia wrote: > On Fri, Jul 07, 2000 at 07:18:41PM +0200, Christoph Goern wrote: > > hi, > > I just tracked the same bug down on some redhat boxes using nscd, > > and redhat has no solution too. have you received any comments > > on this bug? > > From what I can tell, apparently an ethernet interface blocks in a bad way > when it can't arp for the default gateway (for example if a cable modem or > DSL is down). This seems to cause all of nscd's dns resolver processes to > block, which eventually blocks the main nscd process, effectively stopping > all name<->number resolutions including uid's and gid's. As a result, most > jobs on the system eventually block.
the network we have set up has no default gateway, it is completely separated, have a own dns-server resolving all hosts/ip correctly. i think it�s not about dns, we also have "enable-cache hosts no" in nscd.conf maybe what you have spyed is this: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=11777 > I can't think of any good solution. Obviously, nscd can give a good speedup > if you have a large password file or many different processes looking up the > same hostnames on a machine that doesn't run its own bind, so it would be > nice if it got fixed. we use nscd to cache LDAP answers. We use to resolve username<->uidnumber questions based on a central ldap-directory. not using nscd will terribly slow things down. > > -- > Brian Ristuccia > [EMAIL PROTECTED] > [EMAIL PROTECTED] -- Christoph Goern <[EMAIL PROTECTED]> * ID-PRO Deutschland GmbH * Am Hofgarten 20 * D-53113 Bonn * Tel. +49 (0) 2 28-4 21 54-0 * Fax -359 * http://open-for-the-better.com
