<div dir="ltr"><div dir="ltr">On Wed, Sep 25, 2019 at 6:32 AM Robert Winslow Dalpe <<a href="mailto:rwdalpe@gmail.com">rwdalpe@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>I'm trying to track down the reason for an issue I'm seeing between systemd-journald and how rsyslog where data is being truncated when read from the journal file ( <a href="https://github.com/rsyslog/rsyslog/issues/3784" target="_blank">https://github.com/rsyslog/rsyslog/issues/3784</a> ).</div><div><br></div><div>The behavior seems present in systemd 219 (on amazon linux 2 and centos 7) and not in later versions (on arch linux). I figured the truncation may be due to the default threshold for sd_journal_get_data ( <a href="https://www.freedesktop.org/software/systemd/man/sd_journal_get_data.html" target="_blank">https://www.freedesktop.org/software/systemd/man/sd_journal_get_data.html</a> ). From what I can tell, it looks like the only time sd_journal_get_data uses the threshold is when calling `decompress_blob` ( <a href="https://github.com/systemd/systemd/blob/a88abde72169ddc2df77df3fa5bed30725022253/src/journal/sd-journal.c#L1916" target="_blank">https://github.com/systemd/systemd/blob/a88abde72169ddc2df77df3fa5bed30725022253/src/journal/sd-journal.c#L1916</a> ). `decompress_blob` looks to see if the data is compressed using XZ or LZ4 and then decompresses appropriately ( <a href="https://github.com/systemd/systemd/blob/a88abde72169ddc2df77df3fa5bed30725022253/src/journal/compress.c#L214" target="_blank">https://github.com/systemd/systemd/blob/a88abde72169ddc2df77df3fa5bed30725022253/src/journal/compress.c#L214</a> ). It looks like only the XZ decompression code utilizes the threshold (`dst_max`--which contains the threshold value--is unused in `decompress_blob_lz4`).</div><div><br></div><div>>From what I can tell LZ4 compression is the default. Assuming I'm on the right track, I'm trying to determine how XZ decompression would be invoked. That led me to the RPM that centos7 (and thus presumably amazon linux 2) builds for systemd. That RPM applies the following patch: <a href="https://git.powerel.org/powerel7/base/src/commit/e9d94968812dc1b501e6c691ee8c01595d77f76d/SOURCES/0575-Add-support-to-read-lz4-compressed-journals.patch" target="_blank">https://git.powerel.org/powerel7/base/src/commit/e9d94968812dc1b501e6c691ee8c01595d77f76d/SOURCES/0575-Add-support-to-read-lz4-compressed-journals.patch</a>  Although the patch says it "adds support to read lz4 compressed journals," it looks to me like it is actually making XZ compression the default by removing several preprocessor directives that would allow for LZ4 compression/decompression. Am I interpreting that patch correctly? Does any of what I've said seem even close to sane? I realize I can remove that patch and try building an RPM myself, but I'm hoping someone might know enough to provide any quick feedback before I go down that road.</div></div></blockquote><div><br></div><div>Without the patch, XZ is already the default. The patch adds LZ4 decompression support, but tries to avoid making LZ4 the *default* format for compression, making sure that e.g. compress_lz4 remains NULL despite the LZ4 library being present. (I'm guessing one reason is that the LZ4 library already changed its framing format once, and CentOS wants to stick with the stable xz format?)</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>