[Dbmail-dev] [SCM]Paul's DBMail tree branch, dbmail_2_2, updated. v2.2.7-76-gc082bb2

2009-04-23 Thread Paul J Stevens
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

Re: [Dbmail] /tmp full

2009-04-23 Thread Guntis Bumburs
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

Re: [Dbmail] /tmp full

2009-04-23 Thread Guntis Bumburs
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

Re: [Dbmail] /tmp full

2009-04-23 Thread Paul J Stevens
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

Re: [Dbmail] /tmp full

2009-04-23 Thread 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.

Re: [Dbmail] /tmp full

2009-04-23 Thread Curtis Maurand
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

Re: [Dbmail] /tmp full

2009-04-23 Thread Guntis Bumburs
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

Re: [Dbmail] /tmp full

2009-04-23 Thread Michael Monnerie
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

Re: [Dbmail] /tmp full

2009-04-23 Thread Guntis Bumburs
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