The error shows that it require prlimit but I am using kernel 2.6.32 which have util-linux 2.17 but prlimit(1) the user space program was added to util-linux 2.21 to make use of the prlimit(2) syscall available and available since Linux kernel 2.6.36.
Your still compiling from the wrong branch! There’s no process limit support in stable-1.0, the LXC tools are not located in a subfolder called tools and a bunch of other give aways. As I said you need to switch to the correct branch before compiling. Once again, please do:
git clone https://github.com/lxc/lxc.git
cd lxc
git checkout -b local/stable-1.0 origin/stable-1.0
./autogen.sh
./configure --enable-tests --prefix=/usr/ --sysconfdir=/etc/ --localstatedir=/var/" in /build/
make
You just created a CentOS container (release=6, arch=amd64, variant=default)
To enable sshd, run: yum install openssh-server
For security reason, container images ship without user accounts
and without a root password.
Use lxc-attach or chroot directly into the rootfs to set a root password
or create user accounts.
lxc_container: confile.c: parse_line: 1750 unknown key lxc.pty.max
lxc_container: parse.c: lxc_file_for_each_line: 57 Failed to parse config: lxc.pty.max = 1024
You’re doing something really weird since lxc.pty.max is a config key that has been introduced in LXC 2.1. That can’t possibly work with stable-1.0. You’re mixing LXC versions it seems. Why is your common.conf in a new format? That indicates that you either had a newer LXC version installed and not properly removed or still have it installed.
Please show the contents of /usr/local/share/lxc/config/common.conf.
It’s usually higher but there’s no reason why we shouldn’t be able to make this work. I’m confused why the file-lock won’t work though. Where did you compile the library? You should do:
[root@testnode8 lxc]# git checkout 2018-05-28/enable_pre_setns_kernels-II
Branch 2018-05-28/enable_pre_setns_kernels-II set up to track remote branch 2018-05-28/enable_pre_setns_kernels-II from origin.
Switched to a new branch ‘2018-05-28/enable_pre_setns_kernels-II’
[root@testnode8 lxc]# ./autogen.sh
test -d autom4te.cache
aclocal -I config
autoheader
autoconf
automake --add-missing --copy
configure.ac:31: installing config/compile' configure.ac:30: installing config/config.guess’
configure.ac:30: installing config/config.sub' configure.ac:29: installing config/install-sh’
configure.ac:29: installing config/missing' src/lua-lxc/Makefile.am: installing config/depcomp’
[root@testnode8 lxc]# ./configure --enable-tests --prefix=/usr/ --sysconfdir=/etc/ --localstatedir=/var/
checking for pkg-config… /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0… yes
checking for a BSD-compatible install… /usr/bin/install -c
checking whether build environment is sane… yes
checking for a thread-safe mkdir -p… /bin/mkdir -p
checking for gawk… gawk
checking whether make sets $(MAKE)… yes
checking build system type… x86_64-unknown-linux-gnu
checking host system type… x86_64-unknown-linux-gnu
Is there any way I can get access to one of those machines?
I suspect that the LD_LIBRARY_PATH is either not picked up.
The easiest way to test this properly would be to build a distro specific
package with my patch applied.
The problem is that right now I’m poking in the dark.