On Mon, Apr 10, 2017 at 3:04 AM, Lennart Poettering <lenn...@poettering.net> wrote:
> This is specifically the case that happened for Plymouth: the binary > probably got updated, hence the process in memory references a deleted > file, which blocks the read-only remounting, in which case we can't do > anything, and sync and remount. In my reproduce case, the offline update contained only kernel, kernel-core, and kernel-modules packages. This triggers grubby to do the modification on the grub.cfg which happens to be on /boot/grub2 on XFS. Plymouth was definitely not being updated. >> 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. -- Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
