In the case of having a stale lock file on the system, usually due to an
unclean shutdown, have FEX retry if the socket for that lock file is
also not available.
This resolves the exact case of:
```
FEXBash xeyes &
kill -9 `pidof FEXMountDaemon`
sudo shutdown -r now
FEXBash xeyes & <--- This command would now fail
```
The first command would do:
- Check lock file and socket
- Spin up FEXMountDaemon
- Create Lock file and Socket file
- Start executing XEyes in FEXInterpreter
The second command would do:
- Kills the FEXMountDaemon process
- This leaves squashfuse running
- The lock file and socket file are now unmanaged and just files on the filesystem
The third command would do:
- unmounts the squashfuse mount
- Leaving a dangling folder as a mount point
The fourth command would do:
- Check for lock file and socket
- Attempt to use lock file, socket, and mount that is dangling
- Fail with error
Now instead fourth command will do:
- Check for lock file and socket
- Check if filesystem is valid
- Knows that lock file exists but socket isn't active at all
- Deletes lock file
- Spin up FEXMountDaemon
- Create Lock File and Socket File
- Start executing XEyes in FEXInterpreter
On an overburdened system then FEXMountDaemon may notrespond within the two
seconds of FEX waiting for an ack.
In this case then we hit a bad edge case where we overwrite the lock
file with a new FEXMountDaemon instance then spin up a new
FEXMountDaemon.
This new FEXMountDaemon will recognize that one is still running and
early exit, but now that we've overwritten the lock file with a new
location, all future FEX instances won't be able to find the squashfs
rootfs.
Instead, ignore that the ack wasn't received and attempt running
instead.
FEXMountDaemon should still pick up the pipe message and monitor FEX
regardless.
This fixes the `/usr not found` messages and crashes resulting from it.
Migrates lingering instances of the old logger over to fmt where
applicable. This allows removing some of the old defines and functions.
The only remaining usages of the printf-based variant of the logger is
in Tests/LinuxSyscalls/Syscalls.cpp for the strace handling.
For some reason the full container path isn't actually setup right now.
Until this problem is resolved, keep the FEX rootfs configuration
around.
This lets applications still execute albeit still wrapped with the FEX
rootfs rather than the container's
In the case of running inside of a container then we need to redirect
where we look for configuration.
Currently we only care about pressure vessel so we just redirect some
options to check inside of `/run/host/`
This will resolve an issue where installed thunks wouldn't be found.
This solves a problem where sometimes FEX would spin up a new process
while FEXMountDaemon was in the process of shutting down. Breaking
things on both sides.
Now the race conditions are squashed that I could see.
Also fixes one race where FEX is starting up and FEXMountDaemon is
spinning up. This case is where FEX managed to pull the lock file just
before it got deleted. Then sent the FEXMountDaemon a request to be
observed. With DGRAM sockets we would fire and forget. Use a STREAM with
a ack result so we know we can return.
The FEXMountDaemon no longer uses the inotify interface for refcounting
instances of FEX.
The inotify interface fails to send close events when an application
crashes. Which is either an API oversight or intentional choice.
Now to use FEXMountDaemon the FEX process must send the daemon a pipe
fd.
The FEXMountDaemon then uses the write end of the pipe to determine if
the read end of the pipe is still open. It does this using the epoll API
and ref counting how many pipes are still active.
This is possible since epoll will tell us if pipe status has changed to
error. Signalling to the write end that the read end has closed for
whatever reason.
Now we only use the "lock" file to remove races and tell the new
instances of FEX where the rootfs is mounted
This isn't quite a 100% clean sweep of IWYU.
There are some false positives where clang fails.
Additionally there are still a few missed in the frontend side of things
that I didn't get to
Instead of watching to ensure our parent process is still alive. Mount the
squashfs once and use a combination of file leases and inotify to
ref count how many processes are using the rootfs.
This makes it so in the common case, the FEXMountDaemon only ever executes once
and runs until all FEX processes stop running.
In the rare edge case there is a race condition where multiple FEXMountDaemon
applications will start, but only one will end up mounting the squashfs.
In this case, one application wins and the one that failed to grab the lease
will wait until the other one completes.
With this change, squashfs should be reasonable to use now.
This function does everything required for setting up a squashfs as a rootfs.
- Checks if the file is a valid squashfs
- Executes the FEXMountDaemon
- Error checks to ensure it was mounted correctly
- Updates CONFIG_ROOTFS to point to the mounted location
- Takes 200-400ms more startup time
Ryan Houdek