[systemd-devel] more verbose debug info than systemd.log_level=debug?

[Chris Murphy]

On Mon, Apr 10, 2017 at 3:04 AM, Lennart Poettering
<lennart at 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