[systemd-devel] Confusing journal information - journal size

[Colin Guthrie]

David Sommerseth wrote on 17/07/15 14:28:
> 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".

Yeah, I can't disagree with David. Not sure how best to tidy it up, but
some rework would definitely be nice.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/