This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project Paul's DBMail tree.
The branch, dbmail_2_2 has been updated
via c082bb2f1be984b4c5838019619eeb447dc05718 (commit)
via
Anatoly wrote:
Guntis Bumburs wrote:
Hello,
I have a problem with dbmail on Freebsd. The situation is that dbmail
fills all the /tmp space (seems to not releasing used space/opened file)
and when it's full the imap daemon starts acting strange, postfix cant
flush new mails ... (pop
Guntis Bumburs wrote:
Anatoly wrote:
Guntis Bumburs wrote:
Hello,
I have a problem with dbmail on Freebsd. The situation is that dbmail
fills all the /tmp space (seems to not releasing used space/opened file)
and when it's full the imap daemon starts acting strange, postfix
Guntis,
try the attached patch if you will.
But more importantly. a reliable workaround that won't require testing
patches is to tune down the MAXCONNECTS parameter to 100 or so. This
will prevent forked children from running too long.
Guntis Bumburs wrote:
Anatoly wrote:
Guntis Bumburs
Tnx Paul,
Testing now...
Paul J Stevens wrote:
Guntis,
try the attached patch if you will.
But more importantly. a reliable workaround that won't require testing
patches is to tune down the MAXCONNECTS parameter to 100 or so. This
will prevent forked children from running too long.
Change your tmp environment variable to point somewhere else, then
restart whichever daemons need to be restarted so that their tmp paths
are changed. then umount the folder and fsck it. then remount it and
reverse your tmp environment variable changes and restart/reload your
daemons
You miss the point.
The problems reported by fsck is the effect of problems caused by dbmail
I can resolve them by restarting dbmail -imap daemon and there will be
no need to run fsck because by restarting dbmail i solve unref files
Now i'm testing the patch provided by Paul. This could take a
On Donnerstag 23 April 2009 Guntis Bumburs wrote:
MAXCONNECTS = 1
what is the benefit to have it so hight?
what would happen if i change it to Paul's suggested 100?
A single thread will accept MAXCONNECT connections and then stop, and a
fresh one startet. Like this, all memory/disk
Michael Monnerie wrote:
On Donnerstag 23 April 2009 Guntis Bumburs wrote:
MAXCONNECTS = 1
what is the benefit to have it so hight?
what would happen if i change it to Paul's suggested 100?
A single thread will accept MAXCONNECT connections and then stop, and a
fresh one