:: Re: [DNG] runit: unclean shutdown?
Góra strony
Delete this message
Reply to this message
Autor: Didier Kryn
Data:  
Dla: dng
Temat: Re: [DNG] runit: unclean shutdown?
Le 13/03/2023 à 16:27, Steve Litt a écrit :
> Didier Kryn said on Mon, 13 Mar 2023 10:51:06 +0100
>
>> Le 13/03/2023 à 03:47, Steve Litt a écrit :
>>> swapoff -a
>>>
>>> The preceding prevents swapping from changing any disk content...
>>>
>>> umount -r -a -t nosysfs,noproc,nodevtmpfs,notmpfs
>>>
>>> The preceding recursively unmounts all disk filesystems (as opposed
>>> to /sys, /proc, etc.)
>>>
>>> mount -o remount,ro /
>>>
>>> The preceding remounts the root partition as read-only, so further
>>> changes cannot be made to it, but its executables can still be used
>>> to perform the final shutdown tasks. Note that if /usr is a separate
>>> partition and there's no /sbin, those executables won't be available.
>>> You'll need to do some fancy copying before the mass unmount. Oh,
>>> Lennart!
>>>
>>> sync
>>>
>>> The preceding confuses me a little because my first instinct would be
>>> that sync wouldn't work on a read-only filesystem, because what sync
>>> does is write cached disk writes to disk. A quick web search yielded
>>> nothing on this subject. But perhaps sync *does* work on readonly
>>> filesystems. If that's the case, leaving out the sync would leave
>>> cached writes and perhaps would trigger a journal recovery on the
>>> next reboot. So if you haven't yet, but a sync command after you've
>>> unmounted all disk partitions and set the root partition read-only.
>>>
>>> SteveT
>>     Hi Steve.
>>
>>     I'm pretty sure umount flushes the write buffers associated to
>> the
>> given partition and, therefore, there is no need for sync before it.
> Thanks Didier, I have more questions...
>
> Does the umount -a unmount the root partition / ?


    The manual tells that 'umount -a' unmounts all filesystems listed
in /proc/mountinfo, except the pseudofilesystems like /proc itself. Note
the semantic difference with 'mount -a' which refers to /etc/fstab. And
you can verify, as Aitor showed me a few weeks ago, that the rootfs is
*not* listed in /proc/mountinfo (which causes a corner-case issue in
Hopman).

>
> If so, why the   -o remount    ? If not, the root partition wasn't
> flushed.
>
> Do you know whether sync can flush a readonly root partition?


    I'm not sure but I guess sync with no argument flushes all caches.
Only if you specify a file and --data does it flush only the file 
and/or only the data.

>
>
>
>> For what concerns 'mount -o remount,ro' , there is still the issue of
>> file metadata being modified if you don't specify noatime. I would  do
>> 'mount -o remount,ro,noatime'
> I'll do that. I'll also make /etc/fstab specify noatime on all my
> mounts. It's quite an oversight that I haven't done this already.


    I think atime (which is on by default) served only to one single
application in the whole history of Unix and has caused a big load and
impedimenta on all filesystems for all that time. It causes 'mount -o
ro' to be at least a partial lie. I understand acls as suplementary
metadata which must be written to disk in a way or another, but probably
it is not permitted to change them on a read-only partition; in which
case they don't hurt.

>>      I don't know for the f. acls. For my own systems, all partitions
>> are always mounted with noacl; therefore I would also add it in the
>> remount.
> I've never thought about acls. What's the benefit to using noacl on
> mounts?

    I hate acls as much as Systemd. I happened a few times to be
forbidden to modify a file, even being root and having write permission.
Acls are meant to restrict permission beyond the ones shown by 'ls -l'.
I do not think they bring any security at all. The way to get rid of
them is -o noacl. I now have this option in every line of my fstab,
actually noatime,noacl.

    It is enough to look at the manual to be quickly enlightened. Try
'man acl'. If after one hour you have made sense of that crap, then
congratulations! The easy way out: 'mount -o remount,noacl ...'  Thanks
Linus for this option! It is much simpler than to get rid of Systemd or
Selinux.

 --     Didier