From peter@haywire.DIALix.oz.au Fri Jul 15 15:59:47 1994
Received: from haywire.DIALix.oz.au (haywire.DIALix.oz.au [192.203.228.65]) by godot.lysator.liu.se (8.6.8.1/8.6.6) with ESMTP id PAA25347 for <pen@lysator.liu.se>; Fri, 15 Jul 1994 15:55:24 +0200
Received: (peter@localhost) by haywire.DIALix.oz.au (8.6.9/8.6.4) id VAA13101 for pen@lysator.liu.se; Fri, 15 Jul 1994 21:24:13 +0930
From: Peter Wemm <peter@haywire.DIALix.oz.au>
Message-Id: <199407151154.VAA13101@haywire.DIALix.oz.au>
Subject: odd (recurring) problems with an old pidentd
To: pen@lysator.liu.se
Date: Fri, 15 Jul 1994 19:54:12 +0800 (WST)
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 886       
Status: R

Hi.. It's been a while since we were last in contact...

I have about a dozen machines running pidentd-2.1.2..  Every so often,
we get a pidentd that's gone off the rails.  I killed one today that
had consumed around 5800 minutes of cpu time.. :-(

Anyway, I'm wondering if you have seen anything like this before, and
if a newer version is likely to fix it.. :-)

I suspect that pidentd is running off the end of the inode linked list
and looping (this is on a seriously modified Dell 2.2 SVR4.0.4/386
machine...  in fact, now that I think about it, It's _so_ seriously
modified, that I'm now in a position to add a credentials field to the
tcb array.. :-) Hmmmmm..).  When I do a truss on the process, it shows
that it's doing lseek(), read(), lseek(), read(), lseek(), read(),
etc.

Other than that, we've had faithful service from pidentd - thanks VERY
much for doing it!

-Peter