Subject: Re: Problems with ypserv
To: None <firstname.lastname@example.org>
From: Manuel Bouyer <email@example.com>
Date: 06/30/1998 15:36:16
On Jun 26, firstname.lastname@example.org wrote
> I've got a NetBSD-1.3.1/i386 system which is acting as a YP slave.
> The master is a Sun Sparc system. Most of the clients are HP
> Here's the current `top` display:
> PID USERNAME PRI NICE SIZE RES STATE WAIT TIME CPU COMMAND
> 12648 root 53 0 1160K 228K run - 164:17 32.13% ypserv.debug
> 12929 root 38 0 1104K 216K run - 94:30 14.06% ypserv.debug
> 12533 root 37 0 1160K 228K run - 21:30 12.74% ypserv.debug
> 24573 root 2 0 1160K 216K sleep netio 14:44 10.30% ypserv.debug
> 14028 root 2 0 1160K 1268K sleep select 35:40 4.20% ypserv.debug
> 21181 root 2 0 1160K 224K sleep netio 5:56 1.61% ypserv.debug
> 25281 root 2 0 1160K 228K sleep netio 1:19 0.68% ypserv.debug
> This "ypserv.debug" is the regular ypserv compiled with "-g".
> I have checked the ypserv that comes with 1.3.2 and -current, and there
> do not seem to have been any changes except to the SCCS IDs.
> It seems that what is happening is that ypserv receives a request and then
> forks and the child is responsible for sending the reply. Using ktrace,
> it seems that ypserv is repeatedly dumping the group file, over and over
> again. In all cases that I've investigated so far, ypserv is talking to
> a forked copy of `cron` running on an HP workstation.
> Has anyone seen this behavior before? Are there any changes to ypserv
> since 1.3.1? Can anyone help me debug the problem?
> Please email me directly at: ckane (at) best (dot) com,
> I am not on this email list.
I've seen something similar a few days ago, with a sun master server and
some FreeBSD slave servers. The slaves received a higth rate of requests
from clients which did have multiple copies of 'cron' forked. I don't know
if the requests where for passwd or groups.
It turn out this was the result of a bad entry on the master server.
Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr