You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
How often does it reproduce? Is there a required condition?
Constantly
What is the expected behavior?
I'd expect the load to be reported correctly
What do you see instead?
Load from hypervisor exposed
Additional information
Environment is LXC, I'd assume it's due to libuv gets the actual information from the hypervisor, and not the container.
Maybe a similar approach to #27170 should be implemented, and allow a fallback to /proc/loadavg if available.
It's quite common to run applications within LXC, thus it would be nice the os package returns the correct information as seen by the container itself.
In my specific case, the load on the system is detected, and it will halt the application until load drops - since this is the wrong load returned (higher than the defined limit) the application halts more frequently than it should.
The text was updated successfully, but these errors were encountered:
bnoordhuis
added a commit
to bnoordhuis/libuv
that referenced
this issue
Jun 8, 2020
It was reported that uv_loadavg() reports the wrong values inside an
lxc container.
Libuv calls sysinfo(2) but that isn't intercepted by lxc. /proc/loadavg
however is because /proc is a FUSE fs inside the container.
This commit makes libuv try /proc/loadavg first and fall back to
sysinfo(2) in case /proc isn't mounted.
This commit is very similar to commit 3a1be72 ("linux: read free/total
memory from /proc/meminfo") from April 2019.
Fixes: nodejs/node#33791
It's indeed the same issue as #27170: libuv uses sysinfo(2) to obtain the load average, which LXC doesn't intercept/emulate.
I'm not going to bend libuv much further in order to make it work with LXC but I've opened libuv/libuv#2876 because it's a fairly straightforward fix.
bnoordhuis
added
libuv
Issues and PRs related to the libuv dependency or the uv binding.
linux
Issues and PRs related to the Linux platform.
labels
Jun 8, 2020
It was reported that uv_loadavg() reports the wrong values inside an
lxc container.
Libuv calls sysinfo(2) but that isn't intercepted by lxc. /proc/loadavg
however is because /proc is a FUSE fs inside the container.
This commit makes libuv try /proc/loadavg first and fall back to
sysinfo(2) in case /proc isn't mounted.
This commit is very similar to commit 3a1be72 ("linux: read free/total
memory from /proc/meminfo") from April 2019.
Fixes: nodejs/node#33791
PR-URL: libuv#2876
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Richard Lau <riclau@uk.ibm.com>
What steps will reproduce the bug?
Spawn LXC container, load reported in the container (via top or htop) will be correct, while NodeJS reports the hypervisor load:
Code example:
How often does it reproduce? Is there a required condition?
Constantly
What is the expected behavior?
I'd expect the load to be reported correctly
What do you see instead?
Load from hypervisor exposed
Additional information
Environment is LXC, I'd assume it's due to libuv gets the actual information from the hypervisor, and not the container.
Maybe a similar approach to #27170 should be implemented, and allow a fallback to
/proc/loadavg
if available.It's quite common to run applications within LXC, thus it would be nice the
os
package returns the correct information as seen by the container itself.In my specific case, the load on the system is detected, and it will halt the application until load drops - since this is the wrong load returned (higher than the defined limit) the application halts more frequently than it should.
The text was updated successfully, but these errors were encountered: