[systemd-devel] Confusing journal information - journal size

[David Sommerseth]

On 20/07/15 17:49, Colin Guthrie wrote:
> David Sommerseth wrote on 20/07/15 16:29:
>> On 20/07/15 15:31, Anne Mulhern wrote:
[...snip...]
>>>
>>> After seeing the explanation, the best complete and correct (AFAICT) formulation I could come up with was,
>>>
>>> "Runtime journal is using 8.0M (max allowed = min(4.0G, S s.t. total memory(63.7 G) - S = 4.0 G (59.7 G), available memory (16.2 G)) = 4.0G)"
>>>
>>> which is compelled to use math speak for clarity and succinctness.
>>>
>>> Dunno how happy most sys-admins would be with that.
>>>
>>> - mulhern
>>
>> But is all that information really needed?
>>
>> If I try to see this from a sys-admin point of view there are two
>> numbers which are important to me: 1) Current state 2) Final journal
>> limit size.  From how I see it, how the journal code ends up with a
>> certain number is only useful when you're developing/debugging the
>> journal.  Remember: Less is more.
> 
> Well I guess you could just log something like:
> 
> "Runtime journal is using 8.0M (see 'journalctl status' for more info)"
> 
> Then you add a "journalctl status" verb that explained the current
> status of journal (e.g. number of files on disk and in memory, how the
> file size and rotation will work etc)
> 
> 
> That might be more practically useful, but it won't explain things as
> calculated at the time that log entry was created, so can I suggest that
> an additional "_CALCULATION" field (or soemthing similarly named) is
> added into that log message that is not shown by default but is stored)
> so that the typical administrator looking at the log out put will not
> see the detail, but it is logged.
> 
> The journalctl status command could even pull out the last messages in
> the journal (via it's message id) and then get the _CALCULATION field
> and show it in a nice, verbose way to the user.
> 
> That keeps it simple by default but has all the juicy details there
> should they be needed.
> 
> Just a thought.

+1 ... This makes a lot of sense!  I like the journalctl status
approach, as that can provide even more details with some more
explanations when needed.  But I see the benefits of having more
"hidden" fields with details.


--
kind regards,

David Sommerseth