I encountered a situation where sendmail was opening up what appeared to be
listening on random UDP ports. In the process of tracking this down I
discovered that the culprit is getpwnam. A ktrace of the following simple
program show whats happening:
#include
#include
#include
#include
Quoting Bruce Campbell <[EMAIL PROTECTED]>:
> ...
> Well, somewhat unbelievably, copying a getpwent.c from 4.7
> and remaking libc on 5.3 with it worked. Load average
> has gone from 70 to 2.
>
One of my co-workers has found a less kludgey workaround
for the high load problem we were seeing on 5
e tested the dbm_fetch function independently on a large
> file, and it is fine.
>
> I've opened a bug report, and plan to build a replacement 4.x
> mail server, as the most deterministic path to restoring
> adequate e-mail service to our users.
>
> Can anyone suggest a worka
Quoting Bruce Campbell <[EMAIL PROTECTED]>:
> > On Tue, Jan 04, 2005 at 09:27:27PM -0500, Bruce Campbell wrote:
> >
> > > I wrote a small program:
> > >
> > > #include
> > > #include
> > >
> > > main( int argc, char *argv[] )
> > > {
> > > getpwuid( 13076 );
> > > }
> > >
> > > an
s
> yourself - it's straightforward to modify the source to do this).
Thanks. That had no effect on the large number of seeks/reads
to do a getpwuid of a specific uid. I tried boosting that
number further, still no change. I suspect the problem is related
to some change to the hash function
On Tue, Jan 04, 2005 at 09:27:27PM -0500, Bruce Campbell wrote:
> I wrote a small program:
>
> #include
> #include
>
> main( int argc, char *argv[] )
> {
> getpwuid( 13076 );
> }
>
> and ran it under truss on 5.x and it generated 178,711 lines of output.
> (the bulk of which is th
Quoting Kris Kennaway <[EMAIL PROTECTED]>:
>> > Well, no, not quite.
> >
> > old: imap-uw-2002_1,1
> > new: imap-uw-2004a,1
>
> OK, that's where you should start, then. Go back to the software
> configuration that you know is working and see if it still misbehaves.
>
> Kris
Thanks. I shutdown