search

nestybox / sysbox

An open-source, next-generation "runc" that empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs.
Apache License 2.0
2.78k stars 152 forks source link

Support writing to `/proc/sys/kernel/dmesg_restrict` inside system containers #599

Closed felipecrs closed 1 year ago

felipecrs commented 1 year ago

I'm trying to run a Home Assistant Supervised installation inside of a container, but it have some serious dependencies on host, including Systemd and Docker.

So I though: Sysbox to the rescue!

And, I stumbled upon one issue. During the installation of homeassistant-supervised.deb it tries to write to /proc/sys/kernel/dmesg_restrict which fails with permission denied.

https://github.com/home-assistant/supervised-installer/blob/a3d1502f5159170ea5c01c47c9c08121dd4d0328/homeassistant-supervised/DEBIAN/preinst#L20

Some claims that --privileged seems to work around this issue, but I think it does not work when using sysbox-run, like --runtime=sysbox-runc --privileged.

https://stackoverflow.com/questions/41171349/why-is-a-shell-within-a-docker-container-showing-dmesg-content-from-the-host

It would be really nice if Sysbox could help in this situation. :)

felipecrs commented 1 year ago

The only solution I found so far was to run:

sudo sysctl kernel.dmesg_restrict=0

Before starting the container, which is far from ideal, I think.

felipecrs commented 1 year ago

BTW, after that, Home Assistant can't be started still because:

Can't start homeassistant: 400 Client Error for http+docker://localhost/v1.41/containers/373d3210262f6a0740cfdfae295535f6332157cc703b6c9ba43fe57743c30eaa/start: Bad Request ("failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: open /proc/sys/kernel/domainname: permission denied: unknown")

It seems unable to handle /proc/sys/kernel/domainname. Maybe related to https://github.com/docker/for-linux/issues/743.