child bwrap process is left as zombie

[DanGooding]

Hi! Apologies in advance if this isn't really a bug / my findings are wrong.

Bubblewrap clones itself to create a child, then clones again and exec's the user binary in this grandchild process. I noticed that with --unshare-pid the parent doesn't wait() for the child, so the child is left as a zombie.

I think a fix would just look like waiting for this child, since we should be able to do that from outside the pid namespace(?).

Minimal reproduction (tested on arm64-darwin):

CONTAINER=$(docker run --privileged --detach alpine:3.22 sleep 10m)
docker exec $CONTAINER apk add bubblewrap
docker exec $CONTAINER bwrap --version
docker exec $CONTAINER bwrap --unshare-pid --dev-bind / / -- echo hi
docker exec $CONTAINER ps aux

This outputs

bubblewrap 0.11.0
hi
PID   USER     TIME  COMMAND
    1 root      0:00 sleep 10m
   27 root      0:00 [bwrap]            <- this is the zombie
   29 root      0:00 ps aux

Running without --unshare-pid the process is cleaned up fine.

This isn't causing problems for me - I only noticed it because my container didn't have an init process to reap this zombie child. The workaround was just to run with docker run --init to add an init process.

[rafaeloledo]

How can i even auto close this process that is running on every game launch and consuming 8.3% on cpu?

[rafaeloledo]

It seems to be related to bottles sandboxing. When i run directly from the GUI Manager, its sandboxing automatically. When i run from bottles cli, it's not.

What is the point of WMHelper.exe consumimg 8.3% of cpu?

[zyxhere]

It seems to be related to bottles sandboxing. When i run directly from the GUI Manager, its sandboxing automatically. When i run from bottles cli, it's not.

What is the point of WMHelper.exe consumimg 8.3% of cpu?

Please take that to bottles

[mousetail]

I'm having the same issue.

I run:

bwrap --die-with-parent ...

Then kill -9 the bwrap process.

This leaves a child parented to my process ID (which is annoying to clean up) where it should have been process 0.

I think this happens because bwrap uses PR_SET_CHILD_SUBREAPER to get it's grandparents exit code, however, if it exits with SIGKILL (as happens with --die-with-parent) it is unable to clear this flag in time and thus the parent of bwrap becomes the subreaper, which is not desired.

Though there could be something entirely different going on.

What is interesting is, on my server, running Linux 6.8.0-87-generic this happens consistently with every kill but I was unable to reproduce this on my local computer with kernel version 6.16.12-1-MANJARO. So it could potentially be a kernel bug. But there where many other aspects of the production environment I couldn't easily replicate locally so it could also be caused by any of those.