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

[Chris Murphy]

On Mon, Mar 27, 2017 at 1:27 PM, Mantas Mikulėnas <grawity at gmail.com> wrote:
> On Mon, Mar 27, 2017 at 10:20 PM, Chris Murphy <lists at colorremedies.com>
> wrote:
>>
>> Ok so the dirty file system problem always happens with all pk offline
>> updates on Fedora using either ext4 or XFS with any layout; and it's
>> easy to reproduce.
>>
>> 1. Clean install any version of Fedora, defaults.
>> 2. Once Gnome Software gives notification of updates, Restart & Install
>> 3. System reboots, updates are applied, system reboots again.
>> 4. Now check the journal filtering for 'fsck' and you'll see it
>> replayed the journals; if using XFS check the filter for "XFS" and
>> you'll see the kernel did journal replace at mount time.
>>
>> Basically systemd is rebooting even though the remoun-ro fails
>> multiple times, due to plymouth running off root fs and being exempt
>> from being killed, and then reboots anyway, leaving the file system
>> dirty. So it seems like a flaw to me to allow an indefinite exemption
>> from killing a process that's holding a volume rw, preventing
>> remount-ro before reboot.
>>
>> So there's a risk that in other configurations this makes either ext4
>> and XFS systems unbootable following an offline update.
>
>
> So on the one hand it's probably a Plymouth bug or misconfiguration (it
> shouldn't mark itself exempt unless it runs off an in-memory initramfs).

OK. But does it even make sense to have a process exempt from killing,
when it's going to get killed by reboot? Seems to me once we're at
remount-ro or umount time, nothing is exempt, they need to be forcibly
killed, clean up the file system, and then reboot.


> But on the other hand, are filesystems really so fragile? Even though it's
> after a system upgrade (which updated many files), I was sure systemd at
> least tries to *sync* all remaining filesystems before reboot, doesn't it?

All sync does is flush data and the log to disk, not file system
metadata. While this is crash safe, by not either remount-ro or umount
of root fs, doing a reboot anyway is basically a crash as far as the
file system is concerned. So it has to do log recovery at next mount,
which the bootloader can't do. The bootloader depends on file system
metadata being correct.


-- 
Chris Murphy