You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@spamassassin.apache.org on 2022/10/24 22:13:46 UTC

[Bug 8068] New: t/spamd_ssl_accept_fail.t failure on slow systems

https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8068

            Bug ID: 8068
           Summary: t/spamd_ssl_accept_fail.t failure on slow systems
           Product: Spamassassin
           Version: 4.0.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Regression Tests
          Assignee: dev@spamassassin.apache.org
          Reporter: sidney@sidney.com
  Target Milestone: Undefined

t/spamd_ssl_accept_failt.t was written to test the fix for bug 4107 which was
spamd crashing when it was launched with the option to accept only ssl
connections and spamc called it using non-ssl protocol.

The test consists of launching spamd with ssl option, calling it once with
spamc without ssl, then again with spamc using ssl, then stopping spamd,
confirming that the combined return from the two calls to spamc contains the
expected spam report from the second call.

In setting up testing on GitHub Actions, the test fails with the second spamc
call not appearing to contact spmd, same as the non-ssl call.

If I add a sleep(1) between the first and second call of spamc, the test works.

I suspect that the fix for bug 4107 does not prevent the child process from
crashing when it receives the non-ssl call from spamc. That is good enough as
far as the fix goes, because the child gets re-spawned.

If I'm right about the cause of the test failure, it is only a problem if spamd
is running using ssl on a slower than useful for production system and spamc
calls it without ssl from a machine that has access to the spamd port and then
a proper ssl call from spamc happens less than a second later, and then the
only result is that the second spamc call fails. If that is the only failure
scenario I think it would be fine to just add a sleep(1) to the test so that it
can pass on slow systems like the GitHub action runner.

If anyone wants to look at the code and and make a more robust fix for bug 4107
that keeps the child from crashing, feel free.

Since my proposed change is only in the test, I think I can commit it for 4.0.0
without a vote.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 8068] t/spamd_ssl_accept_fail.t failure on slow systems

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8068

Sidney Markowitz <si...@sidney.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sidney@sidney.com
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|Undefined                   |4.0.0

--- Comment #1 from Sidney Markowitz <si...@sidney.com> ---
trunk % svn ci -m "bug 8068 - Add a delay in the test to allow for some slow
test systems" t/spamd_ssl_accept_fail.t 
Sending        t/spamd_ssl_accept_fail.t
Transmitting file data .done
Committing transaction...
Committed revision 1904818.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 8068] t/spamd_ssl_accept_fail.t failure on slow systems

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8068

Bill Cole <bi...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |billcole@apache.org
         Resolution|FIXED                       |---
             Status|RESOLVED                    |REOPENED

--- Comment #3 from Bill Cole <bi...@apache.org> ---
(In reply to Alyssa Ross from comment #2)
> In Nixpkgs we are still seeing intermittent failures of this test on systems
> under heavy load with SpamAssassin 4.0.0.
> 
> e.g. https://hydra.nixos.org/build/238455345/nixlog/2

The fix for this test failure (see revision 1904818) was simply adding a 1
second 'sleep' delay. I don't think it would be terrible to increase that delay
a little, but it would be good to have an idea of how long it needs to be.

Are you able to reproduce this reliably enough that you could test different
delays to see how long it needs to be? I'd see no issue with bumping it to 5 or
maybe even 10 seconds, but I don't have any way to reproduce the failure mode
of a heavily-loaded build system.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug 8068] t/spamd_ssl_accept_fail.t failure on slow systems

Posted by bu...@spamassassin.apache.org.
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8068

Alyssa Ross <hi...@alyssa.is> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hi@alyssa.is

--- Comment #2 from Alyssa Ross <hi...@alyssa.is> ---
In Nixpkgs we are still seeing intermittent failures of this test on systems
under heavy load with SpamAssassin 4.0.0.

e.g. https://hydra.nixos.org/build/238455345/nixlog/2

-- 
You are receiving this mail because:
You are the assignee for the bug.