http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5007
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|spamc/spamd |Libraries
Summary|Frequent "sysread not |PgSQL backend exits
|ready"-messages |mysteriously during scanning
| |with spamd
------- Additional Comments From [EMAIL PROTECTED] 2006-08-01 09:14 -------
hmm. I've just realised -- those messages like:
Jul 9 12:38:03 robin spamd[10366]: prefork: sysread(9) not ready, wait
max 300 secs
those are entirely OK, and not indicative of any problem. So don't take those
as a symptom. Looking into this, I don't think it's DNS-related either.
However, I notice this:
Jul 9 12:44:01 robin spamd[10225]: prefork: ordered 10366 to accept
Jul 9 12:44:01 robin spamd[10225]: prefork: sysread(7) not ready, wait
max 300 secs
Jul 9 12:44:01 robin spamd[10225]: prefork: child 10366: entering state
2
Jul 9 12:44:01 robin spamd[10225]: prefork: new lowest idle kid: 10388
10366 then proceeds to do a lot of work, at then it goes:
Jul 9 12:44:01 robin spamd[10366]: bayes: tok_get_all: token count: 255
Jul 9 12:44:01 robin spamd[10225]: prefork: new lowest idle kid: 10388
Jul 9 12:44:01 robin spamd[10225]: spamd: handled cleanup of child pid
10366 due to SIGCHLD
Jul 9 12:44:01 robin spamd[10225]: prefork: child closed connection
Jul 9 12:44:01 robin spamd[10225]: prefork: child states: I
The child should not be exiting after 'bayes: tok_get_all'! I think this is
almost definitely a bug in Mail/SpamAssassin/BayesStore/PgSQL.pm, where a
called module like DBI is calling "die", and this is not trapped using an eval
{ } scope. This then allows the "die" to propagate all the way out to the
child itself.
An strace would be really great ;) -- it may contain the SELECT statement and
other SQL traffic. You'd need to capture the syscalls made by the child.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
