https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6748
Bug #: 6748
Summary: spamd --timeout-child=0 results in default 300 second
timeout
Product: Spamassassin
Version: 3.3.2
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: normal
Priority: P2
Component: spamc/spamd
AssignedTo: [email protected]
ReportedBy: [email protected]
Classification: Unclassified
After some testing with a rather large test message, I noticed the following
behavior.
1) Add "time_limit 0" to local.cf.
2) Pass --timeout-child=0 to spamd.
3) Check large message.
4) Analysis times out after 300 seconds with TIME_LIMIT_EXCEEDED.
The correct behavior is:
4) Analysis completes after an unbounded number of seconds.
I tested further by changing both time_limit and --timeout_child to varying
non-zero values. Both work properly, otherwise.
Checking the spamd code, I saw:
if (defined $opt{'timeout-child'}) {
$timeout_child = $opt{'timeout-child'};
$timeout_child = undef if ($timeout_child < 1);
}
# Set some "sane" limits for defaults
...
$timeout_child ||= 300;
Based on later usage of $timeout_child, it appears that the correct logic is
something more like this:
if (defined $opt{'timeout-child'} && $opt{'timeout-child'} >= 0) {
$timeout_child = $opt{'timeout-child'};
$timeout_child = undef if ($timeout_child == 0);
}
else {
$timeout_child = 300;
}
The "sane limits" line optionally defining $timeout_child should be removed.
As far as I can tell, this same logic should probably also be applied to
timeout-tcp.
I'll try to put up a patch...
--
Configure bugmail:
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
