-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Insane cgroup mounts in /sys/fs/cgroup/systemd/libpod_parent with podman+bind mounts #94
Comments
The first potential problem here is that we're mounting libpod's cgroupfs CGroups into systemd's CGroup hierarchy. That strikes me as wrong (and potentially dangerous). Systemd CGroup support in libpod is still very much in progress, but once it is complete we might want to consider making it mandatory for oci-systemd-hook (it'll be moving to default once it's ready to match CRI-O's current default) |
Unrelated to cleanup: on start up we also seem to have a bug: the host sees 3 mounts, two on the single path and one on the double path (specific to containers created with
After the container is stopped, if these paths are manually unmounted, then the container can be restarted indefinitely, i.e, it doesn't trap itself in tripled/quad paths etc. This may explain the triple/quad path - when the container is restarted without proper cleanup it just keeps adding to the cgroup path ad inifinitum... |
The weird thing is the containers that do not use This container does not use
The host sees nothing. |
@rhatdan This definitely sounds like a separate bug than Podman not firing the cleanup hooks (unless we want a duplicated CGroup path for some reason)? I'm betting that mount propogation is the reason for only seeing this with volume mounts - we probably need to change our mount propogation to mount volumes into the container. |
Normally a non- Non-
Start a
|
Filed as #95 |
/sys/fs/cgroup/systemd/libpod_parent
has an infinite recursion after a few stop/start cycles. In fact there are 86(!) mounts as below, but only four unique mount paths. These directories don't exist and the cgroup cannot be unmounted. Furthermore, after the third time the container cannot be started. No other container can be started (even those without bind mounts).Reproducer:
single:
cgroup on /sys/fs/cgroup/systemd/libpod_parent/libpod-cd8be22a52efaed7e2790d2eb3421c00542c3eb9763bfe715c3ad23647c419e0/ctr
doubled:
cgroup on /sys/fs/cgroup/systemd/libpod_parent/libpod-cd8be22a52efaed7e2790d2eb3421c00542c3eb9763bfe715c3ad23647c419e0/ctr/libpod_parent/libpod-cd8be22a52efaed7e2790d2eb3421c00542c3eb9763bfe715c3ad23647c419e0/ctr type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,name=systemd)
tripled:
cgroup on /sys/fs/cgroup/systemd/libpod_parent/libpod-cd8be22a52efaed7e2790d2eb3421c00542c3eb9763bfe715c3ad23647c419e0/ctr/libpod_parent/libpod-cd8be22a52efaed7e2790d2eb3421c00542c3eb9763bfe715c3ad23647c419e0/ctr/libpod_parent/libpod-cd8be22a52efaed7e2790d2eb3421c00542c3eb9763bfe715c3ad23647c419e0/ctr type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,name=systemd)
quadrupled:
cgroup on /sys/fs/cgroup/systemd/libpod_parent/libpod-cd8be22a52efaed7e2790d2eb3421c00542c3eb9763bfe715c3ad23647c419e0/ctr/libpod_parent/libpod-cd8be22a52efaed7e2790d2eb3421c00542c3eb9763bfe715c3ad23647c419e0/ctr/libpod_parent/libpod-cd8be22a52efaed7e2790d2eb3421c00542c3eb9763bfe715c3ad23647c419e0/ctr/libpod_parent/libpod-cd8be22a52efaed7e2790d2eb3421c00542c3eb9763bfe715c3ad23647c419e0/ctr type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,name=systemd)
The text was updated successfully, but these errors were encountered: