drop loopback out-of-process

[cgwalters]

This one may be a good first issue: today when doing install --via-loopback, if we get killed by e.g. Ctrl-C (i.e. SIGINT) we will leak the loopback device allocation.

I've been thinking here what would be nice in general is to create a little "out of process drop" helper that could handle these external resources; it would:

• mask most signals that would otherwise be fatal
• own the resource and if the parent process died (via PR_SET_PDEATHSIG) we'd take care of dropping them

This type of flow would also be nice for temporary directories, which are also easy to leak in this way.

---

Hmm, we may also be able to stop forking /bin/losetup and instead use the ioctl APIs and only hold a file descriptor, but that's a bigger change.

[dchen5022]

Hi, I'm interested in tackling this. I'm not sure if my understanding is correct, but it seems like we need to:

1. Fork a child process
2. Mask signals in the child process
3. Have the child process create the loopback device and have the parent process wait until it is opened
4. Set up a signal handler to drop the loopback device if the parent process is killed.

Am I missing anything here?

[cgwalters]

👋 Thanks for your interest in this! One thing I'd note here is that this problem domain generalizes into a "remote process object holder + drop handler" that is independent of bootc really. Another good example of something to also do this way would be tempfile::tempdir().

I did some searching on crates.io but didn't find something exactly like this, though there are various related crates like https://lib.rs/crates/defer-drop and https://lib.rs/crates/backdrop
Basically we need a process and not a thread so we handle signals (and crashing).

I think instead of a plain fork let's do an actual fork+exec which is a lot safer and easier to manage. The downside is that data passing is a bit more complex.

[dchen5022]

Thanks so much for the clarification! So just to make sure, this would have to be a separate binary? And if we're fork+execing could this just be done with std::process::Command::spawn then?

[cgwalters]

We don't need a separate binary, but can re-exec our own binary with a new entrypoint. See the handling of bootc internals - I did something similar in this commit especially this section.

[dchen5022]

Ah ok, very interesting, thanks!