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 <[email protected]>
To: [email protected]
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
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
-- End Original Message --
--
Jesse Norell
jesse (at) kci.net
_______________________________________________
Dbmail mailing list
[email protected]
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
