Bug 874631 - RFE: allow configuration of percentage values for disk space in journald.conf
RFE: allow configuration of percentage values for disk space in journald.conf
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: systemd (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Zbigniew Jędrzejewski-Szmek
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: systemd-RFE 1247768
  Show dependency treegraph
 
Reported: 2012-11-08 09:54 EST by John Florian
Modified: 2015-07-31 09:21 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-12 07:36:19 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description John Florian 2012-11-08 09:54:48 EST
Description of problem:
According to JOURNALD.CONF(5), numerous settings (e.g., SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=) are expressed as percentages, yet systemd-journald emits error messages if the user sets one of these with a percentage.

For example, the man page says "SystemMaxUse= and RuntimeMaxUse= control how much disk space the journal may use up at maximum. Defaults to 10% of the size of the respective file system."  Yet if I have:

RuntimeMaxUse=20%

I'll get something like "Failed to parse bytes value" as a result.  It appears that the percent sign needs to be eliminated from the conf file, like:

RuntimeMaxUse=20


It might be nice if the parser could simply ignore the percent sign, which keeps the config file more readable.  Or is the absence of the percent sign supposed to indicate an absolute value and if so, what unit of measure, bytes?

Also, it would be very helpful if the man page made use of quoting or some other form of emphasis for the permissible values.  For example:

PRESENTLY:
Storage= Controls where to store journal data. One of volatile, persistent, auto and none.

PROPOSED:
Storage= Controls where to store journal data. One of "volatile", "persistent", "auto" and "none".


Version-Release number of selected component (if applicable):
systemd-195-2.fc18

How reproducible:
always
Comment 1 Jan Synacek 2015-06-12 07:36:19 EDT
I have tried to implement this and it turned out to be a bad idea. The code gets needlessly complicated as the disk space gets evaluated in multiple places, for almost no additional value. There are also other problems, like the percentage being confusing if btrfs is used and the disks are hot-plugged.
Comment 2 John Florian 2015-06-12 16:53:20 EDT
(In reply to Jan Synacek from comment #1)
> I have tried to implement this and it turned out to be a bad idea. The code
> gets needlessly complicated as the disk space gets evaluated in multiple
> places, for almost no additional value. There are also other problems, like
> the percentage being confusing if btrfs is used and the disks are
> hot-plugged.

Jan, thanks for looking into this.  Could we at least changing the wording in the man page to make this a little clearer?  I think something like the following would be better:

s/The first pair defaults to 10% and the second to 15%/The first pair defaults to 10 (percent) and the second to 15 (percent)/

Or maybe mention that these settings expect a percent value without the symbol so that if you wanted SystemMaxUse set to 42% you'd enter "SystemMaxUse=42".
Comment 3 Jan Synacek 2015-06-15 02:14:32 EDT
There may be a misunderstanding here. The values are *not* specified in percentages, they are specified in absolute values followed by a unit. The percentages mentioned in the manpage are applied only if the user specifies no value for a given option.

From journald.conf(5):

"The first pair defaults to 10% and the second to 15% of the size of the respective file system."

...

"Specify values in bytes or use K, M, G, T, P, E as units for the specified sizes (equal to 1024, 1024²,... bytes)."
Comment 4 John Florian 2015-06-15 08:59:09 EDT
Oh!  When I've read that paragraph up to now, I understood that "Specify values in bytes or use K, M, G, T, P, E as units for the specified sizes (equal to 1024, 1024²,... bytes)." applied only to SystemMaxFileSize= and RuntimeMaxFileSize=, not the rest of the settings in that same section.  Your statements in comment 1 now make much more sense to me.

What do you think of moving "Specify values in bytes or use K, M, G, T, P, E as units for the specified sizes (equal to 1024, 1024²,... bytes)." to its own paragraph just below where it appears now?  Or maybe something even more radical (below)...

I'm torn how to best present so much useful info and in what order.  I like that the page describes what each setting does before getting into the details of how you specify the values.  After all there's little point in understanding the latter if the former indicates you're reading about something irrelevant to your situation at hand.  I wonder if there's something that could be done in the header line of each section to generally indicate the expected data type and then describe each data type once in a separate section.  E.g.,

RateLimitInterval=, RateLimitBurst=    [TIME]
...

SystemMaxUse=, SystemKeepFree=, SystemMaxFileSize=, RuntimeMaxUse=, RuntimeKeepFree=, RuntimeMaxFileSize=   [SIZE]
...

UNITS OF MEASURE FOR OPTIONS

SIZE
  Values are to be specified in the following units: "K", "M", "G", "T", "P", "E" (equal to 1024, 1024²,... bytes). 

TIME
  Values are to be specified in the following units: "s", "min", "h", "ms", "us".
Comment 5 Jan Synacek 2015-06-17 03:42:17 EDT
(In reply to John Florian from comment #4)
> What do you think of moving "Specify values in bytes or use K, M, G, T, P, E
> as units for the specified sizes (equal to 1024, 1024²,... bytes)." to its
> own paragraph just below where it appears now?  Or maybe something even more
> radical (below)...

The radical solution would make the formatting really inconsistent with the rest of the manpage (and possibly with many other manpages), but I think that moving that information to a separate paragraph would improve things. I'll write a patch and we'll see.
Comment 6 Jan Synacek 2015-06-17 04:16:26 EDT
For the records, I proposed a patch upstream:

https://github.com/systemd/systemd/pull/241
Comment 7 Zbigniew Jędrzejewski-Szmek 2015-07-31 09:10:23 EDT
FTR, pull/241 landed in systemd-221.
Comment 8 John Florian 2015-07-31 09:17:13 EDT
(In reply to Zbigniew Jędrzejewski-Szmek from comment #7)
> FTR, pull/241 landed in systemd-221.

Yeah.  Unfortunately that's just a doc improvement but won't help with BZ# 1247768.
Comment 9 Zbigniew Jędrzejewski-Szmek 2015-07-31 09:19:50 EDT
Expressing those values as percentages is still the most natural way. Also, if the filesystem size or the amount of ram is not known in advance, it is the only way which allows reasonable scaling. I'll take a stab at implementing this.

Note You need to log in before you can comment on or make changes to this bug.