[pkg-lxc-devel] Container doesn't start at boot time
Pierre-Elliott Bécue
peb at pimeys.fr
Fri Jul 2 10:03:02 BST 2021
Hi Ervin,
Ervin Hegedüs <airween at gmail.com> writes:
> Hi there,
>
> I have 3 LXC containers on my Debian 11 system.
>
> Each containers set up for the autostart, and the configs have a
> symlink
> under the /etc/lxc/auto.
>
> The problem is that the first and only the first container in
> the
> list does not start at system boot - sometimes. Sometimes it
> starts as well.
>
> If the container does not start automatically, I can start is
> manually without any problem.
>
> The another two containers starts as well always.
>
> I have turned on the log for that conainer, and after a failed
> start I got these lines in the log:
>
> lxc vm-mysql ... ERROR cgroup2_devices -
> cgroups/cgroup2_devices.c:bpf_program_load_kernel:348 -
> Operation not permitted - Failed to load bpf program: (null)
> lxc vm-mysql ... ERROR cgroup2_devices -
> cgroups/cgroup2_devices.c:bpf_program_cgroup_attach:382 -
> Unknown error -1 - Failed to load bpf program
> lxc vm-mysql ... ERROR cgfsng -
> cgroups/cgfsng.c:cgfsng_devices_activate:3024 - Cannot allocate
> memory - Failed to attach bpf program
> lxc vm-mysql ... ERROR start - start.c:lxc_spawn:1834 -
> Failed to setup cgroup2 device controller limits
> lxc vm-mysql ... ERROR lxccontainer -
> lxccontainer.c:wait_on_daemonized_start:859 - Received container
> state "ABORTING" instead of "RUNNING"
> lxc vm-mysql ... ERROR start - start.c:__lxc_start:1999 -
> Failed to spawn container "vm-mysql"
>
> I posted this issue in the LXC forum, but still not got any
> solution. There was an idea to check the net.core.bpf_jit_limit.
>
> The default value of this variable in Debian 11:
>
> # sysctl -a | grep net.core.bpf_jit_limit
> net.core.bpf_jit_limit = 264241152
>
> The recommended value is:
>
> net.core.bpf_jit_limit 3000000000
>
> This is a limit on the size of eBPF JIT allocations which is
> usually set
> to PAGE_SIZE * 40000. When your kernel is compiled with
> CONFIG_BPF_JIT_ALWAYS_ON=y then
> /proc/sys/net/core/bpf_jit_enable is set
> to 1 and can’t be changed. On such kernels the eBPF JIT
> compiler will
> treat failure to JIT compile a bpf program such as a seccomp
> filter as
> fatal when it would continue on another kernel. On such
> kernels the limit
> for eBPF jitted programs needs to be increased
> siginficantly.
>
> but this is what I have:
>
> # getconf PAGESIZE
> 4096
> # echo $[4096*40000]
> 163840000
>
> so as I see the default value (264241152) is greater than the
> "expected"
> value (163840000).
>
> I'm not sure the problem is the bpf_jit_limit variable, my
> assumption is some dependency problem: eg. a process/service,
> which
> starts later than the first container would start - so, it is
> rather a Debian specific issue than LXC.
>
> What do you think? Do you have any idea?
Considering the symptoms you describe, I'd probably look into the
boot
order of systemd services including the lxc one which is
responsible for
the autostarts AFAIR.
It's plausible that to start, a container needs something that is
not
mentioned properly as a dependency in the lxc service.
Cheers!
--
PEB
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 853 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-lxc-devel/attachments/20210702/75e56a05/attachment.sig>
More information about the Pkg-lxc-devel
mailing list