Bug 1378591 - RFC: Confusing names for timeout options
Summary: RFC: Confusing names for timeout options
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-22 20:12 UTC by Paulo Andrade
Modified: 2020-01-17 15:57 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-18 10:25:38 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Paulo Andrade 2016-09-22 20:12:52 UTC
Basically the same inquiry has been reported at
https://bugzilla.redhat.com/show_bug.cgi?id=1018335
[various timing parameters have an incorrect USec suffix in systemctl show output, such as RestartUSec, TimeoutUSec, etc.]

  But I would like some feedback about it, as it is
confusing to need to set TimeoutStartSec and when
querying values it shows TimeoutStartUSec. Yet, also
confusing is the fact that it is required to tell,
and it also outputs, time units, i.e. "min" for minutes
and "s" for seconds.

Comment 2 Lukáš Nykrýn 2016-09-23 08:13:07 UTC
I am not sure that I can tell you more than Lennart already wrote in the mentioned bug.

TimeoutStartSec in the unit file make sense because it is created by the user and it is practical to have seconds as a default value there.
In the other hand internally we use microseconds because that gives us better granularity. systemctl show is a low level command to display the internal things.

Maybe it would be better to display the time in microseconds in the show output, instead of converting them to human-readable values. But we are providing stability promise on output of systemctl show (so it can be used in scripts), so it is really hard to change that.

Comment 3 Jan Synacek 2016-10-18 08:56:22 UTC
Since we can neither break the API by renaming the variables nor break stability by changing the output, I'm inclined to close this bug.


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