On Tue, Oct 19, 2021 at 3:18 PM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > IIRC the kernel does unmount filesystems and flushes caches before > actually rebooting.
These two comments provide some more details: "reboot doesn't sync: do that yourself before calling this." [0] "The kernel will automatically flush ATA disks and suchlike on reboot(), but the file systems need to be synced explicitly in advance." [1] [0]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/reboot.c#n309 [1]: https://github.com/systemd/systemd/blob/1eb3ef78b4df28a9e9f464714208f2682f957e36/src/systemctl/systemctl-util.c#L900-L901 To me, this reads like device-layer write caches will be flushed, but any fs-layer caches won't, nor will filesystems be actually unmounted or synced. The point of 'reboot --force --force' is to be able to programmatically reboot the system *somehow* if PID 1 is in a broken state, assuming your shell and the kernel still work well enough to run a command. To run any command on the Hurd, you'd need the root filesystem and the proc and exec servers (and maybe the auth server) to still work at least somewhat, plus of course the Mach. But maybe something else is broken, maybe /hurd/startup has crashed, maybe /servers/startup does not resolve for whatever reason (doesn't exist, broken permissions, ext2fs bugs). That's when I'd expect 'reboot-hurd --force' to be of use. Sergey
