ulimit default too low

[moto-timo]

In the base containers, ulimit is set to 1024 (yes, I realize this is the docker default).

This is too low and caused (at least) ninja to fail to compile:

ERROR: Logfile of failure stored in: /srv/build/ttorling/poky-pyrex/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/temp/log.do_compile.28230 Log data follows: | DEBUG: Executing shell function do_compile | [1/31] RE2C src/depfile_parser.cc | [2/31] INLINE build/browse_py.h | [3/31] RE2C src/lexer.cc | [4/31] CXX build/debug_flags.o | [5/31] CXX build/disk_interface.o | FAILED: build/disk_interface.o | g++ -MMD -MT build/disk_interface.o -MF build/disk_interface.o.d -g -Wall -Wextra -Wno-deprecated -Wno-missing-field-initializers -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe '-DNINJA_PYTHON="python3"' -O2 -DNDEBUG -DUSE_PPOLL -DNINJA_HAVE_BROWSE -I. -isystem/srv/build/ttorling/poky-pyrex/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/recipe-sysroot-native/usr/include -O2 -pipe -isystem/srv/build/ttorling/poky-pyrex/build/tmp/work/x86_64-linux/ninja-native/1.10.0-r0/recipe-sysroot-native/usr/include -O2 -pipe -c src/disk_interface.cc -o build/disk_interface.o | In file included from /usr/include/c++/7/cstdlib:75:0, | from /usr/include/c++/7/ext/string_conversions.h:41, | from /usr/include/c++/7/bits/basic_string.h:6361, | from /usr/include/c++/7/string:52, | from /usr/include/c++/7/stdexcept:39, | from /usr/include/c++/7/array:39, | from /usr/include/c++/7/tuple:39, | from /usr/include/c++/7/bits/stl_map.h:63, | from /usr/include/c++/7/map:61, | from src/disk_interface.h:18, | from src/disk_interface.cc:15: | /usr/include/stdlib.h:25:10: fatal error: /usr/include/x86_64-linux-gnu/bits/libc-header-start.h: Too many open files | #include <bits/libc-header-start.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | compilation terminated. | [6/31] CXX build/ninja.o | FAILED: build/ninja.o

This is on CentOS 8.1, latest master of poky, latest pyrex. Default in CentOS 8.1 is podman, so it is possible that is a factor, but I would be skeptical. The build machine is a dual Xeon E5-26xx so multiple tasks are running at once. If I individually run '$ bitbake ninja-native', it builds fine. But then comes a box of dominoes (binutils-native, libpcre-native, perl-native, etc). Build target is core-image-full-cmdline. If it is just a matter of a different configuration, it would handy to have that documented.

[JoshuaWatt]

@moto-timo We can set a new default value for the docker/podman command line in pyrex.ini, do you have a recommendation for a good default?

[JoshuaWatt]

Would you also mind checking what version of fuse-overlayfs you have? Since version 0.3 it looks like it would automatically bump it's own ulimit to the hard limit which solved a few problems, see https://github.com/containers/fuse-overlayfs/commit/d3729baa932bae444586ce9343bae59147ab2efb and https://github.com/containers/libpod/issues/2053

I think the sane thing to do in this case is have pyrex bump up the soft limit to match the hard limit before starting the container

[moto-timo]

Breadcrumbs for others:

(1) engine = podman in pyrex.ini (e.g. if you are using podman-docker you won't get the benefit of #47) (2) on CentOS 8.1, the only way to bump the system nofile limit is by setting: DefaultLimitNOFILE=<some number bigger than 4096> in /etc/systemd/system.conf and rebooting. Anything else you read on the Internet about /etc/security/limits.conf or /etc/security/limits.d/*.conf or pam_limits is a wild goose chase. There is also nothing about selinux getting in the way. It is systemd controlling the upper limit.

I can however confirm that the fix in #47 does indeed set the limit properly as far as pyrex/podman is concerned.

[moto-timo]

After some experimentation, it appears that 16384 is not enough but DefaultLimitNOFILE=32768 works for core-image-sato-sdk target.