Bug 1378591

Summary:	RFC: Confusing names for timeout options
Product:	Red Hat Enterprise Linux 7	Reporter:	Paulo Andrade <pandrade>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED CANTFIX	QA Contact:	qe-baseos-daemons
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2	CC:	jsynacek, myamazak, systemd-maint-list
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-10-18 10:25:38 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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.