Container Uptime Discussion

--0000000000008bacb0061010ce73
Content-Type: text/plain; charset="UTF-8"

Hello All,
  Debian bug #827171 [1] asked if it was possible to show the containers
uptime, rather than the system uptime. I then raised issue 300 [2] to track
it.

So this email is to bring discussion about what is the best way with this
feature. I think its a worthwhile feature; knowing the uptime of your
container you are in.

The trick here, there are a few things to consider.


System or Container Selection
Or in other words, how should uptime and w decide which uptime to show?
There are three options:
#1 The library makes the decision
#2 There is an environment variable that sets it
#3 There is a new command line option for w and uptime, not sure what to do
with top here.

I don't like #1 because if the library magic is not magic enough, you get
strange results. It does mean the API would remain the same.
#2 also means the API remains the same, but you can't select which one on
the fly.
#3 means the user is explicit about which uptime they are after, but there
are fiddly API changes.

I think #1 is a bad idea, prefer #3 but also see benefits of #2.



Obtaining container uptime
Not sure of all container methods, but `PIDS_TIME_ELAPSED` of pid 1 would
seem to be the most reliable. stat'ing /dev/pty seems a bit hacky and
possibly a way of getting around it.

For idle time, I'm not even sure that makes sense for a container. If
someone can think of a metric here, I'd love to hear it. However, for most
applications, we don't display this value now so whatever it is, it better
be a cheap function to get it.

### API changes
The uptime (and idle) values come from procps_uptime() which simply parses
/proc/uptime. There could be a procps_container_uptime() which set the
uptime and idle values, this is a simple API change because its an addition.

top, uptime and w use the uptime functions procps_uptime_sprint() and
procps_uptime_sprint_short(). The issue is both functions call
procps_uptime() inside, giving no opportunity to tell them to use the other
uptime. Ideally, the formatting and therefore the sprint functions would
not be library functions, but they are there now.

My idea for now is to have two new sprint functions, move the formatting
into a common internal function which they call. Something like
procps_uptime_sprint()
  procps_uptime(&up)
  format_uptime(up, str)
  return str

procps_container_uptime_sprint()
 procps_container_uptime(&up)
 format_uptime(up, str)
 return str

 - Craig



1: https://bugs.debian.org/827171
2: https://gitlab.com/procps-ng/procps/-/issues/300
-- 

Craig Small             https://dropbear.xyz/  csmall at : dropbear.xyz
Debian GNU/Linux        https://www.debian.org/
<http://www.debian.org/>  csmall at : debian.org
GPG fingerprint:     5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

--0000000000008bacb0061010ce73
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello All,</div><div>=C2=A0 Debian bug #827171 [1] as=
ked if it was possible to show the containers uptime, rather than the syste=
m uptime. I then raised issue 300 [2] to track it.</div><div><br></div><div=
>So this email is to bring discussion about what is the best way with this =
feature. I think its a worthwhile feature; knowing the uptime of your conta=
iner you are in.<br></div><div><br></div><div>The trick here, there are a f=
ew things to consider.</div><div><br></div><div><br></div><div>System or Co=
ntainer Selection</div><div>Or in other words, how should uptime and w deci=
de which uptime to show?</div><div>There are three options:</div><div>#1 Th=
e library makes the decision</div><div>#2 There is an environment variable =
that sets it</div><div>#3 There is a new command line option for w and upti=
me, not sure what to do with top here.</div><div><br></div><div>I don&#39;t=
 like #1 because if the library magic is not magic enough, you get strange =
results. It does mean the API would remain the same.</div><div>#2 also mean=
s the API remains the same, but you can&#39;t select which one on the fly.<=
/div><div>#3 means the user is explicit about which uptime they are after, =
but there are fiddly API changes.<br></div><div><br></div><div>I think #1 i=
s a bad idea, prefer #3 but also see benefits of #2.<br></div><div><br></di=
v><div><br></div><div><br></div><div>Obtaining container uptime<br>Not sure=
 of all container methods, but `PIDS_TIME_ELAPSED` of pid 1 would seem to b=
e the most reliable. stat&#39;ing /dev/pty seems a bit hacky and possibly a=
 way of getting around it.<br><br>For idle time, I&#39;m not even sure that=
 makes sense for a container. If someone can think of a metric here, I&#39;=
d love to hear it. However, for most applications, we don&#39;t display thi=
s value now so whatever it is, it better be a cheap function to get it.<br>=
<br>### API changes</div><div>The uptime (and idle) values come from procps=
_uptime() which simply parses /proc/uptime. There could be a procps_contain=
er_uptime() which set the uptime and idle values, this is a simple API chan=
ge because its an addition.</div><div><br></div><div>top, uptime and w use =
the uptime functions procps_uptime_sprint() and=C2=A0 procps_uptime_sprint_=
short(). The issue is both functions call procps_uptime() inside, giving no=
 opportunity to tell them to use the other uptime. Ideally, the formatting =
and therefore the sprint functions would not be library functions, but they=
 are there now.</div><div><br></div><div>My idea for now is to have two new=
 sprint functions, move the formatting into a common internal function whic=
h they call. Something like</div><div>procps_uptime_sprint()</div><div>=C2=
=A0 procps_uptime(&amp;up)<br></div><div>=C2=A0 format_uptime(up, str)</div=
><div>=C2=A0 return str<br></div><div><br></div><div>procps_container_uptim=
e_sprint()</div><div>=C2=A0procps_container_uptime(&amp;up)</div><div>=C2=
=A0format_uptime(up, str)</div><div>=C2=A0return str</div><div><br></div><d=
iv>=C2=A0- Craig</div><div><br></div><div><br></div><div><br></div><div>1: =
<a href=3D"https://bugs.debian.org/827171">https://bugs.debian.org/827171</=
a></div><div>2: <a href=3D"https://gitlab.com/procps-ng/procps/-/issues/300=
">https://gitlab.com/procps-ng/procps/-/issues/300</a></div><span class=3D"=
gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_signa=
ture" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><pre>Craig Small =
            <a href=3D"https://dropbear.xyz" target=3D"_blank">https://drop=
bear.xyz/</a>  csmall at : <a href=3D"http://dropbear.xyz" target=3D"_blank=
">dropbear.xyz</a>
Debian GNU/Linux        <a href=3D"http://www.debian.org/" target=3D"_blank=
">https://www.debian.org/</a>  csmall at : <a href=3D"http://debian.org" ta=
rget=3D"_blank">debian.org</a>
GPG fingerprint:     5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5</pr=
e></div></div></div>

--0000000000008bacb0061010ce73--