Attention LXC Team: Does a functioning /sys always exist in an LXC
container, or is it absent/disabled in some configurations?
Hi Arnaud,
Reply follows inline.
Arnaud Rebillout <arnaudr@kali.org> writes:
> Package: debootstrap
> Version: 1.0.123
> Severity: normal
> Tags: patch
> User: devel@kali.org
> Usertags: origin-kali
>
> Dear Maintainer,
>
> The code that is meant to detect if debootstrap is running from within a
> docker container is broken with cgroup v2. Talking about this particular
> function and line in the file `functions`:
>
I agree that Bullseye should have working LXC with cgroups v2, since (as
far as I know) we have new enough packages from upstream to support
it :-) Thank you for your interest and motivation to fix this!
> detect_container () {
> [...]
> elif grep -qs '[[:space:]]/docker/.*/sys/fs/cgroup' /proc/1/mountinfo; then
> CONTAINER="docker"
>
> This code only works for cgroup v1.
>
> After some research, and also after looking into the code of
> systemd-detect-virt, it seems that the right way to detect a docker
> container these days is to check for the file '/.dockerenv'.
>
> Hence I'm proposing this patch:
> https://salsa.debian.org/installer-team/debootstrap/-/merge_requests/52
>
I'm not sure that systemd-detect-virt and your patch are
forward-compatible in light of
Originally, ".dockerenv" was for transmitting the environment
variables of the container across the container boundary -- I would
not recommend relying on its existence either (IIRC, that code
you've linked to is the only reason it still exists). There's
likely something incriminatory inside /sys/fs/cgroup, but I haven't
checked recently.
https://github.com/moby/moby/issues/18355#issuecomment-220484748
This makes it sounds like ".dockerenv" may be deprecated and later
removed. It seems reasonable to contact Debian's systemd maintainer[s]
about this probable future issue, because if checking for ".dockerenv"
is robust enough for Bullseye's systemd, then it might be robust enough
for debootstrap. That said, I still wonder if this method could pose a
problem when using debootstrap, lxc, and docker from future
bullseye-backports, if ".dockerenv" support is removed sometime during
Bullseye's life-cycle.
Cgroup v2 is also mounted at /sys/fs/cgroup, so I wonder if the original
check should be rewritten to check for something under this path instead
of mountinfo? Also, using this /sys/fs/cgroup method, I'm not sure if
it's better debootstrap style to express the OR logical operator in the
regex or a shell "||" (ie: seems to be needed because the tree under
/sys/fs/cgroup is different between v1 and v2).
Thanks again!
Regards,
Nicholas
Attachment:
signature.asc
Description: PGP signature