#1119773 rsyslog: FTBFS: FAIL imrelp-tls-cfgcmd.sh (exit status: 1)

#1119773#5
Date:
2025-10-31 11:29:40 UTC
From:
To:
Dear maintainer:

During a rebuild of all packages in unstable, this package failed to build.

Below you will find the last part of the build log (probably the most
relevant part, but not necessarily). If required, the full build log
is available here:

https://people.debian.org/~sanvila/build-logs/202510/

About the archive rebuild: The build was made on virtual machines from AWS,
using sbuild and a reduced chroot with only build-essential packages.

If you cannot reproduce the bug please contact me privately, as I
am willing to provide ssh access to a virtual machine where the bug is
fully reproducible.

If this is really a bug in one of the build-depends, please use
reassign and add an affects on src:rsyslog, so that this is still
visible in the BTS web page for this package.

Thanks.
--------------------------------------------------------------------------------
[...]
 debian/rules clean
dh clean
   dh_clean
 debian/rules binary
dh binary
   dh_update_autotools_config
   dh_autoreconf
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'

[... snipped ...]

=== Analyzing core dump #2: ./core.227410 ===
Core file type:
./core.227410: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from './tcpflood -p48863 -u openssl -Trelp-tls -acertvalid -p48863 -m1000 -x ./tls-ce', real uid: 924, effective uid: 924, real gid: 924, effective gid: 924, execfn: './tcpflood', platform: 'x86_64'
Core file size: 10788864 bytes
./diag.sh: line 1669: gdb: command not found
gdb analysis failed
./diag.sh: line 1672: gdb: command not found
gdb analysis failed for tcpflood

=== Analyzed 2 core dump(s) ===
=== Disk Space Analysis ===
Disk usage: 11% (Free: 102G)
=== System Information ===
Linux r7a-large-1761905299 6.12.48+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.48-1 (2025-09-20) x86_64 GNU/Linux
=== Linux System Status ===
Memory info:
MemTotal:       16005604 kB
MemFree:        13927164 kB
MemAvailable:   15390432 kB
=== Error Logs Collection ===
gather-check-logs.sh not found, collecting available logs manually...
No failed-tests.log found
not reporting failure as RSYSLOG_STATSURL is not set
10:25:00[1]  FAIL: Test ./imrelp-tls-cfgcmd.sh (took 1 seconds)
FAIL imrelp-tls-cfgcmd.sh (exit status: 1)

============================================================================
Testsuite summary for rsyslog 8.2510.0
============================================================================
# TOTAL: 717
# PASS:  707
# SKIP:  9
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See tests/test-suite.log for debugging.
Some test(s) failed.  Please report this to rsyslog@lists.adiscon.com,
together with the test-suite.log file (gzipped) and your system
information.  Thanks.
============================================================================
make[5]: *** [Makefile:4147: test-suite.log] Error 1
make[5]: Leaving directory '/<<PKGBUILDDIR>>/tests'
make[4]: *** [Makefile:4282: check-TESTS] Error 2
make[4]: Leaving directory '/<<PKGBUILDDIR>>/tests'
make[3]: *** [Makefile:4348: check-am] Error 2
make[3]: Leaving directory '/<<PKGBUILDDIR>>/tests'
make[2]: *** [Makefile:948: check-recursive] Error 1
make[2]: Leaving directory '/<<PKGBUILDDIR>>'
dh_auto_test: error: make -j2 check TESTSUITEFLAGS="-j2 --verbose" VERBOSE=1 returned exit code 2
============================================
   rsyslog 8.2510.0: tests/test-suite.log
============================================

# TOTAL: 717
# PASS:  707
# SKIP:  9
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

System information (uname -a): Linux 6.12.48+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.48-1 (2025-09-20) x86_64
Distribution information (/etc/os-release):
PRETTY_NAME="Debian GNU/Linux forky/sid"
NAME="Debian GNU/Linux"
VERSION_CODENAME=forky
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

.. contents:: :depth: 2

SKIP: daqueue-persist
=====================

===============================================================================
[daqueue-persist.sh]: test data persisting at shutdown
TEST is currently DISABLE because it is unstable
SKIP daqueue-persist.sh (exit status: 77)

SKIP: imuxsock_logger_ratelimit
===============================

[imuxsock_logger_ratelimit.sh]: test rate limiting with imuxsock
testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
10:17:57[0]  Test: ./imuxsock_logger_ratelimit.sh
------------------------------------------------------------
liblogging-stdlog not available - skipping test
SKIP imuxsock_logger_ratelimit.sh (exit status: 77)

SKIP: imuxsock_traillf
======================

testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
10:18:00[0]  Test: ./imuxsock_traillf.sh
------------------------------------------------------------
liblogging-stdlog not available - skipping test
SKIP imuxsock_traillf.sh (exit status: 77)

SKIP: imuxsock_ccmiddle
=======================

testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
10:18:00[0]  Test: ./imuxsock_ccmiddle.sh
------------------------------------------------------------
liblogging-stdlog not available - skipping test
SKIP imuxsock_ccmiddle.sh (exit status: 77)

SKIP: imuxsock_traillf_syssock
==============================

testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
10:18:00[0]  Test: ./imuxsock_traillf_syssock.sh
------------------------------------------------------------
liblogging-stdlog not available - skipping test
SKIP imuxsock_traillf_syssock.sh (exit status: 77)

SKIP: imuxsock_ccmiddle_syssock
===============================

testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
10:18:00[0]  Test: ./imuxsock_ccmiddle_syssock.sh
------------------------------------------------------------
Linux
liblogging-stdlog not available - skipping test
SKIP imuxsock_ccmiddle_syssock.sh (exit status: 77)

SKIP: omfwd_fast_imuxsock
=========================

testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
10:21:36[0]  Test: ./omfwd_fast_imuxsock.sh
------------------------------------------------------------
liblogging-stdlog not available - skipping test
SKIP omfwd_fast_imuxsock.sh (exit status: 77)

SKIP: sndrcv_tls_client_missing_cert
====================================

testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
10:23:14[0]  Test: ./sndrcv_tls_client_missing_cert.sh
------------------------------------------------------------
This test is under review - it seems to have some issues
SKIP sndrcv_tls_client_missing_cert.sh (exit status: 77)

SKIP: sndrcv_relp_dflt_pt
=========================

testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
10:24:15[0]  Test: ./sndrcv_relp_dflt_pt.sh
------------------------------------------------------------
relp default port 514 is privileged
need to be root to run this test - skipping
SKIP sndrcv_relp_dflt_pt.sh (exit status: 77)

FAIL: imrelp-tls-cfgcmd
=======================

testbench: TZ env var not set, setting it to UTC
------------------------------------------------------------
10:24:59[0]  Test: ./imrelp-tls-cfgcmd.sh
------------------------------------------------------------
config rstb_403615_a2046ec4qS9m_.conf is:
     1	module(load="../plugins/imdiag/.libs/imdiag")
     2	global(inputs.timeout.shutdown="60000"
     3	       default.action.queue.timeoutshutdown="20000"
     4	       default.action.queue.timeoutEnqueue="20000"
     5	       debug.abortOnProgramError="on")
     6	# use legacy-style for the following settings so that we can override if needed
     7	$MainmsgQueueTimeoutEnqueue 20000
     8	$MainmsgQueueTimeoutShutdown 10000
     9	$IMDiagListenPortFileName rstb_403615_a2046ec4qS9m.imdiag.port
    10	$IMDiagServerRun 0
    11	$IMDiagAbortTimeout 580
    12
    13	:syslogtag, contains, "rsyslogd"  ./rstb_403615_a2046ec4qS9m.started
    14	###### end of testbench instrumentation part, test conf follows:
    15
    16	module(	load="../plugins/imrelp/.libs/imrelp"
    17		tls.tlslib="openssl")
    18	input(type="imrelp" port="48863" tls="on"
    19			tls.cacert="./tls-certs/ca.pem"
    20			tls.mycert="./tls-certs/cert.pem"
    21			tls.myprivkey="./tls-certs/key.pem"
    22			tls.authmode="certvalid"
    23			tls.permittedpeer="rsyslog"
    24			tls.tlscfgcmd="Protocol=ALL,-SSLv2,-SSLv3,-TLSv1,-TLSv1.2
    25	CipherString=ECDHE-RSA-AES256-GCM-SHA384
    26	Protocol=ALL,-SSLv2,-SSLv3,-TLSv1,-TLSv1.2,-TLSv1.3
    27	MinProtocol=TLSv1.2
    28	MaxProtocol=TLSv1.2")
    29
    30	template(name="outfmt" type="string" string="%msg:F,58:2%\n")
    31	:msg, contains, "msgnum:" action(type="omfile" template="outfmt"
    32				         file=`echo $RSYSLOG_OUT_LOG`)
rsyslogd: NOTE: RSYSLOG_DEBUG_TIMEOUTS_TO_STDERR activated
rsyslogd 8.2510.0 error: invalid debug option 'nologfuncflow' - ignored
rsyslogd 8.2510.0 error: invalid debug option 'noprintmutexaction' - ignored
main Q:Reg: worker start requested, num workers currently 0
main Q:Reg: wrkr start initiated with state 0, num workers now 1
rsyslog debug: main Q:Reg: worker 0x5581ba9e73b0 started
rsyslog debug: main Q:Reg: started with state 3, num workers now 1
10:24:59[0]  rsyslogd startup indicator seen, pid  227392
waiting for file rstb_403615_a2046ec4qS9m.imdiag.port
imdiag port: 33245
rsyslogd: imrelp[48863]: error 'relpTcpRtryHandshake_ossl: Server handshake failed with 1 - Aborting handshake.', object  'lstn 48863: conn to clt 127.0.0.1/localhost' - input may not work as intended [v8.2510.0 try https://www.rsyslog.com/e/2353 ]
rsyslogd: imrelp[48863]: error 'relpTcpLastSSLErrorMsg: OpenSSL Error Stack: error:0A0000BF:SSL routines::no protocols available ', object  'lstn 48863: conn to clt 127.0.0.1/localhost' - input may not work as intended [v8.2510.0 try https://www.rsyslog.com/e/2353 ]
starting run 1
Sending 1000 messages.
error during tcpflood on port 48863! But test continues...
10:24:59 Shutting down instance 1
imdiag: wait q_empty: qsize 0 nempty 1
imdiag[33245]: 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: 0x5581ba9e7510: worker exiting
rsyslog debug: main Q:Reg/w0: thread joined
10:25:00[1]  wait on shutdown of 227392
ABORT! core file exists (maybe from a parallel run!)
/<<PKGBUILDDIR>>/tests
-rw------- 1 buildd buildd 10788864 Oct 31 10:24 core.227410
=== Core Dump Detection and Analysis ===
Searching for core dumps in:
  - Current directory: /<<PKGBUILDDIR>>/tests
  - /cores/ directory (macOS system cores)
  - Subdirectories (*.core, core.*)
=== Analyzing core dump #1: core.227410 ===
Core file type:
core.227410: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from './tcpflood -p48863 -u openssl -Trelp-tls -acertvalid -p48863 -m1000 -x ./tls-ce', real uid: 924, effective uid: 924, real gid: 924, effective gid: 924, execfn: './tcpflood', platform: 'x86_64'
Core file size: 10788864 bytes
./diag.sh: line 1669: gdb: command not found
gdb analysis failed
./diag.sh: line 1672: gdb: command not found
gdb analysis failed for tcpflood

=== Analyzing core dump #2: ./core.227410 ===
Core file type:
./core.227410: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, from './tcpflood -p48863 -u openssl -Trelp-tls -acertvalid -p48863 -m1000 -x ./tls-ce', real uid: 924, effective uid: 924, real gid: 924, effective gid: 924, execfn: './tcpflood', platform: 'x86_64'
Core file size: 10788864 bytes
./diag.sh: line 1669: gdb: command not found
gdb analysis failed
./diag.sh: line 1672: gdb: command not found
gdb analysis failed for tcpflood

=== Analyzed 2 core dump(s) ===
=== Disk Space Analysis ===
Disk usage: 11% (Free: 102G)
=== System Information ===
Linux r7a-large-1761905299 6.12.48+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.48-1 (2025-09-20) x86_64 GNU/Linux
=== Linux System Status ===
Memory info:
MemTotal:       16005604 kB
MemFree:        13927164 kB
MemAvailable:   15390432 kB
=== Error Logs Collection ===
gather-check-logs.sh not found, collecting available logs manually...
No failed-tests.log found
not reporting failure as RSYSLOG_STATSURL is not set
10:25:00[1]  FAIL: Test ./imrelp-tls-cfgcmd.sh (took 1 seconds)
FAIL imrelp-tls-cfgcmd.sh (exit status: 1)

make[1]: *** [debian/rules:94: override_dh_auto_test-arch] Error 1
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
make: *** [debian/rules:9: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
--------------------------------------------------------------------------------

#1119773#10
Date:
2025-10-31 18:22:47 UTC
From:
To:
duplicate of #1100103.
#1119773#23
Date:
2025-10-31 18:38:10 UTC
From:
To:
severity 1119773 serious
thanks

Hi. Your merge has unadvertedly downgraded the bug I reported, and I
don't think that's ok.

I will not change the severity again, but in this case I can reproduce
the problem 100% of the time, and I can offer a VM to reproduce it (as
I always do), so I believe the serious severity was fully justified.

I understand that debugging the failing test might take time and
effort, but if you are not willing to debug it, which is ok, then
please at least disable or skip it, which should not be difficult.

Thanks.

#1119773#30
Date:
2025-11-01 09:48:25 UTC
From:
To:
severity 119773 important
thanks

Am 31.10.25 um 19:38 schrieb Santiago Vila:

This was deliberately and not inadvertently.

I treat failures that do happen on non-official buildds as non-RC

If you looked at the referenced other bug report you would have noticed
that the issue has been debugged and sent upstream.
So I find your statement rather insulting and condescending when it's
apparently you who didn't spend the time to read #1100103

Michael

#1119773#37
Date:
2025-11-01 11:33:36 UTC
From:
To:
Why?

Sorry for the misunderstanding. By "debugging" I really meant
"actually findind a fix" (which did not happen in #1100103).

We don't know when (if at all) upstream will offer a fix. Some people
who try to build the package with enough disk space and enough memory
(i.e. not doing anything "wrong") can't build the package reliably.
This is why I suggest to disable the test in the meantime.

Thanks.

#1119773#42
Date:
2025-11-01 12:00:01 UTC
From:
To:
Not digging into discussion politics, but I will skip the test
upstream until the root cause is clear. IMHO the test indeed succeeds
for what it tests, the tcpflood abort is a non-intended but useful
side-failure not tests. More details in PR.

https://github.com/rsyslog/rsyslog/pull/6280

Rainer

El sáb, 1 nov 2025 a las 12:35, Santiago Vila (<sanvila@debian.org>) escribió:

#1119773#61
Date:
2026-03-10 13:41:03 UTC
From:
To:
Hello.

This is my build history for trixie on AWS instances of type
r7a.large, nothing special. I try to build it once a day to measure
how random it is, keeping the last 25 builds, and the outcome is still
100% failure rate.

Status: failed      rsyslog_8.2504.0-1_amd64-20260210T041106.168Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260211T041102.826Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260212T041010.777Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260213T041014.854Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260214T041105.740Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260215T041104.092Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260216T040918.331Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260217T041010.556Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260218T040920.613Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260219T041018.901Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260220T041104.221Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260221T041104.849Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260222T041103.571Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260223T040919.113Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260224T041012.731Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260225T041103.115Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260226T041015.937Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260227T041015.590Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260228T041105.633Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260301T041104.333Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260302T041103.262Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260303T041103.750Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260304T041102.490Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260305T041102.482Z
Status: failed      rsyslog_8.2504.0-1_amd64-20260306T041014.166Z

RC or not, this is a violation of Policy 4.2.
Can we have a fixed version in trixie, please?

Thanks.

#1119773#66
Date:
2026-03-10 13:55:28 UTC
From:
To:
Am 10.03.26 um 14:41 schrieb Santiago Vila:

If you can provide a recipe for reproducing the issue?

#1119773#71
Date:
2026-03-10 14:33:40 UTC
From:
To:
Am 10.03.26 um 14:55 schrieb Michael Biebl:

not sure what "Package relationships" has to do with this.

#1119773#76
Date:
2026-03-10 14:49:26 UTC
From:
To:
Am 10.03.26 um 15:44 schrieb Santiago Vila:

I'd rather prefer instructions how I can reproduce the issue.

#1119773#81
Date:
2026-03-10 15:01:05 UTC
From:
To:
That's not always possible or even desirable.

However, I can tell that it fails to build for me all the time
on machines with 1 and 2 CPUs of different types in the AWS cloud.

Therefore (if you insist on trying in your own machine) I would try
booting with GRUB_CMDLINE_LINUX="nr_cpus=1" or GRUB_CMDLINE_LINUX="nr_cpus=2".

I think it's likely that it will also happen to you that way (and we can
leave the VM thing as plan B).

[ BTW: While I can agree that physical machines with 1 or 2 CPUs are rare,
  that's not the case at all in the cloud. For example, I have an imap
  server on Vultr, and it has a single cpu (because I don't need
  a bigger machine), and I expect Debian to work ok in such machine
  the same way I would expect arm64 to work the same as amd64 ]

Thanks.