Re: Container Uptime Discussion

--000000000000cf1fd40610e50c7e
Content-Type: text/plain; charset="UTF-8"

On Fri, 9 Feb 2024 at 06:03, Jim Warner <[email protected]> wrote:

> So we're left with just the --help issue and possibly the following.
>
The help issue, to answer your question, should have been updated.

Under lxc, /proc/uptime is adjusted to reflect the container's proper
> uptime.  That renders TIME_ELAPSED for pid #1 useless as the task
> start_time is greater than the reported /proc/uptime * hertz.  Thus, the
> <pids> api will always return zero.
>
> If the new procps_container_uptime() function were to first check for
> the above anomaly, it could just return with the existing
> procps_uptime() seconds instead of zero otherwise.
>
I was expecting each container's uptime to have quirks, like this.

So, let me get this straight.
Get both PID1 elapsed and uptime.
If PID1 has a shorter elapsed time, then use that's its docker and
friends.  e.g. /proc/uptime is 100 seconds, PID1 etimes is 2 seconds =
uptime is 2 seconds
If PID1 has a longer elapsed time, then use that as its lxc. e.g.
/proc/uptime is 1 second, PID1 etimes is 2 seconds = uptime is 1 second.

 - Craig

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

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, 9 Feb 2024 at 06:03, Jim Warner &=
lt;<a href=3D"mailto:[email protected]">[email protected]</a>=
&gt; wrote:</div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">So we&#39;re left with just the --help issue and possibl=
y the following.<br></blockquote><div>The help issue, to answer your questi=
on, should have been updated.</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex">
Under lxc, /proc/uptime is adjusted to reflect the container&#39;s proper <=
br>
uptime.=C2=A0 That renders TIME_ELAPSED for pid #1 useless as the task <br>
start_time is greater than the reported /proc/uptime * hertz.=C2=A0 Thus, t=
he <br>
&lt;pids&gt; api will always return zero.<br>
<br>
If the new procps_container_uptime() function were to first check for <br>
the above anomaly, it could just return with the existing <br>
procps_uptime() seconds instead of zero otherwise.<br></blockquote><div>I w=
as expecting each container&#39;s uptime to have quirks, like this.</div><d=
iv><br></div><div>So, let me get this straight.</div><div>Get both PID1 ela=
psed and uptime.</div><div>If PID1 has a shorter elapsed time, then use tha=
t&#39;s its docker and friends.=C2=A0 e.g. /proc/uptime is 100 seconds, PID=
1 etimes is 2 seconds =3D uptime is 2 seconds</div><div>If PID1 has a longe=
r elapsed time, then use that as its lxc. e.g. /proc/uptime is 1 second, PI=
D1 etimes is 2 seconds =3D uptime is 1 second.<br></div></div><div class=3D=
"gmail_quote"><br></div><div class=3D"gmail_quote">=C2=A0- Craig</div><div =
class=3D"gmail_quote"><br></div></div>

--000000000000cf1fd40610e50c7e--