On 19 Oct 2021, at 13:41, Sergey Bugaev <buga...@gmail.com> wrote: > > 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.
[0] may be of interest. Jess [0]: https://bsdimp.blogspot.com/2020/07/when-unix-learned-to-reboot2.html
