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

[Kai Krakow]

Am Mon, 10 Apr 2017 13:54:27 +0200
schrieb Lennart Poettering <lennart at poettering.net>:

> 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>:
> >   
>  [...]  
> > > 
> > > 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.

Ah okay, so given that case, a journal flush even isn't attempted, it
fails right away. My first idea was that it should flush the journal
but can fail anyways. I didn't get that point. Thus my assumption that
remount-ro doesn't flush the journal.

> > 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...

Yes it's ugly and there should be a proper ioctl/syscall for the exact
semantics needed. Usually, working around such missing APIs only
results in the needed bits never implemented. I totally understand your
point. ;-)


-- 
Regards,
Kai

Replies to list-only preferred.