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