Re: Container Uptime Discussion

--XZHjzUJnrMK9LqTs
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2024/01/29 18:43:39 +1100, Craig Small wrote:
> 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 tra=
ck
> it.
>=20
> 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.
>=20
> The trick here, there are a few things to consider.
>=20
>=20
> 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.
>=20
> 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.
>=20
> I think #1 is a bad idea, prefer #3 but also see benefits of #2.
>=20


Normally I use within a container (if ps is part of the container) commands
like

  ps o etimes=3D 1

to get the uptime of the container in seconds.  Interesting would be if
the uptime command would accept an further option to specify the namespace
pid of the container to do this from outside aka the host system.  This
because for minimalist containers there is no ps included.  On the other
hand for e.g. my ghostscript namespace (ghostscriptwrap) I can use

  ps o cmd,etimes=3D 15473
  CMD                               =20
 /usr/bin/gs -dSAFER             411


> 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.
>=20
> 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.
>=20
> ### 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 additi=
on.
>=20
> 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 oth=
er
> uptime. Ideally, the formatting and therefore the sprint functions would
> not be library functions, but they are there now.
>=20
> 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
>=20
> procps_container_uptime_sprint()
>  procps_container_uptime(&up)
>  format_uptime(up, str)
>  return str
>=20
>  - Craig

Werner

--=20
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr

--XZHjzUJnrMK9LqTs
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJgBAABCABKFiEEGwa/WjgpkPvLonW+UOkNVR3Bay4FAmW40SEsFIAAAAAAFQAO
cGthLWFkZHJlc3NAZ251cGcub3Jnd2VybmVyQHN1c2UuZGUACgkQUOkNVR3Bay5r
nhAAy71q44qBeVzckRFLq/53IEbtRGLnz+0u4oG97vjDsfPajTnzgSCOJ5JhGJDf
FhGPyJ9nRRRZil+tpKvqD4Si4QoIssmc+teNZ6K4zpIO/XGk23vyFUp5t0G3T+iJ
90m9GEIFJlg1d5t8By3EP0tJYikz5ij6ruOlDVMSeqcziCL7UnOykQ+LfHvpJnC7
VSeO+6ysxbWdj9OrlvTpX0n0EmcFWifbLhW8n/ItE2EVcVc/KKv889fEyPvok0M/
inpxrT321YenrzhOTtJd53vzuoAu76UOb7gm5GhsosE5HvrbZoTsDa27z0Wf1l2X
fmixUWqd9daVDGraqMhH2ymXPv41Dho8X7QwuSsXICyVwhnHy76gyKRivyxYqd86
juj8ILe7kV16PE/W0ffxtJ1ChhxEIhqtw8IHBGVKm3RrBA+XtuL7nYFQKEWbK6pq
1ofBB7sj/UwgPj9l0HqLbrAzt8mxhbeE4rM2WjwlmvQAvM2W9b7kUiZgcrhHizbB
EeLmKdtf4QXCTRabVSJlDAefRCN5NqUnh6EntJBArKNp2JZWdgPQxu/t7BtoJDIq
pY5mtwLMLP2tpLazyuIl+qSgB7AbdyWIG3ZTYW8J5kH2cJ6k4kzQ/pEzXc4vZabQ
Qfslxgq7K+51EztZ9QfmkIbUiwTuStWP4x6tLmYboDRAWLg=
=Hh8W
-----END PGP SIGNATURE-----

--XZHjzUJnrMK9LqTs--