How to get exit code of daemonized new-pid-ns jailed firecracker?

[kanpov]

Currently working on adding support for both jailer daemonization and separate pid namespaces to fctools and hit a major roadblock.

To support both child processes and non-children like what the jailer creates, I made an enum ProcessHandle wrapper with either a properly controlled tokio Child or a raw PID FD. Problem is, as per Linux syscall docs, waitid() on a PID FD can only be used with a child process fd and not the one made by the jailer.

So... I asynchronously epoll() with an AsyncFd<RawFd> in a separate task and send back when the process exited via a oneshot channel, but no way to get an exit code. waitid() can't be used, only epoll() with readable interest, so I basically have to pretend every time Firecracker exits it does with exit code 0, which is so obviously awful.

There was previously an issue that I can't dig up easily rn where the integration tests team decided on printing exit_code= something to the end of Firecracker output, which:

1. requires stdout parsing in a hacky way
2. requires stdout in the first place, which daemonized jailer doesn't provide

So what should I do?

[kanpov]

It would be a trivial change to just add a CLI argument to the jailer or to firecracker binary itself that would output wait status into <exec-file-name>.status when exiting, but maybe that's already possible?

[kanpov]

I found an interesting way to do this:

1. Get pid from jailer
2. Fetch pidfd via pidfd_open()
3. epoll() for read readiness on the pidfd until success meaning exit of the process
4. Try to fetch the exit status via procfs by opening /proc/[pid]/stat with the original pid and fetching the last integer value
5. If this succeeds (which I haven't actually proven ever doesn't happen), use this exit status, otherwise assume it's 0 as a fallback

This procfs approach seems to work accurately since this pseudo-init process, after its death, becomes a zombie process i.e. it's still registered within procfs and its exit status can be fetched from there.

I am reasonably satisfied with this solution and implemented it here, but I'd like to get some input on its correctness or possible alternatives from the jailer team since, so far, I haven't found any?