On Mon, 10.04.17 19:30, Chris Murphy (li...@colorremedies.com) wrote: > >> Remember, all of this is because there *is* software that does the wrong > >> thing, and it *is* possible for software to hang and be unkillable. It > >> would > >> be good for systemd to do the right thing even in the presence of that kind > >> of software. > > > > Yeah, we do what we can. > > > > But I seriously doubt FIFREEZE will make things better. It's just > > going to make shutdowns hang every now and then. > > My understanding is freeze isn't ignorable, it's expressly for the use > case when the disk has active processing writing and the fs must be > made completely consistent, e.g. prior to taking a snapshot. The thaw > immediately following freeze would prevent any shutdown hang. > > The point of freeze/thaw is it will cause the file system metadata > that grub depends on to know where the new grub.cfg is located, to get > committed to disk prior to reboot. If some process is still hanging > around with an open write, it doesn't really matter.
As mentioned: if you prep a patch that adds FIFREEZE+FITHAW when we remount stuff read-only, then I'd merge it, even though I think the kernel APIs for this are really broken, and it would be much preferably having a proper API for this, either exposed via the well-understood sync() syscall, or through a new ioctl, if they must. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
