Hello,

as suggested by Jochen (in CC:), I'm filing this bug to record the
apparent ftbfs of rsyslog. This happens inside sbuild 0.88.5 with
todays unstable.

Given enough RAM and diskspace, rsyslog compiles, but then the tests
fail in imrelp-tls-cfgcmd.sh.

With gdb installed, I get this result in test-suite.log:

| rsyslogd: imrelp[50927]: error 'relpTcpRtryHandshake_ossl: Server handshake failed with 1 - Aborting handshake.', object  'lstn 50927: conn to clt 127.0.0.1/localhost' - input may not work as intended [v8.2502.0 try https://www.rsyslog.com/e/2353 ]
| rsyslogd: imrelp[50927]: error 'relpTcpLastSSLErrorMsg: OpenSSL Error Stack: error:0A0000BF:SSL routines::no protocols available ', object  'lstn 50927: conn to clt 127.0.0.1/localhost' -
| input may not work as intended [v8.2502.0 try https://www.rsyslog.com/e/2353 ]
| starting run 1
| Sending 1000 messages.
| error during tcpflood on port 50927! But test continues...
| 21:00:48 Shutting down instance 1
| imdiag: wait q_empty: qsize 0 nempty 1
| imdiag[34869]: mainqueue empty
| DoDie called.
| rsyslogd debug: info: trying to cooperatively stop input ../plugins/imdiag/.libs/imdiag, timeout 60000 ms
| rsyslogd debug: info: trying to cooperatively stop input imrelp, timeout 60000 ms
| rsyslog debug: main Q:Reg/w0: enter WrkrExecCleanup
| rsyslog debug: 0xaaaad34ac350: worker exiting
| rsyslog debug: main Q:Reg/w0: thread joined
| 21:00:49[1]  wait on shutdown of 268852
| ABORT! core file exists (maybe from a parallel run!)
| /build/reproducible-path/rsyslog-8.2502.0/tests
| -rw------- 1 sbuild sbuild 10649600 Mar 10 21:00 core.268875
| trying to obtain crash location info
| note: this may not be the correct file, check it
|
| warning: core file may not match specified executable file.
| [New LWP 268877]
| [New LWP 268875]
| Core was generated by `./tcpflood -p50927 -u openssl -Trelp-tls -acertvalid -p50927 -m1000 -x ./tls-certs/ca.pem -z ./tls-certs/key.pem -Z ./tls-certs/cert.pem -Ersyslog -k Protocol=ALL,-S
| SLv2,-SSLv3,-TLSv1.1,-TLSv1.2\ CipherString=DHE-RSA-AES256-SHA\ Protocol=ALL,-SSLv2,-SSLv3,-TLSv1.1,-TLSv1.2,-TLSv1.3\ MinProtocol=TLSv1.1\ MaxProtocol=TLSv1.1'.
| Program terminated with signal SIGSEGV, Segmentation fault.
| #0  0x0000ffff7f807c54 in ?? ()
| [Current thread is 1 (LWP 268877)]
| #0  0x0000ffff7f807c54 in ?? ()
| #1  0x0000ffff7e48e238 in ?? ()
| Backtrace stopped: not enough registers or memory available to unwind further
| not reporting failure as RSYSLOG_STATSURL is not set
| 21:00:49[1]  FAIL: Test ./imrelp-tls-cfgcmd.sh (took 1 seconds)
| FAIL imrelp-tls-cfgcmd.sh (exit status: 1)

Upstream has at least one open issue from 2020 and newer, allegedly
fixed issues:

https://github.com/rsyslog/rsyslog/issues/4130
https://github.com/rsyslog/rsyslog/pull/4535

I tried understanding the test, but ISTM it tries to setup a TLS
configuration that cannot work. All protocols get disabled, and then
Min/MaxProtocol is set to a disabled protocol.

I don't see how OpenSSL could ever fulfill this request.

On top of that, tcpflood(.c) apparently segfaults when it cannot
connect to the specified remote.

Hope this helps,
Chris

On Tue, Mar 11, 2025 at 01:16:53PM +0100, Chris Hofstaedtler wrote:

...

I can confirm I'm hitting this too, and cowbuilder on the same host works as
expected (i.e. can't reproduce the FTBFS)

Hi Chris, hi Jochen !
failed so far.

I've setup sbuild following the instructions at [1].

Interestingly, debusine has trouble building rsyslog as seen at [2], but
the test suite failures are not
amd64: imrelp-tls-mixed-chainedcert
arm64: sndrcv_relp_tls
armel: imrelp-tls-mixed-chainedcert, imrelp-tls-cfgcmd
armhf: imrelp-tls-mixed-chainedcert, imrelp-tls-mixed-chainedcert2,
imrelp-tls-cfgcmd
i386: imrelp-tls-mixed-chainedcert

The results are a bit mixed and I don't yet see a pattern. Not being
able to reproduce the issue makes it hard to debug this further or raise
this upstream.

Any ideas what's missing so I can trigger those test failures?

Michael


[1] https://wiki.debian.org/sbuild
[2] https://debusine.debian.net/debian/developers/work-request/206678/

Hi again,

thanks to Jochen's help, we got a bit further investigation the test
suite failure.

It appears, one needs to have kernel.core_pattern set to "core" for the
test to actually fail, otherwise the test-suite.sh (wrongly) assumes the
test was successful (see also the two attached test runs, one with
systemd-coredump being set as coredump handler, the other with "core"
being set)

It so happens that I had systemd-coredump installed (it was dragged in
via plasma-workspace depends drkonqi recommends systemd-coredump)

sbuild/unshare does not seem to be necessary to trigger this test failure.

So we have two issues here afaics:
a/ imrelp-tls-cfgcmd.sh triggering a segfault in tcpflood/librelp
b/ the testsuite requiring a ./core file to properly detect a test failure.


I'll raise both issues with upstream now that we have found how to
reproduce the problem.



Regards
Michael

Am 25.10.25 um 14:57 schrieb Michael Biebl:

Running dh_auto_test with --no-parallel, the results are more reliable:

https://debusine.debian.net/debian/developers/work-request/214419/

All now fail reliably in imrelp-tls-cfgcmd.

When run in parallel mode, the existence of a core file can confuse the
test-suite to mark a test as failed even though it actually hasn't.

Another mystery solved.

I'll enable "--no-parallel" in the next rsyslog upload.

Michael