[systemd-devel] more verbose debug info than systemd.log_level=debug?
Chris Murphy
lists at colorremedies.com
Wed Mar 22 17:05:16 UTC 2017
On Tue, Mar 21, 2017 at 9:48 PM, Andrei Borzenkov <arvidjaar at gmail.com> wrote:
> 22.03.2017 00:10, Chris Murphy пишет:
>> OK so I had the idea to uninstall plymouth, since that's estensibly
>> what's holding up the remount read-only. But it's not true.
>>
>> Sending SIGTERM to remaining processes...
>> Sending SIGKILL to remaining processes...
>> Unmounting file systems.
>> Remounting '/tmp' read-only with options 'seclabel'.
>> Unmounting /tmp.
>> Remounting '/' read-only with options 'seclabel,attr2,inode64,noquota'.
>> Remounting '/' read-only with options 'seclabel,attr2,inode64,noquota'.
>> Remounting '/' read-only with options 'seclabel,attr2,inode64,noquota'.
>> All filesystems unmounted.
>
> Could you show your /proc/self/mountinfo before starting shutdown (or
> ideally just before systemd goes into uount all)? This suggests that "/"
> appears there three times there.
I'm too stupid to figure out how to get virsh console to attach to
tty9/early debug shell but here's a screen shot right as
pk-offline-update is done, maybe 2 seconds before the remounting and
reboot.
https://drive.google.com/open?id=0B_2Asp8DGjJ9NXRGTTFjSlVPSU0
>
> Result code of "remount ro" is not evaluated or logged. systemd does
>
> (void) mount(NULL, m->path, NULL, MS_REMOUNT|MS_RDONLY, options);
>
> where "options" are those from /proc/self/mountinfo sans ro|rw.
>
> Probably it should log it at least with debug level.
So I've asked over on the XFS about this, and they suggest all of this
is expected behavior under the circumstances. The sync only means data
is committed to disk with an appropriate journal entry, it doesn't
mean fs metadata is up to date, and it's the fs metadata that GRUB is
depending on, but isn't up to date yet. So the suggestion is that if
remount-ro fails, to use freeze/unfreeze and then reboot. The
difference with freeze/unfreeze and remount-ro is that freeze/unfreeze
will update fs metadata even if there's something preventing
remount-ro.
If it's useful I'll file an issue with systemd on github to get a
freeze/unfreeze inserted. remount-ro isn't always successful, and
clearly it's not ok to reboot anyway if remount-ro fails.
--
Chris Murphy
More information about the systemd-devel
mailing list