On Mon, 14 Mar 2016 08:56:53 +0100 Martin Husemann <martin%duskware.de@localhost>
wrote:
> On Sun, Mar 13, 2016 at 10:40:04PM +0100, Ian D. Leroux wrote:
>
> > If /dev/console can just go missing however (does that happen?)
>
> No, it *should* never happen unintendedly (besides catastrophic file
> system corruption, mount failures for other similar reasons, ...).
> The init reaction is an emergency recovery feature.
>
> It happens regularily on install media, but I guess we can ignore
> most of the rc.d scripts in that environment (as they are not
> present).
>
> I am not objecting to your implementation, and as you say the choice
> of defaults is not a clear one and could be argued either way.
>
> Your point of a simpler implementation is a very valid one.
Here's slightly better compromise, that does the right thing by default
in more cases. The rc.conf variable "swapoff_umount" (name changed for
clarity) can be either
- an explicit list of zero or more tmpfs filesystems to umount before
removing swap devices, or
- "auto", in which case all tmpfs mounts containing no device nodes are
removed, as you suggested at the beginning of the week.
Implementing the auto version turned out to be easier than I thought,
and it means that the default ("auto") won't bite anyone whose /dev
unexpectedly gets tmpfs-mounted after a catastrophic filesystem problem.
It also simplifies the documentation, which I take to be a good sign.
This way there is still the option of explicitly controlling the
unmounting, but the default should handle most cases with reasonable
grace. I've removed the "ALL" option that blindly unmounted all tmpfs
filesystems. As far as I can see, its only advantage was that it saves
a little time (no need to wait for the scan for device nodes run by
"auto"). If users regularly have such large tmpfs filesystems mounted
at shutdown time that the device-node scan takes an irritatingly long
time, they can explicitly list them in swapoff_umount and thus avoid
the scan. It's a configuration burden on such users, but I'm
comfortable with that since it only concerns speed of shutdown, not
correctness, in what I suspect is a fairly unusual corner case.
Further comments or suggestions for improvement?
--
IDL
Attachment:
manpage.patch
Description: Binary data
Attachment:
rc.conf.patch
Description: Binary data
Attachment:
swap1.patch
Description: Binary data