#1031360 rsyslog: SEGV on startup with truncated files in spool

Package:
rsyslog
Source:
rsyslog
Description:
reliable system and kernel logging daemon
Submitter:
Matthew Vernon
Date:
2026-08-19 18:13:02 UTC
Severity:
normal
Tags:
#1031360#5
Date:
2023-02-15 16:16:26 UTC
From:
To:
Hi,

We had a system fill up its root filesystem; after resolving that,
rsyslog would not start up, instead SEGVing every time.

strace showed that the SEGV was happening shortly after opening files
in /var/spool/rsyslog; moving those files away allowed rsyslog to
start up OK.

I attach a tarball of the offending files in case they help.

I assume that rsyslog is not adequately checking the spool files; I
think this is quite a significant problem, as it means log entries are
lost. Obviously they get lost when / is full, but this failure mode
means that even once that problem is fixed, rsyslog can't start up, so
log messages continue to be discarded. I considered setting serious
severity as a result, but I'll leave that to your discretion.

I think rsyslog should handle this better: either explicitly flagging
the offending file, or better by discarding a corrupt file and
recording the fact.

Thanks,

Matthew
#1031360#10
Date:
2023-02-15 17:16:10 UTC
From:
To:
Hi,

thanks for the bug report.

Am 15.02.23 um 17:16 schrieb Matthew Vernon:

Can you share your rsyslog configuration and the output of
running "rsyslogd -d -n" ?

Regards,
Michael
#1031360#17
Date:
2023-02-15 18:27:45 UTC
From:
To:
Am 15.02.23 um 18:16 schrieb Michael Biebl:

I can try to reproduce the issue once I have the full rsyslog config.
Otherwise, a backtrace (with debug symbols) would be helpful as well.

Michael
#1031360#22
Date:
2023-02-15 19:11:47 UTC
From:
To:
Am 15.02.23 um 19:27 schrieb Michael Biebl:

I'm asking because if I can't reproduce the issue myself, I would kindly
ask you to try rsyslog from bpo and if it's still reproducible there,
file the issue directly upstream at
https://github.com/rsyslog/rsyslog/issues
It's likely that they will have further questions which are best
answered by you directly.

Michael
#1031360#27
Date:
2023-02-16 15:18:13 UTC
From:
To:
Hi,

Here's a tarball of our rsyslog config (except the ssl keypair for
obvious reasons :-) ) - it's the contents of /etc/rsyslog.d and
/etc/rsyslog.lookup.d/

I've included everything for sake of completeness, but I suspect you
really only need 30-remote-syslog.conf (and maybe 40-swift.conf)

I hope this helps; the affected system is a production server where we
have limited redundancy, so I had to get it back into service ASAP.
Hopefully you can now reproduce this :)

Thanks,

Matthew
#1031360#34
Date:
2023-02-16 16:22:26 UTC
From:
To:
Hi,

Oops, rsyslog.conf would be useful as well, sorry!

Here it is.

Regards,

Matthew
#1031360#39
Date:
2023-02-16 20:48:27 UTC
From:
To:
Am 16.02.23 um 16:18 schrieb Matthew Vernon:

The important bits were in 30-remote-syslog.conf indeed. With that the
issue was reproducible and I therefor forwarded this to upstream. See
https://github.com/rsyslog/rsyslog/issues/5085

I didn't explicitly ask you, if I could attach your config files/spool
files there, but I assumed as you attached it to the Debian bug tracker,
that this is ok. If not, please let me know.
#1031360#44
Date:
2023-02-16 20:54:41 UTC
From:
To:
Hi,

Great, thank you.

Yes, that's fine.

Regards,

Matthew
#1031360#51
Date:
2026-08-19 18:10:40 UTC
From:
To:
According to upstream, this was fixed in 8.2602.0:

https://github.com/rsyslog/rsyslog/issues/5085#issuecomment-4280106115
https://github.com/rsyslog/rsyslog/pull/6739

Closing the issue for that version in Debian.

Regards,
Michael

Am 16.02.23 um 21:54 schrieb Matthew Vernon: