On Jun 26, nospam@best.com wrote
> Hello.
> 
> 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 
> workstations.
> 
> 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
--