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

[Mantas Mikulėnas]

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.

On Tue, Mar 21, 2017, 05:25 Chris Murphy <lists at colorremedies.com> wrote:

> Any thoughts on this?
>
> I've followed these instructions:
> https://freedesktop.org/wiki/Software/systemd/Debugging/
> Shutdown Completes Eventually
>
> However, no additional information is being logged that gives any
> answer to why there are three remount ro attempts, and why they aren't
> succeeding.
>
> https://github.com/systemd/systemd/blob/master/src/core/umount.c
> line 409
>
> This suggests three ro attempts shouldn't happen. And then 413 says
> that / won't actually get umounted, reboot happens leaving it ro
> mounted. So the "All filesystems unmounted." doesn't tell us anything;
> but it does seem like there should be a way to expose exit code for
> umount. I'm just not sure how to do it, and if that means compiling
> systemd myself.
>
> --
> Chris Murphy
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-- 

Mantas Mikulėnas <grawity at gmail.com>
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20170321/23dac848/attachment.html>