rsyslog unexpected end of file on log files with OMFileZipLevel

It seems a normal behaviour. I'm not sure about closeTimeout parameter because OMFileZipLevel is usually applied to services that generates a lot of output, so I've never had a file not being written for 10 minutes (or 10 seconds btw)!

GZIP is a stream compressor, so the files are written with a header and a tail, but the tail is not written until the file is considered closed and terminated, so zcat and gunzip will complain when reaching the end of a normal gzip file that is still being written.

Using OMFileZipLevel just tells rsyslog to compress logs to a normal gzip file, so this still applies.

Using veryRobustZip rsyslog can construct gzip files composed of small blocks of gzip data concatenated one after another (which is gzip-compliant) and could allow the data to be extracted without errors with zcat or gunzip (but consult rsyslog help to check some details).

Nonetheless, I've develop gztool to easily manage compressed log files produced by rsyslog, no matter the options: you can

• continuosuly tail a .log.gz file like with tail -f for text files, using gztool -T
• extract all data even if the process sending logs is abruptly stopped and then restarted, which lead to gzip files with unreachable data for zcat/gunzip but that gztool can flawlessly extract with gztool -p
• extract data from any part of the gzip file without reading it all (which is compulsory for other tools)

Just consult the examples of use of gztool.

The question would be why it didn't happen before the upgrade: are you sure this didn't happen before with the same rsyslog configuration?