On Fri, Jul 19, 2019 at 8:45 AM Uoti Urpala <uoti.urpala@xxxxxxxxxxx> wrote: > > On Thu, 2019-07-18 at 21:52 -0600, Chris Murphy wrote: > > # df -h > > ... > > /dev/mapper/live-rw 6.4G 5.7G 648M 91% / > > > > And in the log: > > 47,19636,16754831,-;systemd-journald[905]: Fixed min_use=1.0M > > max_use=648.7M max_size=81.0M min_size=512.0K keep_free=973.1M > > n_max_files=100 > > > > Why is keep_free bigger than available free space? Is that the cause > > of the vacuuming? > > The default value for keep_free is the smaller of 4 GiB or 15% of total > filesystem size. Since the filesystem is small and has less than 15% > free, it's already over the default limit. Those defaults are defined > in src/journal/journal_file.c. When over the limit, journald still uses > at least DEFAULT_MIN_USE (increased to the initial size of journals on > disk if any). But it looks suspicious that this is 1 MiB while > FILE_SIZE_INCREASE is 8 MiB - doesn't this imply that any use at all > immediately goes over 1 MiB? > > You can probably work around the issue by setting a smaller > SystemKeepFree in journald.conf. I don't really need a work around, this is live media and that file will be read only. What I need is to understand exactly why the journal vacuuming is being triggered. Either that's simply not being recorded in the journal in the first place, and must be inferred by esoteric knowledge, or the reason is in the journal that has been vacuum, and is thus lost. -- Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel