diff options
author | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2022-08-23 04:25:54 +0200 |
---|---|---|
committer | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2022-08-23 04:25:54 +0200 |
commit | 772e292c2d47e9d93455e3c87ae0209a58a3da67 (patch) | |
tree | b75ed8330d15e3f1937c057b4573c4482e0db31c /libdiskfs/file-exec.c | |
parent | cb372e4d5ae9db30aef20150f1242392459ed808 (diff) | |
download | hurd-772e292c2d47e9d93455e3c87ae0209a58a3da67.tar.gz hurd-772e292c2d47e9d93455e3c87ae0209a58a3da67.tar.bz2 hurd-772e292c2d47e9d93455e3c87ae0209a58a3da67.zip |
Fix spurious EINTR while exec() within fakeroot
The scenario is:
- process running inside fakeroot exec()s
- fakeroot forwards the exec call
- exec starts thrashing the previous process, and notably close its
ports
- the send port that pointed to fakeroot is thus closed
- fakeroot thus receives a no-senders notification
- its libports thus interrupts the current RPC on it, i.e. the exec(),
because it thinks that the caller is no more, but that was exactly the
point of the exec()...
- exec tries to interrupt its own RPCs, at best the execution will fail,
at worse the process is already thrashed and there's nothing better
than burying it for good.
The symptom is processes running inside fakeroot seeming randomly
crashing with SIGKILL.
Making fakeroot keep a send right avoids the no-senders notification,
thus the whole interruption (which was meaningless).
Diffstat (limited to 'libdiskfs/file-exec.c')
0 files changed, 0 insertions, 0 deletions