mirror of
https://github.com/facebook/sapling.git
synced 2024-10-10 16:57:49 +03:00
b39f678b85
Summary: on macOS we cannot safely use `fork`. This commit replaces the use of `fork` in the startup logger subsystem. This was a little tricky to untangle; originally (prior to any of the `fork` removal efforts in this diff stack), the startup flow was to spawn a set of processes via fork: ``` edenfs (setuid) \-----edenfs (privhelper, as root) \------edenfs (daemonized) ``` The forked children take advantage of being able to implicitly pass state to the child processes from the parent. That data flow needs to become explicit when removing the fork which makes some things a little awkward. With fork removed: * `edenfs` unconditionally spawns `edenfs_privhelper` while it has root privs and before most of the process has been initialized. * That same `edenfs` process will then spawn a child `edenfs` process which starts from scratch, but that which needs to run as the real server instance * The original `edenfs` instance needs to linger for a while to remain connected to the controlling tty to pass back the startup state to the user, before terminating. This commit deletes the check that `edenfs` is started originally as root; previously the logic relied on the forked startup logger continuing past the `daemonizeIfRequested` call and simply deferring the check until after folly::init. With these changes we can't easily perform such a check without adding some extra gymnastics to pass the state around; the place where that is checked is in the spawned child of the original edenfs, which is not a privileged process and doesn't know the original euid. I don't believe this to be a great loss as we tuck `edenfs` away under the libexec dir. Reviewed By: chadaustin Differential Revision: D23696569 fbshipit-source-id: 55b95daf022601a4699274d696af419f0a11f6f2 |
||
---|---|---|
.. | ||
CMakeLists.txt | ||
fake_edenfs.cpp | ||
force_sd_booted.c | ||
fsattr.cpp | ||
TakeoverTool.cpp | ||
ZeroBlob.cpp |