-------------------- Start SpamAssassin results ----------------------
This mail is probably spam. The original message has been altered
so you can recognise or block similar unwanted mail in future.
See http://spamassassin.org/tag/ for more details.
Content analysis details: (6.6 hits, 5.0 required)
1.2 USER_AGENT_MOZILLA_UA User-Agent header indicates a non-spam MUA (Mozilla)
5.4 BAYES_99 BODY: Bayesian spam probability is 99 to 100%
[score: 0.9999]
-------------------- End of SpamAssassin results ---------------------
--- Begin Message ---
Jesse Norell wrote:
The only thing that comes to mind even remotely similar is in some
signal handling bugs in the linux kernel. I had some machines with
a problem in the pop3d server - whenever it got a SIGALRM it went into
a loop sucking up all cpu time. I never had time to really track it
down and it was not producable on other OS's .. and a few updates
later (running debian unstable), the problem went away. There is
now another problem with pop3d in a high cpu use loop while serving
pop3 clients, and writes to the client are quite slow (eg. one write()
per 1-4 seconds), but I'm guessing that may not be in dbmail either
(both linux kernel and postgres libraries were updated when this
showed up). Again, haven't had the time to look into it more....
If you can, try to track this down a little more, and post a bug
report (or patch ;). At minimum, turn on level 5 logging and post
the logs when this happens. You could also strace the process and
see if that gives any indication of what's happening, and run it
under a debugger to really track things down, if you're familiar with
doing so. Even finding a scenario in which this can be reproduced
by someone else will help get it fixed a lot faster. (Don't use imap
here, so I can't really check that.)
lol, I actually did a little of that when I first found it, the level 5
log (I'll see if I have it laying around still, if not I'll make one
again) showed the request coming in and the sql being formulated and
presumably sent to the db, but no response came back, so it could have
easily been a signal issue or a block on a socket to the sql server. I
can strace it or attach with gdb and get more information. The scenario
for reproducing it was pretty much describe by Jason. If you make a lot
of requests such as switching folders rapidly it'll get into this
state. I'm running it on a 2.6.0-test4 kernel.
Eric
--- End Message ---
