Closed ui-paul-kasemir closed 2 years ago
stgraber
commented
2 years ago root@b1:~# java RuntimeDemo
Hello world!
16
root@b1:~# dpkg -l | grep jre
ii openjdk-8-jre-headless:amd64 8u312-b07-0ubuntu1~18.04 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
root@b1:~# java -version
openjdk version "1.8.0_312"
OpenJDK Runtime Environment (build 1.8.0_312-8u312-b07-0ubuntu1~18.04-b07)
OpenJDK 64-Bit Server VM (build 25.312-b07, mixed mode)
root@b1:~# 
ui-paul-kasemir
commented
2 years ago @stgraber what is your host machine running? And what version of LXD
stgraber
commented
2 years ago Ubuntu 22.04 and LXD 5.0
stgraber
commented
2 years ago Same thing on an Ubuntu 20.04 + LXD 5.0 setup
stgraber
commented
2 years ago Closing as this can't be a LXD bug anyway, LXD just sets some cpuset pinning in the kernel.
This kind of issue could come from a broken LXCFS setup. Looking at what Java is doing, it seems to expect /sys/devices/system/cpu to be readable and /sys/devices/system/cpu/online to show something that makes sense.
ui-paul-kasemir
commented
2 years ago I'm using Garuda Linux (which is an arch linux)
How can you safely close this ticket @stgraber without testing the host I'm using? Besides the fact that it is an issue with LXD. Using a pre 5.0 LXD it was working okay.
ui-paul-kasemir
commented
2 years ago Unless you are assuming LXD will only be working/supported for Ubuntu
stgraber
commented
2 years ago @ui-paul-kasemir because LXD hasn't changed the way it sets up cgroups in years and the files that are being accessed by that bit of Java are not controlled by LXD at all.
You're most likely seeing a difference in LXCFS behavior, not LXD.
stgraber
commented
2 years ago [root@archlinux ~]# cat /etc/os-release
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://bugs.archlinux.org/"
LOGO=archlinux-logo
[root@archlinux ~]# lxc exec b1 bash
root@b1:~# java RuntimeDemo
Hello world!
2
root@b1:~# dpkg -l | grep jre
ii openjdk-8-jre-headless:amd64 8u312-b07-0ubuntu1~18.04 amd64 OpenJDK Java runtime, using Hotspot JIT (headless)
root@b1:~# exit
[root@archlinux ~]# lxc config set b1 limits.cpu=1
[root@archlinux ~]# lxc exec b1 bash
root@b1:~# java RuntimeDemo
Hello world!
1
root@b1:~# @stgraber You are right. If I downgrade lxcfs it starts working again. I'll file a ticket there.
lxcfs-4.0.12-1: success :heavy_check_mark: Available processors: 16
lxcfs-5.0.0-1: fails :x: Available processors: 0
ui-paul-kasemir
commented
2 years ago @stgraber what version of lxcfs are you using?
stgraber
commented
2 years ago I'm using LXCFS 5.0.0 but with a bunch of cherry-picked fixes:
git cherry-pick 42c155d1df92d8bbabdb1de3433048584bb05d47 # lxcfs_fuse: ensure lxcfs_fuse_compat.h is included after including fuse header
git cherry-pick e297458cb0d2a5c7f91ddacc771d4cf9efe301f8 # tree-wide: remove struct stat argument from DIR_FILLER and make it static inline
git cherry-pick d58528f752aaa532eb3871899a27d66996a2a798 # tree-wide: ensure that file information is set even with legacy fuse
git cherry-pick 02beb5d4e1b82e3416988af2341142518c804bd3 # tests: add test for issue #522
git cherry-pick 112f0b9ca720b8f0da4d4a39153c16f55e3294e1 # meson: Include documentation
git cherry-pick 1ef15e0d1f345ebb851f1bab8835cace5279e392 # workflows: disable documentation generation
git cherry-pick 9d6cded612483cfb31919f306d1975ce801d8e25 # sysfs: Don't incorrectly filter entries
git cherry-pick dcc13128a03b8af4e975e65b32afc841074bedb8 # tests: Fix sysfs test
git cherry-pick 5daf75dbed117c75198e104f852fd170cac766de # utils: add and use opathdir()
git cherry-pick 2e3a6f5d8240695bd13a7a6da75de895b9407492 # sysfs_fuse: fix indendation
git cherry-pick 2e13f0be3ad903adf870e7a3032c3356c0c9e4eb # sysfs_fuse: generate file info for cpu<nr> entries as well
git cherry-pick 75395f89cf6de91695562a0a47e36acbba879c1e # meson: bump fuse version
git cherry-pick 35bf60d4eed08e703180c1f6ec505c7c91442915 # github: add fuse3 tests
git cherry-pick 006db260b1202761a6661085f7af2fd3cd7083f3 # meson: handle fuse versions with buggy dt_type handling
git cherry-pick b997ce418919137df7a4552b2b8e0d8207edbaa5 # init/meson: Use libdir instead of hardcoded /lib path
git cherry-pick a08da8d7e63a023679603a93c18b6bfc443f9471 # Query systemd system unit dir.So looks like it's something that's been fixed upstream and LXCFS 5.0.1 should then work for you once we release it.
ui-paul-kasemir
commented
2 years ago Okay, I do see that it is fixed already. I bisected the fix to: https://github.com/lxc/lxcfs/commit/2e13f0be3ad903adf870e7a3032c3356c0c9e4eb
Required information
lxc info
Issue description
The "infallible" java8 function call
Runtime.getRuntime().availableProcessors()is returning0. The docs page says:See https://www.tutorialspoint.com/java/lang/runtime_availableprocessors.htm
Howerever if using a slightly newer java version11 it works as expected
Steps to reproduce
public static void main(String[] args) {
// print a normal message System.out.println("Hello world!");
// check the number of processors available System.out.println(""+Runtime.getRuntime().availableProcessors()); } }
Information to attach
dmesg)lxc info NAME --show-log)lxc config show NAME --expanded)lxc monitorwhile reproducing the issue)