In some email I received from Chris Nolan <[EMAIL PROTECTED]> on Mon, 02 Jun 2003 10:02:36 +1000, wrote:
> Hi Eelco, > > Have you looked at RT POSIX signals? Admittedly, they are quite > dependent on a very new 2.4 kernel but they are very standard and seem > to behave properly on my Linux boxes, as in just like the Solaris 7 and > 8 boxes at uni. > Couldnt reproduce this problem on my machines... slackware linux 9.0 + latest dbmail-cvs cheers > Eelco van Beek - IC&S wrote: > > > 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 <[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
