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

[Chris Murphy]

Thanks for the reply.

On Mon, Mar 20, 2017, 11:05 PM Mantas Mikulėnas <grawity at gmail.com> wrote:

> First thought: Even without the exit code or anything, it's going to be
> -EBUSY like 99.999% of the time. Not much else can fail during umount.
>
> And ”Filesystem is busy" would perfectly fit the earlier error message
> which you overlooked:
>
> "Process 304 (plymouthd) has been marked to be excluded from killing.
> It is running from the root file system, and thus likely to block
> re-mounting of the root file system to read-only."
>
> So you have a process holding / open (Plymouth is the boot splash screen
> app) and the kernel doesn't allow it to be umounted due to that.
>


a. Seems flawed to have something that can block remount to read only.
Either a flaw of Plymouth directly, or running it from root fs rather than
the initramfs.

b. This message occurs, as well as the three remount ro messages,
regardless of filesystem (volume format).

c. Only XFS is left in a dirty state following the reboot. Ext4 and Btrfs
are OK.

So I'm still left with why XFS is affected, and XFS devs want to know the
exit code.

At reboot/shutdown time, exactly what does systemd issue to the kernel to
do this?


Chris Murphy

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170321/da7778f3/attachment-0001.html>