Hi Craig,
when using 'uptime' in containers (regardless what kind of containers),
it shows the uptime of the host system rather than the one of the container.
What we used locally here is to look at /dev/pts:
DATE_CONTAINER="$(stat -c %z /dev/pts)"
DATE_CONTAINER="$(date +%s -d"${DATE_CONTAINER}")"
UPTIME_CONTAINER="$((${DATE_HOST} - ${DATE_CONTAINER}))"
and then go on with that and calculate the uptime days/hours/minutes etc.
It would be nice if uptime could do something about this in order to be
more container friendly.
Regards,
Daniel
It _does_ work on vserver but not on lxc (and similar). 'uptime' is just a pretty-printer for /proc/uptime, you'd need to teach the kernel what a "container" means. And here's a problem: unlike vserver where containers are an in-kernel thing, lxc is merely a wrapper for chroot+cgroups+unshare. You can mix and match those yourself -- which raises the question when two processes stop being in the same "container". When their root filesystem differs? When they're in different namespaces -- but which namespace? I think the best approximation is the PID namespace -- ie, defining containers as "having separate inits". But when did the current init start? There _is_ task->real_start_time, ie, field 22 of /proc/1/stat, but it changes whenever init is exec()ed. What we'd want is the time when unshare was called, and I don't think that's stored anywhere. Thus, unless someone has a better idea, all we can get in modern containers is "time since init was started/upgraded". Meow!
severity 827171 wishlist thankyou I was tempted to close this bug and say well uptime is the system uptime (or how "old" procfs thinks the system is) and that be it. I'll leave it open but as a wishlist. I suspect it may wait for some more kernel parameters to come but who knows. Yes because there are real virtual machines and, uh, other things. The english language really fails about these sorts of things "real virtual". This is the problem in a nutshell. For a "real" server you look at /proc/uptime and use that. For something like kvm the /proc/uptime is just like a real machine, so no issue. There is also the issue around start time of processes and how this interacts with /proc/uptime and its replacement. You will get processes that start before the computer was turned on and other oddities. I'm in two minds if you want uptime the program to do this. I think there needs to be something to do it but should it be uptime or perhaps a different binary or flag. So a few things: What is considered a "container" which triggers the alterative repsonse? Adam had the idea a different init but would that be confusing? I build a container one way get one answer, build it another its a different answer. How would uptime "know" its in a container? This is tied to the first question as there may be different container types and we only want to change for some. Once uptime knows its a container it wants to change to, how does it calculate the alternative uptime? Daniel had a suggested approach but does it work for all circumstances? - Craig
severity 827171 wishlist thankyou I was tempted to close this bug and say well uptime is the system uptime (or how "old" procfs thinks the system is) and that be it. I'll leave it open but as a wishlist. I suspect it may wait for some more kernel parameters to come but who knows. Yes because there are real virtual machines and, uh, other things. The english language really fails about these sorts of things "real virtual". This is the problem in a nutshell. For a "real" server you look at /proc/uptime and use that. For something like kvm the /proc/uptime is just like a real machine, so no issue. There is also the issue around start time of processes and how this interacts with /proc/uptime and its replacement. You will get processes that start before the computer was turned on and other oddities. I'm in two minds if you want uptime the program to do this. I think there needs to be something to do it but should it be uptime or perhaps a different binary or flag. So a few things: What is considered a "container" which triggers the alterative repsonse? Adam had the idea a different init but would that be confusing? I build a container one way get one answer, build it another its a different answer. How would uptime "know" its in a container? This is tied to the first question as there may be different container types and we only want to change for some. Once uptime knows its a container it wants to change to, how does it calculate the alternative uptime? Daniel had a suggested approach but does it work for all circumstances? - Craig
Lookie here: https://github.com/lxc/lxcfs/commit/9ac264cfb0836a013af6fa31a4e4c01afe72255a And, despite the commit message mentioning only /proc/stat, it also changes /proc/uptime so all is fine as long as the host has lxcfs >= 2.0.7-1. This of course works only on containers started using lxc, rather than a zillion other chroot+cgroups+unshare wrappers, such as docker, systemd, etc. Meow!
ps -o etimes 1 will do it too The upstream libproc2 now has a feature of providing container uptime and both w and uptime have the option either as a command line or environment variable. - Craig