Re: Container Uptime Discussion

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

As Kris pointed out (in an encrypted email so can't quote) I suspect the
LXC stuff is showing the correct values due to LXCFS
https://github.com/lxc/lxcfs

On Fri, 9 Feb 2024 at 07:56, Craig Small <[email protected]> wrote:

> 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
>
>

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

<div dir=3D"ltr">As Kris pointed out (in an encrypted email so can&#39;t qu=
ote) I suspect the LXC stuff is showing the correct values due to LXCFS <a =
href=3D"https://github.com/lxc/lxcfs">https://github.com/lxc/lxcfs</a></div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fr=
i, 9 Feb 2024 at 07:56, Craig Small &lt;<a href=3D"mailto:[email protected]=
yz">[email protected]</a>&gt; wrote:<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=
204);padding-left:1ex"><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]" targe=
t=3D"_blank">[email protected]</a>&gt; wrote:</div><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So we&#39;re le=
ft with just the --help issue and possibly the following.<br></blockquote><=
div>The help issue, to answer your question, should have been updated.</div=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,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>
</blockquote></div>

--0000000000008d1d970610e51c77--