[systemd-devel] Confusing journal information - journal size

[David Sommerseth]

On 17/07/15 13:31, Mantas Mikulėnas wrote:
> On Fri, Jul 17, 2015 at 2:13 PM, David Sommerseth <davids at redhat.com
> <mailto:davids at redhat.com>> wrote:
> 
> 
>     Hi,
> 
>     I'm looking through some journals now, and even though I've seen it a
>     few times I haven't thought about it until now.
> 
>        systemd-journal[1151]: Runtime journal is using 8.0M (max allowed
>                  4.0G, trying to leave 4.0G free of 63.7G available →
>                  current limit 4.0G).
> 
>     Could this line be cleaned up so you don't have to look up a man page to
>     try to figure out what this really means?  Here's my uneducated guess
>     and confusion of this line:
> 
>     * Runtime journal is using 8.0M
>       - Okay, so currently the journal uses 8MB of disk-space.  No problem.
> 
>     * max allowed 4.0G
>       - Okay, so the journal should not grow beyond 4GB, makes sense.  No
>         problem.
> 
>     * trying to leave 4.0G free of 63.7G available
>       - Uhm, what!? So it will grow until there is 4GB left on the
>         filesystem?  Not so okay.
> 
> 
> It chooses the /smallest/ limit, not largest. (Common sense...) For
> example, if you had only 5 GB space available, the journal would not
> grow beyond 1 GB.
>  
> 
>     * current limit 4.0G
>       - Ehh ... okay ... so make up your mind, please!  So will the
>         journal grow until 4GB or 59.7GB.
> 
> 
> This *is* it making up its mind: "min(limit 1, limit 2) → resulting limit"
> 
>     But then I looked into /var/log/journal ...
> 
>       # du --si -s /var/log/journal/
>       4.3G  /var/log/journal/
> 
>     I do see that both system,journal and user-UID.journal are both 8.4MB,
>     and from that I can guess what the log entry tried to tell me with
>     "Runtime journal" ... but how is /that/ information useful for me, from
>     a sys-admin point of view?
> 
> 
> "Runtime" here means /run, as opposed to persistent in /var. They have
> separately configurable limits, since /run is in RAM and /var is usually
> on disk. (Though, I'm not entirely sure what purpose the runtime journal
> even serves, when /var is available.)

Fair enough.  But you are missing my point.

How this information is presented do require some detail knowledge of
the journal.  Don't think like a developer who have poked at the journal
code.  Think like a sys-admin who looks through the logs looking for
issues.  Then you want to have the answer straight in your face, not
needing to go elsewhere to read about these things.  In fact most admins
will probably have forgotten what they were going to look for when they
move their eyes of the log data.

If it is considered important information, fine.  But present it in a
far more understandable way for those who just uses the journal.  Right
now, I'm not surprised if most sys-admins read that line as useless
gibberish - "Yeah, yeah, journal will waste some space on my drive".


--
kind regards,

David Sommerseth