[Docker] LXC resource limits ignored by Docker running inside jt

[frontend-report]

Script: Docker

Reported by: @andrebrait

Guidelines

• Read and understood guidelines: yes
• Verbose mode used: yes

Issue occurs during: Initial Creation / Installation

Environment

• Linux distribution: Debian
• Proxmox version: 9.1
• Default settings: No
• Advanced settings: Yes
• Exact command: var_os='debian' bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/docker.sh)"

Description

The script sets up an LXC container in a naive way so the Docker daemon running inside it does not respect and is not aware of the resource limits you set for the LXC.

Steps to reproduce

1. Install Docker with this script. Choose a Memory limits below your maximum.
2. Open a shell inside the LXC
3. Run the following commands to see the Docker runtime cannot see the memory limits:

echo "CT sees:        $(head -1 /proc/meminfo)"
echo "container sees: $(docker run --rm alpine head -1 /proc/meminfo)"
echo "cgroup limit:   $(docker run --rm alpine cat /sys/fs/cgroup/memory.max)"

Error output

The output would be (64GB total system memory, 8GB set to the LXC, the "fixed" line is what I will propose as a solution).

broken:  MemTotal: 65648168 kB   memory.max: max
fixed:   MemTotal:  8388608 kB   memory.max: 8589934592

Additional context

Two commands that would have told you nothing — worth naming, because they're the obvious ones to reach for:

• docker info reported MemTotal=8589934592 NCPU=6the entire time it was broken. The daemon runs as a plain CT process, so it reads thelxcfs /proc/meminfo` and looks perfectly healthy while every container it starts sees 62 GiB.
• docker run --rm alpine free -m prints the host figure even after the fix is correctly applied. busybox free uses sysinfo(2), which lxcfs cannot intercept. Same for getconf _PHYS_PAGES and Node's os.totalmem().

Solution

We can use lxcfs to give containers running in Docker the proper visibility they need for their own resource consumption.

Some sources:

• https://alibaba-cloud.medium.com/kubernetes-demystified-using-lxcfs-to-improve-container-resource-visibility-86f48ce20c6
• https://dev.to/adrien77570/running-docker-in-lxc-containers-why-it-makes-sense-for-homelabs-31fa
• https://proxmox.rdem-systems.com/en/blog/docker-vm-vs-lxc-proxmox/ -> which shows why this is an antipattern

[MickLesk]

On Your Message / Link: "Docker belongs in a VM, not an LXC":
We ship both. vm/docker-vm.sh has been there the whole time — nobody is stopped from using it. Picking the LXC is a deliberate choice, not an oversight, and the trade-off is the operator's to make:

An VM has stronger isolation boundary (hardware virtualization), at the cost of a second kernel, a fixed RAM allocation, a second filesystem layer, and slower start/backup.
An LXC use shared kernel, thin provisioning, no ballooning waste, near-instant start. unprivileged + nesting means dockerd runs as root inside a user namespace, so a container escape lands in an unprivileged ct rather than on the host

A VM is the stronger boundary; that part of the argument is fair. It does not follow that the LXC path is broken or unsupported. For a homelab running trusted images, the density and overhead win is usually worth more than the delta between "userns-confined" and "hardware-virtualized."

For the record: I use an LXC in production here for nearly three years, currently hosting 12 stacks — Immich, several PostgreSQL instances, Mealie, and others. The failure modes people predict from the antipattern posts have not materialized.

So let's keep this issue on the actual finding — nested /proc visibility — rather than relitigating the deployment model. That discussion belongs in a separate thread if someone wants to have it. @andrebrait

[andrebrait]

So let's keep this issue on the actual finding — nested /proc visibility — rather than relitigating the deployment model. That discussion belongs in a separate thread if someone wants to have it. @andrebrait

@MickLesk sorry. It was not my intent. I am using it myself, after all. It's how I noticed this. I guess I ended up copy-pasting that mention when I was transferring my investigation to the issue report form.

I'm making a patch for it. I'll put it behind a toggle so people can disable it if they want.

So far I found no issues with it. I guess if you change memory limits on the running LXC you have to restart the Docker daemon and update the containers, but it's better than not having the containers know about the memory limits at all.

And indeed, most if those points in the article are moot, especially running the LXC in unprivileged mode.

[andrebrait]

FYI community-scripts/core#9