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
{{ message }}
Repository navigation
os.cpus() failing on lxc containers setting cpuset.cpus to less than the host cpu count #6252
Platform: Linux 3.19.0-42-generic Improve repo description #48~14.04.1-Ubuntu SMP Fri Dec 18 10:24:49 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux (inside an LXC container)
Subsystem: os
When running inside an LXC container with cgroups setup to restrict cpuset.cpus to something less than the number of CPUs in the host machine (very common with cloud providers), accessing os.cpus() will give the following:
Because it triggers an assertion failure with an an abort it can't be caught in a try/catch in JavaScript and there really isn't a way to know if it will fail prior to calling it. A common use case for this would be getting the CPU count to use with the cluster module to determine how many instances to run.
While it may not be possible to address the underlying issue it would be helpful it if failed in a way that could be caught in a try/catch so code could be written to use sensible defaults or an alternative method in the event of failure.
#5994 is the libuv upgrade and it's been tagged for back-porting to v4.x and v5.x. I'll close, the next minor (not patch) release on those branches will have the fix.
When running inside an LXC container with cgroups setup to restrict cpuset.cpus to something less than the number of CPUs in the host machine (very common with cloud providers), accessing os.cpus() will give the following:
To reproduce you will need to run node inside an LXC container with the appropriate cpuset.cpus setting. You can then reproduce with this command:
Because it triggers an assertion failure with an an abort it can't be caught in a try/catch in JavaScript and there really isn't a way to know if it will fail prior to calling it. A common use case for this would be getting the CPU count to use with the cluster module to determine how many instances to run.
While it may not be possible to address the underlying issue it would be helpful it if failed in a way that could be caught in a try/catch so code could be written to use sensible defaults or an alternative method in the event of failure.