We need to be quite careful around changing this code, as there is a lot of history behind how we ended up with this fairly ugly FIFO solution.

The signalling model we have takes advantage of the fact thatwrite to a FIFO will block until a reader appears and then you are guaranteed to continue running. This means that multiplerunc start invocations will not block each other, and if (hypothetically)runc start crashes after opening the file descriptorrunc init will still succeed. I think we tried doing it the way you've done in this PR and there was some deadlock scenario, though this was all ~10 years ago now so I can't quite remember the details.

We used to use signals and switched to the FIFO because of lots of issues with that model (signal coalescing and pid1 has special signal semantics). That being said, I wonder ifSIGSTOP/SIGCONT would work (I think we used to use custom signals, which was a huge cause of issues).

some people read-only mount /var/run into container

This seems likeA Very Bad Idea ™️ -- unix sockets are not protected byro bind-mounts, and so if they are running a container process as root you can easily break out of the container through/var/run/docker.sock or various other sockets in/var/run (/var/run/cups/cups.sock would be fun to exploit thanks to the enormous amount of printer driver RCEs).

I can't prevent user bind /var/run into container. I find crun start will write data into the fifo. may be we can refer it.
and use this commit /run/runc/id/exec.fifo have a smaller time window will be misread.@cyphar