-
Notifications
You must be signed in to change notification settings - Fork 7
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
unable to detach no such process #29
Comments
Looks like CRIU fails to checkpoint the container here. Can you post a few details about your system? OS, kernel version, container image and pod config used (is this just the nginx example?). Can you also try to increase the scaledown duration a bit, something like: |
OS is Ubuntu 22.04.4 LTS in a proxmox LXC container increasing the scaledown duration didn't help |
I found some more debug output I missed last time
full debug output
|
Thanks for the full CRIU log, that helps a lot.
So the k3s node is running inside an LXC container? That might complicate things here but I'm not sure. Did you by any chance configure a seccomp default profile that enables seccomp for all containers? Regardless, can you try explicitly disabling seccomp for the nginx pod? spec:
template:
spec:
containers:
- image: nginx
name: nginx
ports:
- containerPort: 80
# add this
securityContext:
seccompProfile:
type: Unconfined
That is probably just because you ran an older version of
|
yes, the k3s node is running inside a lxc container setting seccomp to unconfined still results in the same error message,
|
I'm pretty sure this is caused by LXC applying seccomp filters to all processes running within the container. CRIU does not have the ability to ignore seccomp filters during checkpoint/restore (checkpoint-restore/criu#2143), so I'm afraid the only way to get zeropod running within that LXC container (barring other roadblocks) would be to simply disable seccomp. I have never really used/configured LXC before but it looks like disabling seccomp is not that straight-forward: https://lists.linuxcontainers.org/pipermail/lxc-users/2020-June/015265.html |
I tried disabling seccomp by providing an empty blacklist as above but it didn't change anything but I agree It's probably lxc soing something weird here |
After fixing the zeropod deployment I am facing this issue:
The process exists though
root 4050438 0.0 0.0 11416 8028 ? Ss 19:08 0:00 nginx: master process nginx -g daemon off;
The text was updated successfully, but these errors were encountered: