You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Marcin Mirosław <ma...@mejor.pl> on 2011/03/30 12:17:52 UTC
One thing about bug 6558
Hi!
Sometimes (for example bug 6558) happen than spamd child(s) utilizes
100% cpu for a long time (until i kill them myself). My suggestion is to
add new functionality to SA, something like watchdog for spamd child
processes. If child hangs to long with email, it should be killed by
parrent proccess.
Regards.
Marcin
Re: One thing about bug 6558
Posted by Per Jessen <pe...@computer.org>.
Marcin Mirosław wrote:
> W dniu 30.03.2011 16:21, Per Jessen pisze:
>> Well, isn't the behaviour you're seeing working-as-expected then? If
>> it was an indefinite loop, setting up a time-out would be a possible
>> work-around. If the bayes code is doing what it is supposed to do,
>> but just taking long to do it, no work-around is needed.
>> Instead, you could try limiting the size of what is being processed
>> by spamd.
>
> It's not so easy to limit message size. It would be ideally to have
> config option "bayes_max_msg_size". I'm getting huge mail (UCE) which
> should be scanned by SA. Bayes isn't needed in this case (remained
> rules are enough to score such mails), but i can't turn off bayes
> engine for some mails.
Hmm, what size of mails are we talking about? I only scan mails <2Mb,
which I think is quite liberal. I guess a bayes_max_msg_size option is
not a bad idea though.
/Per Jessen, Zürich
Re: One thing about bug 6558
Posted by Marcin Mirosław <ma...@mejor.pl>.
W dniu 30.03.2011 16:21, Per Jessen pisze:
> Well, isn't the behaviour you're seeing working-as-expected then? If it
> was an indefinite loop, setting up a time-out would be a possible
> work-around. If the bayes code is doing what it is supposed to do, but
> just taking long to do it, no work-around is needed.
> Instead, you could try limiting the size of what is being processed by
> spamd.
It's not so easy to limit message size. It would be ideally to have
config option "bayes_max_msg_size". I'm getting huge mail (UCE) which
should be scanned by SA. Bayes isn't needed in this case (remained rules
are enough to score such mails), but i can't turn off bayes engine for
some mails. To do it i will have to setup another SA instance, with the
same config but with bayes turned off, in exim i can decide wich engine
use to scan using mail size. But this needs two SA running, needs more
memory etc.
I can't try now what would happen with rules mention in bug #6558, but
meseem spamd child wasn't killed after --timeout-child.
Regards!
Re: One thing about bug 6558
Posted by Marcin Mirosław <ma...@mejor.pl>.
W dniu 30.03.2011 16:21, Per Jessen pisze:
> Well, isn't the behaviour you're seeing working-as-expected then? If it
> was an indefinite loop, setting up a time-out would be a possible
> work-around. If the bayes code is doing what it is supposed to do, but
> just taking long to do it, no work-around is needed.
> Instead, you could try limiting the size of what is being processed by
> spamd.
Border case (i don't have much time for SA, i need to know quickly):
--timeout-child=1
I start spamc, and i'm expecting after one second i'll get info:
-spam
-ham
-time_limit
but know i'm getting info "time limit" after (e.g) 5 seconds.
Re: One thing about bug 6558
Posted by Per Jessen <pe...@computer.org>.
Marcin Mirosław wrote:
> W dniu 30.03.2011 15:47, Per Jessen pisze:
>> Yes, I meant the child - obviously, it sounds as if it's a problem in
>> the bayes processing. I don't use SA bayes, but that problem ought
>> to be investigated first before we look at work-arounds. IMHO.
>
> I'm expecting that bayes can do its work for long time, i'm working on
> mail with many, many words.
Well, isn't the behaviour you're seeing working-as-expected then? If it
was an indefinite loop, setting up a time-out would be a possible
work-around. If the bayes code is doing what it is supposed to do, but
just taking long to do it, no work-around is needed.
Instead, you could try limiting the size of what is being processed by
spamd.
/Per Jessen, Zürich
Re: One thing about bug 6558
Posted by Marcin Mirosław <ma...@mejor.pl>.
W dniu 30.03.2011 16:34, Kris Deugau pisze:
> My experience here has been that if a spamd child is pegging a CPU core
> for an extended period, there's simply a *lot* of body text to run
> (raw)body rules against (eg, ~ >200K).
>
> We've found that a fairly effective defense against this is to set up a
> second spamd instance with ~20 high-scoring rules (Spamhaus, local
> DNSBL, local and remote URI blacklists, Pyzor and/or Razor, plus one or
> two "normal" rules) and do two scanning passes:
>
> -> call the second (lean) instance, skip further filtering if tagged.
> This skims off ~80% of the junk (much of which would score >20 points
> with the full ruleset) at *very* low CPU usage.
> -> call the main instance on all remaining mail
This is interesting idea! I thought about configuration like this, but i
think about SA with and without bayes. I'm still trying to avoid double
instance of SA. I don't have big emails traffic, i have a little
specific traffic.
Regards
Re: One thing about bug 6558
Posted by Kris Deugau <kd...@vianet.ca>.
Marcin Mirosław wrote:
> W dniu 30.03.2011 15:47, Per Jessen pisze:
>> Yes, I meant the child - obviously, it sounds as if it's a problem in
>> the bayes processing. I don't use SA bayes, but that problem ought to
>> be investigated first before we look at work-arounds. IMHO.
>
> I'm expecting that bayes can do its work for long time, i'm working on
> mail with many, many words.
My experience here has been that if a spamd child is pegging a CPU core
for an extended period, there's simply a *lot* of body text to run
(raw)body rules against (eg, ~ >200K).
We've found that a fairly effective defense against this is to set up a
second spamd instance with ~20 high-scoring rules (Spamhaus, local
DNSBL, local and remote URI blacklists, Pyzor and/or Razor, plus one or
two "normal" rules) and do two scanning passes:
-> call the second (lean) instance, skip further filtering if tagged.
This skims off ~80% of the junk (much of which would score >20 points
with the full ruleset) at *very* low CPU usage.
-> call the main instance on all remaining mail
-kgd
Re: One thing about bug 6558
Posted by Mark Martinec <Ma...@ijs.si>.
Marcin,
> This option doesn't work as i wish ;) spamd child isn't killing after
> time set in --timeout-child, it is working, and working and utilizes
> 100% CPU until i send kill signal.
> It seems for me this option works as described below:
> (for this example --timeout-child=10 sec)
> Should i fill bug with this idea (or bug descibed there:
> http://osdir.com/ml/users-spamassassin/2011-03/msg00481.html or there:
> http://www.gossamer-threads.com/lists/spamassassin/users/161931#161931 ) ?
> Or it's enough it was discussed here?
It would be worthwhile to investigate your spamd's debug log and
see what is going on. The --timeout-child sets a deadline time, which
then controls most of the stages of spam checking, although it is
not a hard promise: perl uses a concept of safe-signals which means
that atomic perl opcodes won't be interrupted by a timer. If a runaway
regexp of a rule takes excessive time, the deadline exceeded will only
be detected after that rule has finished its work. Similarly some database
operations are not interrupted by SpamAssassin right after a deadline
is reached, but are allowed to complete for the sake of database integrity.
So it is not uncommon that a deadline gets exceeded occasionally by
few seconds. Seeing delays larger than that are worth investigating.
> spamc gets answer from daemon:
> 0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline
All the tests that have completed up till the deadline should be included
in the reported score. It may be the TIME_LIMIT_EXCEEDED alone,
but more commonly there would be other tests too. If you always see
a TIME_LIMIT_EXCEEDED as the only reported test and a score of 0,
then this should be investigated and warrants opening a ticket.
Mark
Re: One thing about bug 6558
Posted by Marcin Mirosław <ma...@mejor.pl>.
W dniu 30.03.2011 16:27, Adam Moffett pisze:
> Your watchdog idea is a valid one,
Should i fill bug with this idea (or bug descibed there:
http://osdir.com/ml/users-spamassassin/2011-03/msg00481.html or there:
http://www.gossamer-threads.com/lists/spamassassin/users/161931#161931 ) ?
Or it's enough it was discussed here?
Regards!
Marcin
Re: One thing about bug 6558
Posted by Mark Martinec <Ma...@ijs.si>.
Kris Deugau wrote:
> Mark Martinec wrote:
> > When we started using SpamAssassin years back our bayes and awl
> > databases were on a Berkeley DB. This worked reasonably well (sharing
> > your opinion on being 'occasionally flaky'), but the auto-expiration
> > long times started to grow from minutes to hours. Initially this was
> > solved by turning off opportunistic auto-expiry and running it
> > explicitly periodically. A long auto-expiry run could bog down mail
> > processing for a good part of an hour or more, collecting a large
> > backlog in a mail queue.
>
> I found BDB worked pretty well with a midnight-ish expiry up to ~600
> accounts; bayes_expiry_max_db_size was set to 600k and expiry was
> dropping ~60k tokens daily. I don't recall what the expiry time was but
> I'm sure it wasn't more than 10-15 minutes at most. Around that time
> that server became a legacy machine and customer cancellations slowly
> dropped the number of accounts back down.
True, machines have been much slower a couple of years back,
and pre-queue triage techniques have much improved since, so
nowadays our bdb figures would have been less severe.
> > The solution was to run an occasional
> > database repair, which would make things right again for a week
> > or two.
>
> I haven't seen corruption beyond anything that can just be attributed to
> mis(auto)learning; can you expand on what you saw and what you did here?
We started seeing most of bayes results to hit the indeterminate BAYES_50,
and only rarely still hitting BAYES_00 or BAYES_99 - as if the Bayes module
could not find any significant tokens in the database. A REPAIR TABLE,
folowed by ANALYZE TABLE and OPTIMIZE TABLE always resolved the problem,
so the records were there all the time. Didn't investigate much further,
knowing that I have a solution that worked and needs to be applied weekly.
Later switching to InnoDB avoided the problem altogether. It may have been
due to restarting SpamAssassin occasionally when testing new things and
fixing bugs.
> Are you running per-user Bayes DBs?
No, a global bayes database. Works for our rather homogenous users base
much better than a per-user Bayes DB, people benefit from each other's
auto-learned spam and ham samples.
> but we're also filtering all outbound mail.
So are we. Gives bayes auto-learning much more opportinity to learn
valuable ham samples, and saves our butt twice in a year when some
internal PC gets infected and starts spewing out spam.
Mark
Re: One thing about bug 6558
Posted by Mark Martinec <Ma...@ijs.si>.
Btw, I forgot to add that the:
bayes_auto_learn_on_error 1
feature in SpamAssassin trunk is a big help in keeping an
auto-learning Bayes database growth in check.
$ man Mail::SpamAssassin::Plugin::AutoLearnThreshold
bayes_auto_learn_on_error (0 | 1) (default: 0)
With "bayes_auto_learn_on_error" off, autolearning will be
performed even if bayes classifier already agrees with the new
classification (i.e. yielded BAYES_00 for what we are now trying
to teach it as ham, or yielded BAYES_99 for spam). This is a
traditional setting, the default was chosen to retain backwards
compatibility.
With "bayes_auto_learn_on_error" turned on, autolearning will be
performed only when a bayes classifier had a different opinion from
what the autolearner is now trying to teach it (i.e. it made an
error in judgement). This strategy may or may not produce better
future classifications, but usually works very well, while also
preventing unnecessary overlearning and slows down database growth.
Mark
Re: One thing about bug 6558
Posted by Michael Scheidell <mi...@secnap.com>.
On 4/1/11 1:52 PM, Mark Martinec wrote:
> The MyISAM screwups were finally resolved by switching our database to
> a InnoDB -type engine and using Mail::SpamAssassin::BayesStore::MySQL
> back-end (instead of the Mail::SpamAssassin::BayesStore::SQL).
> This finally solver the reliability/stability problems of a Bayes and
> AWL database for us, and the speed was good!
>
> Life was beautiful - until somehow this SQL solution started to become
> slow
on our large installs, I still have bayes_auto_expire 0 and do nightly
bayes cleanups.
I have some client sites much larger than your 1000, and don't see any
slowdowns.
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
ISN: 1259*1300
>*| *SECNAP Network Security Corporation
* Best Intrusion Prevention Product, Networks Product Guide
* Certified SNORT Integrator
* Hot Company Award, World Executive Alliance
* Best in Email Security, 2010 Network Products Guide
* King of Spam Filters, SC Magazine
______________________________________________________________________
This email has been scanned and certified safe by SpammerTrap(r).
For Information please see http://www.secnap.com/products/spammertrap/
______________________________________________________________________
Re: One thing about bug 6558
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Fri, 1 Apr 2011 19:52:54 +0200
Mark Martinec <Ma...@ijs.si> wrote:
> I can very much believe and agree that for a read-only bayes database
> the CDB provides the best performance - as long as you can afford
> (or have no other choice in large scale environments) to update it
> periodically offline.
It turns out not to be a problem. Updating the CDB by rewriting it
completely and then atomically renaming it turns out to be pretty
fast. We also don't need any locking (because we have other mechanisms
in place to ensure that one and only one process ever updates the CDB
at a time.)
> Regarding Berkeley DB and SQL I do not share this experience.
[...]
Ah, OK. My experience with PostgreSQL for Bayes was back in the 7.4
days, so I can believe Pg has improved tremendously since then. (We
do use PostgreSQL for many other things and are incredibly pleased
with it; it's an amazingly robust piece of software.)
Regards,
David.
Re: One thing about bug 6558
Posted by Henrik K <he...@hege.li>.
On Fri, Apr 01, 2011 at 04:08:02PM -0400, Kris Deugau wrote:
>
> We switched from MyISAM on physical disk to MyISAM on RAMdisk.
> Since we're running a global Bayes setup, ~2G of "disk" is plenty.
> A little tweaking of the MySQL init script makes sure the tmpfs is
> mounted, and then loads a backup dump of the database on startup.
> The effort involved in setting up a physical-disk storage system
> that can handle the I/O load is too high at the moment.
MyISAM is notoriously slow for Bayes, since it doesn't have row-level locking
like InnoDB.
Your setup seems unnecessary hacky compared to just running InnoDB and
innodb_flush_log_at_trx_commit=0.
Re: One thing about bug 6558
Posted by Kris Deugau <kd...@vianet.ca>.
Mark Martinec wrote:
> When we started using SpamAssassin years back our bayes and awl
> databases were on a Berkeley DB. This worked reasonably well (sharing
> your opinion on being 'occasionally flaky'), but the auto-expiration
> long times started to grow from minutes to hours. Initially this was
> solved by turning off opportunistic auto-expiry and running it
> explicitly periodically. A long auto-expiry run could bog down mail
> processing for a good part of an hour or more, collecting a large
> backlog in a mail queue.
I found BDB worked pretty well with a midnight-ish expiry up to ~600
accounts; bayes_expiry_max_db_size was set to 600k and expiry was
dropping ~60k tokens daily. I don't recall what the expiry time was but
I'm sure it wasn't more than 10-15 minutes at most. Around that time
that server became a legacy machine and customer cancellations slowly
dropped the number of accounts back down.
> So we finally gave up on using a Berkeley DB for bayes and
> switched to MySQL - and what a relief that was! Opportunistic
> auto-expire could be used again in real time, and the whole mail
> sytem could breath again. Well - occasionally the MyISAM -type
> database would enter into an unusable state, where SpamAssasin
> would still appear to be running normally, but bayes would not be
> returning sensible results. The solution was to run an occasional
> database repair, which would make things right again for a week
> or two.
I haven't seen corruption beyond anything that can just be attributed to
mis(auto)learning; can you expand on what you saw and what you did here?
> Life was beautiful - until somehow this SQL solution started to become
> slow, and tweaking and cleaning a database did not help. I'm not
> sure what exactly happened, but even starting with a new scratch
> database soon lost its speed. Not seeing any obvious solution, we tried
> switching to PostgreSQL - and stayed there ever since, never looking back!
> The switch was made somewhere in the 8.3 version of a PostgreSQL
> server, but now we are running a 9.0.3 (on a FreeBSD) and are very happy
> with it (along with a SpamAssassin from trunk - to become a 3.4).
We switched from MyISAM on physical disk to MyISAM on RAMdisk. Since
we're running a global Bayes setup, ~2G of "disk" is plenty. A little
tweaking of the MySQL init script makes sure the tmpfs is mounted, and
then loads a backup dump of the database on startup. The effort
involved in setting up a physical-disk storage system that can handle
the I/O load is too high at the moment.
Are you running per-user Bayes DBs?
> To put things into perspective, our user base is about 1000 users, so
> my experience does not necessarily translate to large ISPs, or to SOHO.
*nod* We're filtering ~13k of ~50k users, but we're also filtering all
outbound mail.
On my personal server, I'm still using per-user BDB Bayes; I've seen no
reason to switch. There are all of about 3 live users, after all...
-kgd
Re: One thing about bug 6558
Posted by Mark Martinec <Ma...@ijs.si>.
David F. Skoll wrote:
> Using Pg for Bayes data will be really slow. We don't use the SpamAssassin
> Bayes implementation and we went through three iterations of storage
> back-ends before finding one we liked.
>
> 1) PostgreSQL: Convenient but slow.
>
> 2) Berkeley DB: Faster than PostgreSQL, but still slow and
> occasionally flaky
>
> 3) CDB: Very fast, but cannot be incrementally updated. You need to
> rebuild the entire DB and then atomically rename it.
>
> In our implementation, it's not a problem to have a read-only DB, so we
> went with CDB. It's dramatically faster than Berkeley DB:
> http://www.dmo.ca/blog/benchmarking-hash-databases-on-large-data/
Thanks for pointing out your benchmark, interesting - especially for me the
reference to a Tokyo Cabinet and its successor Kyoto Cabinet. This would
be worth inverstigating further. The benchmark may not necessarily reflect
directly the usage profile of SpamAssassin's Bayes module, especially its
auto- expiration runs and the search-in-a set (the IN operator in SQL).
I can very much believe and agree that for a read-only bayes database
the CDB provides the best performance - as long as you can afford
(or have no other choice in large scale environments) to update it
periodically offline.
Regarding Berkeley DB and SQL I do not share this experience.
When we started using SpamAssassin years back our bayes and awl
databases were on a Berkeley DB. This worked reasonably well (sharing
your opinion on being 'occasionally flaky'), but the auto-expiration
long times started to grow from minutes to hours. Initially this was
solved by turning off opportunistic auto-expiry and running it
explicitly periodically. A long auto-expiry run could bog down mail
processing for a good part of an hour or more, collecting a large
backlog in a mail queue.
So we finally gave up on using a Berkeley DB for bayes and
switched to MySQL - and what a relief that was! Opportunistic
auto-expire could be used again in real time, and the whole mail
sytem could breath again. Well - occasionally the MyISAM -type
database would enter into an unusable state, where SpamAssasin
would still appear to be running normally, but bayes would not be
returning sensible results. The solution was to run an occasional
database repair, which would make things right again for a week
or two.
The MyISAM screwups were finally resolved by switching our database to
a InnoDB -type engine and using Mail::SpamAssassin::BayesStore::MySQL
back-end (instead of the Mail::SpamAssassin::BayesStore::SQL).
This finally solver the reliability/stability problems of a Bayes and
AWL database for us, and the speed was good!
Life was beautiful - until somehow this SQL solution started to become
slow, and tweaking and cleaning a database did not help. I'm not
sure what exactly happened, but even starting with a new scratch
database soon lost its speed. Not seeing any obvious solution, we tried
switching to PostgreSQL - and stayed there ever since, never looking back!
The switch was made somewhere in the 8.3 version of a PostgreSQL
server, but now we are running a 9.0.3 (on a FreeBSD) and are very happy
with it (along with a SpamAssassin from trunk - to become a 3.4).
I must admit that during our first attempted transition to SQL we
tried both the MySQL as well as PostgreSQL, and indeed the MySQL
turned out to be faster. Seems like the IN operator in PostgreSQL
was not well optimized. But it appears that this problem is no longer
present in more current versions of PostgreSQL - not sure in which
version the change occurred.
To put things into perspective, our user base is about 1000 users, so
my experience does not necessarily translate to large ISPs, or to SOHO.
Anyway, just wanted to share my point of view.
Mark
Re: One thing about bug 6558
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Wed, 30 Mar 2011 16:51:57 +0200
Marcin Mirosław <ma...@mejor.pl> wrote:
> I'm using postgresql, but machine isn't quick... Any db is slowly
> there.
Using Pg for Bayes data will be really slow. We don't use the SpamAssassin
Bayes implementation and we went through three iterations of storage
back-ends before finding one we liked.
1) PostgreSQL: Convenient but slow.
2) Berkeley DB: Faster than PostgreSQL, but still slow and
occasionally flaky
3) CDB: Very fast, but cannot be incrementally updated. You need to rebuild
the entire DB and then atomically rename it.
In our implementation, it's not a problem to have a read-only DB, so we went
with CDB. It's dramatically faster than Berkeley DB:
http://www.dmo.ca/blog/benchmarking-hash-databases-on-large-data/
Regards,
David.
Re: One thing about bug 6558
Posted by Marcin Mirosław <ma...@mejor.pl>.
W dniu 30.03.2011 16:27, Adam Moffett pisze:
> Your watchdog idea is a valid one, but if you can improve bayes
> performance it may become a non-issue. Have you tried moving bayes to a
> MySQL database? It consumes more disk space and memory, but it's
> dramatically faster than using the default database (which is Berkeley
> if I recall correctly).
I'm using postgresql, but machine isn't quick... Any db is slowly there.
Re: One thing about bug 6558
Posted by Adam Moffett <ad...@plexicomm.net>.
> I'm expecting that bayes can do its work for long time, i'm working on
> mail with many, many words.
Your watchdog idea is a valid one, but if you can improve bayes
performance it may become a non-issue. Have you tried moving bayes to a
MySQL database? It consumes more disk space and memory, but it's
dramatically faster than using the default database (which is Berkeley
if I recall correctly).
Re: One thing about bug 6558
Posted by Marcin Mirosław <ma...@mejor.pl>.
W dniu 30.03.2011 15:47, Per Jessen pisze:
> Yes, I meant the child - obviously, it sounds as if it's a problem in
> the bayes processing. I don't use SA bayes, but that problem ought to
> be investigated first before we look at work-arounds. IMHO.
I'm expecting that bayes can do its work for long time, i'm working on
mail with many, many words.
Re: One thing about bug 6558
Posted by Per Jessen <pe...@computer.org>.
Marcin Mirosław wrote:
> W dniu 30.03.2011 14:06, Per Jessen pisze:
>> Have you looked at what spamd is doing when it so busy?
>
> Did You mean "spamd child"? At this moment bayes engine do very hard
> work with email.
Yes, I meant the child - obviously, it sounds as if it's a problem in
the bayes processing. I don't use SA bayes, but that problem ought to
be investigated first before we look at work-arounds. IMHO.
/Per Jessen, Zürich
Re: One thing about bug 6558
Posted by Marcin Mirosław <ma...@mejor.pl>.
W dniu 30.03.2011 14:06, Per Jessen pisze:
> Have you looked at what spamd is doing when it so busy?
Did You mean "spamd child"? At this moment bayes engine do very hard
work with email.
Re: One thing about bug 6558
Posted by Per Jessen <pe...@computer.org>.
Marcin Mirosław wrote:
> Hi!
> Sometimes (for example bug 6558) happen than spamd child(s) utilizes
> 100% cpu for a long time (until i kill them myself). My suggestion is
> to add new functionality to SA, something like watchdog for spamd
> child processes. If child hangs to long with email, it should be
> killed by parrent proccess.
Have you looked at what spamd is doing when it so busy?
/Per Jessen, Zürich
Re: One thing about bug 6558
Posted by Marcin Mirosław <ma...@mejor.pl>.
W dniu 30.03.2011 17:12, RW pisze:
> Are you sure that there were idle spamd children? The above is
> consistent with ~14 seconds queuing for a child, followed by a
> timeout after 10 seconds.
I was watching cpu time of spamd child (i took delta, not last cpu time
;) ). 14+10 is coincidence.
Re: One thing about bug 6558
Posted by RW <rw...@googlemail.com>.
On Wed, 30 Mar 2011 13:17:55 +0200
Marcin Mirosław <ma...@mejor.pl> wrote:
> W dniu 30.03.2011 12:33, Daniel Lemke pisze:
> > You mean something like --timeout-child=secs as a spamd starting
> > option? ;) http://spamassassin.apache.org/full/3.3.x/doc/spamd.html
>
> Thanks for quick reply!
> This option doesn't work as i wish ;) spamd child isn't killing after
> time set in --timeout-child, it is working, and working and utilizes
> 100% CPU until i send kill signal.
> It seems for me this option works as described below:
> (for this example --timeout-child=10 sec)
> ...
> real 0m24.851s
> user 0m0.000s
> sys 0m0.010s
>
> 24 seconds was time how long spamd child was working on test email.
Are you sure that there were idle spamd children? The above is
consistent with ~14 seconds queuing for a child, followed by a
timeout after 10 seconds.
Re: One thing about bug 6558
Posted by Marcin Mirosław <ma...@mejor.pl>.
W dniu 30.03.2011 12:33, Daniel Lemke pisze:
> You mean something like --timeout-child=secs as a spamd starting option? ;)
> http://spamassassin.apache.org/full/3.3.x/doc/spamd.html
Thanks for quick reply!
This option doesn't work as i wish ;) spamd child isn't killing after
time set in --timeout-child, it is working, and working and utilizes
100% CPU until i send kill signal.
It seems for me this option works as described below:
(for this example --timeout-child=10 sec)
0s - i'm starting scanning mail with spamc
[...] - spamd child havy works with mail
10s - spamd child still works and uses 100% of cpu
20s - spamd child still works and uses 100% of cpu
30s - spamd child finished scanning, it ends his work, in this moment
spamc gets answer from daemon: 0.0 TIME_LIMIT_EXCEEDED Exceeded time
limit / deadline
So, if child doesn't end in time definied in timeout-child it means that
result of spamd child's work will not be usedby spamd. But spamd still
doesn't return "time_limit" after timeout-child pass, it waits for
something (cpu is free), and spamc waits for nothing (spamc should now
get "time_limit" imho). This is new question, why spamd doesn't return
"time_limit" immediately when timeout-child occurs?
# ps x|grep spamd
29513 ? SNs 0:12 /usr/sbin/spamd -d -r /var/run/spamd.pid
--min-spare=2 --max-spare=4 -m 5 -i 127.0.0.1 -x -q -u nobody -l
--timeout-child=10
# time spamc -s 3344444 -R <
1297332681.M942138P14806.poczta\,S\=1557593\,W\=1608807
0.0/5.9
[cut X-info]
X-Szczegoly:(poczta.cibet.pl)(0.0 points)
pts rule name description
---- ---------------------- ---------------------------------------------
0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline
real 0m24.851s
user 0m0.000s
sys 0m0.010s
24 seconds was time how long spamd child was working on test email.
P.S. Yes, i'm using new version of SA, 3.3.1 ;)
Re: One thing about bug 6558
Posted by Daniel Lemke <le...@jam-software.com>.
Marcin Mirosław wrote:
>
> If child hangs to long with email, it should be killed by
> parrent proccess.
>
You mean something like --timeout-child=secs as a spamd starting option? ;)
http://spamassassin.apache.org/full/3.3.x/doc/spamd.html
Daniel
--
View this message in context: http://old.nabble.com/One-thing-about-bug-6558-tp31275747p31275828.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.