2 ms·

> It's not totally obvious to me why this would impact other non-FUSE filesystems. Anything filesystem that involves writing to another process, possibly a dis

> It's not totally obvious to me why this would impact other non-FUSE filesystems. Anything filesystem that involves writing to another process, possibly a distant one (think NFS) will be susceptible to this. Generally this wouldn't be a problem because init would normally be init, and it wouldn't have any open FDs for remote files (unless it was a diskless boot), and it wouldn't exit (because init never exits, and historically init exiting/dying would cause Unixes to panic), so this doesn't usually come up. But containers can break all these assumptions since you can have applications be init. And if applications-as-init start helper daemons for FUSE or whatever, they need to clean up in order, and if they don't then bad things happen. In this case the application being init caused the kernel to kill all the other processes in the namespace when the application exited. Apps-as-init can always fail to exit cleanly by crashing, and that shouldn't cause unkillable zombies. The fix described is correct: allow flushing during exit to fail, since that could always happen (e.g., ENOSPC). Better than waiting forever for a flush that can't complete.

loeg 3y ago
> Generally this wouldn't be a problem because init would normally be init, and it wouldn't have any open FDs for remote files (unless it was a diskless boot), and it wouldn't exit (because init never exits, and historically init exiting/dying would cause Unixes to panic), so this doesn't usually come up. I mean, the kernel cannot rely on any userspace process to do anything -- even init. Even ignoring containers. I don't think the root cause here is even init related -- that's just what caused flush to hang forever in this situation, but as you point out that could happen for any number of reasons. > Apps-as-init can always fail to exit cleanly by crashing, and that shouldn't cause unkillable zombies. Right. > The fix described is correct: allow flushing during exit to fail, since that could always happen (e.g., ENOSPC). Better than waiting forever for a flush that can't complete. Sure. You could also do an interruptible flush before blocking signals instead of after.

loeg 3y ago

> Generally this wouldn't be a problem because init would normally be init, and it wouldn't have any open FDs for remote files (unless it was a diskless boot), and it wouldn't exit (because init never exits, and historically init exiting/dying would cause Unixes to panic), so this doesn't usually come up. I mean, the kernel cannot rely on any userspace process to do anything -- even init. Even ignoring containers. I don't think the root cause here is even init related -- that's just what caused flush to hang forever in this situation, but as you point out that could happen for any number of reasons. > Apps-as-init can always fail to exit cleanly by crashing, and that shouldn't cause unkillable zombies. Right. > The fix described is correct: allow flushing during exit to fail, since that could always happen (e.g., ENOSPC). Better than waiting forever for a flush that can't complete. Sure. You could also do an interruptible flush before blocking signals instead of after.