yeah, Linux is the only problem child among *nixes.
All the BSD and Solaris are working..
Best regards,
Eelco
On zondag, jun 1, 2003, at 19:23 Europe/Amsterdam,
<[EMAIL PROTECTED]> wrote:
I agree about the signal implementation problem in Linux. I use DBMail
1.1
in Solaris x86/Sparc in 4 production servers. Since rc3 I never see a
cpu
hog problem. DBMail 1.1 repairs a small bug that stops dbmail-imapd to
daemonize if running from console instead of a rc script, and since
that
runs flawlessly.
I test the pop daemon with a 31 second timeout, and process dies
properly,
so it seem DBmail is working fine with solaris signal handing.
I wish luck to solve that for the Linux platform.
Alejandro Marin
Roel, wanna see if you can duplicate (and fix) that? :)
Roel loves signals :)
Seriously, he hates them. The reason is that signals are not
implemented in Linux as the man pages tell us they should be.
This is why Roel has made some workarounds.
It is also what i told was wrong with the CPU hogging, but
he didn't believe it (Roel and I have a bit of a "who writes the best
code" struggle ;).
I think he'll get to it tomorrow, he's probably still drunk
from yesterday's evening :)
I'm going to Florida for a month so i won't be doing much
with DBmail (except reading my e-mail now and then).
Roel told me he was going to stabalize the current source
tree. Next month we'll have a new team member called Ilja
who's going to be working on DBmail a lot.
Best regards,
Eelco
Jesse
---- Original Message ----
From: Jesse Norell <dbmail@dbmail.org>
To: dbmail@dbmail.org
Subject: [Dbmail] dbmail-pop3d hogging cpu - reproducable
Sent: Sat, 31 May 2003 12:18:42 -0600 (MDT)
Hello,
Well, after a late night and having joined the ranks of those
running dbmail on a production, can't turn back now basis, we're
seeing dbmail-pop3d get into a state of using all available cpu
cycles, as others have mentioned. We have one machine on which this
is 100% reproducable by simply telnetting to port 110 and
waiting 5 minutes for the timeout - the dbmail-pop3d that handled
our
connection will then be in that state. Sending HUP signal to the
parent dbmail-pop3d will end up clearing it (at the cost of dropping
all current pop3 sessions), or sig KILL to that process will kill it
to. It's easy to identify by turning up logging
and watching for 'got signal [14]' .. we're working on writing a
script to monitor that and KILL those processes for short term. The
problem is somewhere in the signal handling, but I've not
found it yet. If anyone wants to look into it, or try reproducing
it, that'd be great. I'll keep working on it too, but right now
lack
of sleep is starting to impair progress. This is with cvs as of
this
morning, with pgsql; we have a few custom patches too, but they only
take place later on (after you log in), this is just in the signal
handling routines.
Thanks,
Jesse
--
Jesse Norell
jesse (at) kci.net
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
-- End Original Message --
--
Jesse Norell
jesse (at) kci.net
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_________________________
E.J.A. van Beek
ICT Manager
IC&S
T: +31 30 2322878
F: +31 30 2322305
PGP-key:
www.ic-s.nl/keys/eelco.txt
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
Dbmail mailing list
Dbmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_________________________
E.J.A. van Beek
ICT Manager
IC&S
T: +31 30 2322878
F: +31 30 2322305
PGP-key:
www.ic-s.nl/keys/eelco.txt
