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

[Lennart Poettering]

On Mon, 10.04.17 13:43, Kai Krakow (hurikhan77 at gmail.com) wrote:

> Am Mon, 10 Apr 2017 11:04:45 +0200
> schrieb Lennart Poettering <lennart at poettering.net>:
> 
> > > 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.
> 
> It could simply thaw the FS again after freeze to somewhat improve on
> that. At least everything that should be flushed is now flushed at that
> point and grub et al should be happy.
> 
> But I wonder why filesystems not just flush the journal on remount-ro?
> It may take a while but I think that can be perfectly expected when
> rmounting ro: At least I would expect that this forces out all pending
> writes to the filesystem hence flushing the journal.

Well, the remount-ro doesn't succeed in the case this is all about:
the plymouth process appears to run off the root fs and keeps the
executable pinned, which was deleted because updated, and thus the
kernel will refuse the remount. See other mail.

> So a final freeze/thaw cycle is probably the only way to go? As it
> specifies what is needed here to be compatible with configurations that
> involve grub on complex filesystems.

A pair of FIFREEZE+FITHAW are likely to work, but it's frickin' ugly
(see other mails), and I'd certainly prefer if the fs folks would
provide a proper ioctl/syscall for the operation we need. Quite
frankly it doesn't appear like a particularly exotic operation, in
fact the operation we'd need would probably be run much more often
than the operation that FIFREEZE/FITHAW was introduced for...

Lennart

-- 
Lennart Poettering, Red Hat