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

[Michael Chapman]

On Mon, 10 Apr 2017, Lennart Poettering wrote:
> On Mon, 10.04.17 16:14, Michael Chapman (mike at very.puzzling.org) wrote:
>
>> On Mon, 10 Apr 2017, Chris Murphy wrote:
>>> On Sun, Apr 9, 2017 at 5:17 AM, Lennart Poettering
>>> <lennart at poettering.net> wrote:
>>>
>>>> That said, are you sure FIFREEZE is really what we want there? it
>>>> appears to also pause any further writes to disk (until FITHAW is
>>>> called).
>>>
>>>> So, I am still puzzled why the file system people think that "sync()"
>>>> isn't supposed to actually sync things to disk...
>>>
>>> https://www.spinics.net/lists/linux-xfs/msg05113.html
>>
>> Ah good, Dave actually suggests using a freeze there. A freeze without a
>> corresponding thaw should be OK if it's definitely after all processes have
>> been killed, since we're just about to reboot anyway. (Obviously we'd want
>> to avoid the whole lot when running in a container or when doing
>> kexec.)
>
> No, there is no such guarantee. We support initrds that run userspace
> stuff from the initrd at boot, that stays around in the background is
> only killed after we transition back into the initrd. And we really
> don't control what they do, they can do anything they like, access any
> file they want at any time. We added this primarily to support storage
> services backing the root file system (think iscsid, nbd, ...), but it
> actually can be anything that hsa the "feel" of a kernel component in
> being around since the time before systemd initialiazes until after
> the time it shut down again, but is actually implemented in userspace.
>
> In fact, this is precisely what plymouth is making use of: by marking
> a process with argv[0][0] = '@' we permit any privileged process to be
> excluded from the final killing spree, so that it will survive until
> the initrd shutdown transition.

This is precisely why I intend to add it _just before_ the reboot(2) call. 
Any processes that have survived that far are going to stop running a very 
short moment later anyway; it doesn't matter if they get hung on a write.

Note that I am specifically NOT talking about doing a filesystem freeze 
on the shutdown-initrd transition. That would be ludicrous.

> So no, "freeze" is not an option. That sounds like a recipe to make
> shutdown hang. We need a sync() that actually does what is documented
> and sync the file system properly.

sync() is never going to work the way you want it to work. Let's make 
systemd work correctly for the systems we have today, not some 
hypothetical system of the future.

The filesystem developers have good reasons for sync()'s current 
behaviour. I can only point out again that the way they've designed it 
does *not* lose or corrupt data: all synced data is available as soon 
as the filesystem journals have been flushed. We have to explicitly flush 
the journals ourselves, one way or another, to ensure that GRUB and other 
not-fully-Linux-compatible filesystem implementations work correctly.