cgroups版本冲突是老旧应用在新内核docker中出错的主因：linux 5.0+默认启用cgroups v2，而旧版java、node.js等运行时依赖cgroups v1接口，导致资源识别异常、oom误触发或启动失败。
老旧应用在新内核上运行 Docker 时出错，多数不是 Docker 本身崩溃，而是容器内进程（尤其是 JVM、Node.js 等运行时）与新内核特性或 cgroups v2 行为不兼容导致的隐性故障。排查要从“容器内行为”和“宿主机内核/Docker 配置”两个层面交叉验证。
确认是否是 cgroups 版本冲突
Linux 5.0+ 默认启用 cgroups v2，而许多旧版 Java（
- 检查宿主机当前 cgroups 版本：
cat /proc/1/cgroup | head -1，若输出含0::/表示使用 cgroups v2 - 进入容器执行：
cat /proc/1/cgroup，对比路径格式。若宿主机是 v2，但容器内仍看到cpu,cpuacct:/docker/xxx类 v1 路径，说明 Docker 未透传 v2 支持 - 临时降级到 cgroups v1（测试用）：启动内核参数加
systemd.unified_cgroup_hierarchy=0，或在/etc/docker/daemon.json中添加：{"exec-opts": ["native.cgroupdriver=cgroupfs"]}，然后重启 Docker
检查 Java 类应用的内存与 CPU 感知异常
Java 8u212 之前版本无法正确读取容器内存限制，常表现为 OOMKilled 却无堆栈日志；Java 10+ 已默认支持容器感知，但需显式启用（部分旧镜像未开启）。
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 运行容器时强制启用容器感知：
docker run -m 1g --cpus 2 openjdk:8-jre-slim java -XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 -version - 验证 JVM 是否识别限制：
docker exec -it jstat -gc $(pgrep java)，观察max heap是否接近 -m 设置值（而非宿主机总内存） - 若仍按宿主机内存计算堆大小，说明 JDK 版本过低或未启用
-XX:+UseContainerSupport
验证内核模块与存储驱动匹配性
新内核（如 6.x）可能移除了旧模块（如 aufs），或 overlay2 对 ext4/xfs 的挂载选项更严格，导致镜像加载失败或容器启动卡住。
- 查看 Docker 实际使用的存储驱动：
docker info | grep "Storage Driver" - 检查 overlay2 依赖的内核模块是否加载：
lsmod | grep -E "(overlay|overlayfs)"；若无输出，运行sudo modprobe overlay - 确认文件系统支持 d_type（overlay2 必需）：
findmnt -D | grep "/var/lib/docker"，输出中应含ftype=1。若为 0，需重新格式化为支持 ftype 的 xfs 或 ext4
抓取底层系统调用与日志线索
很多“无声失败”（如容器秒退、进程无日志退出）需要绕过应用层直接看系统反馈。
- 用
strace跟踪容器 init 进程：docker run --cap-add=SYS_PTRACE -it ubuntu:20.04 strace -f -e trace=clone,execve,mmap,openat sh -c 'sleep 1' - 查内核拒绝原因：
dmesg -T | grep -i "docker\|oom\|cgroup"，重点关注CapabilityBoundingSet、memory.oom_control相关报错 - 检查容器 runtime 日志：
journalctl -u docker --since "1 hour ago" | grep -A5 -B5 "error\|fail"
