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
