tpop3d-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [tpop3d-discuss] Tpop 1.4.2 memory leak?: fork_child: fork: Not enou


From: Rich, WhidbeyNet NOC
Subject: RE: [tpop3d-discuss] Tpop 1.4.2 memory leak?: fork_child: fork: Not enough space
Date: Thu, 9 Jan 2003 13:04:01 -0800

Hi list, 

Chris thanks for the reply as always.

Both machines are Solaris 9, which access Maildirs over NFS, and use NIS
for authentication. Tpop3d has been configured in the following way:

listen-address: 0.0.0.0
max-children: 30
log-facility: mail
mailbox: maildir:$(home)/Maildir
auth-pam-enable: yes
auth-pam-facility: login

It was compiled with (we plan to use ldap eventually):

./configure --with-openldap-root=/usr/local --enable-fcntl-locking \
--disable-flock-locking --disable-dotfile-locking
--disable-cclient-locking \
--enable-auth-pam --enable-auth-ldap --enable-mbox-maildir
--disable-mbox-bsd \
--disable-snide-comments

We've been using PAM, so I ran the pamtest.c (gcc -lpam -o pamtest
pamtest.c) for an hour on a test Solaris 9 machine. "vmstat" and
"/usr/ucb/ps" showed that the "pamtest" process consumed an average of
15 Kb of memory per second, about 1 Mb/minute. After an hour, it was
using 60mb of memory, and continued to grow.

The memory was released back to the system when the process was killed.
If left to continue, would that steady consumption of memory by
"pamtest" constitute a memory leak in pam?

I created a memory and cpu monitor for our system. It ran from 6pm last
night, to 8:30pm this morning (when the tpop3d on both machines stopped
responding again. The statistics are attached as files,
"server1stats.txt" and "server2stats.txt". However, they show no steady
progressive memory consumption that I can see.

For now, I think we may disable pam and try "auth-passwd", to see if
that helps. Are the changes in the CVS (1.5x) stable and significant
enough to put in place of our 1.4.2? Do the attached files shed any
light?

Rich Sandberg
address@hidden
Network Administrator
WhidbeyNet Network Operations


-----Original Message-----
From: Chris Lightfoot [mailto:address@hidden 
Sent: Thursday, January 09, 2003 1:38 AM
To: Rich, WhidbeyNET
Cc: address@hidden
Subject: Re: [tpop3d-discuss] Tpop 1.4.2 memory leak?: fork_child: fork:
Not enough space


On Wed, Jan 08, 2003 at 05:37:57PM -0800, Rich, WhidbeyNET wrote:
> Both machines ran fine for 6.5 hours, before the tpop3d daemon could 
> no
> longer fork child processes. All remaining connections were 
> "disconnected" safely by tpop3d, and tpop3d continued to run, but
would 
> no longer answer requests on port 110. The last error in the log was:
> 
> "fork_child: fork: Not enough space"
    [...]
> From looking at the code, the error is generated from a -1 return code
> when trying to call fork().  Has enyone encountered a memory leak with

> tpop3d, and has it been corrected in the CVS?
> 
> This is pretty serious, as it affected two Solaris 9 machines at the
> same time, so it's unlikely a machine-specific problem. We were/are 
> ready to implement tpop3d systemwide.

What authenticators are you using? While it's certainly possible that
there are memory leaks in tpop3d -- there have been in the past -- one
source of problems has also been memory leaks in the PAM libraries. But
that's mostly been on Linux; I can't remember whether I found that
Solaris PAM leaks or not.

If you are using PAM,can you download
    http://ex-parrot.com/junk/pamtest.c
substitute a correct username and password for `user' and `password' in
the call to auth_pam_new_user_pass, and run the code. If it leaks
memory, you have a problem with PAM on your system.

Of course, if you're not using PAM, this may not be the problem. More
details, please.

-- 
``Think about the average person. Now, half the people
  out there, by definition, are even dumber than that.''
  (L. Ron Hubbard, attrib.)

Attachment: server1stats.txt
Description: Text document

Attachment: server2stats.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]