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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel