On Fri, Aug 21, 2015 at 2:11 AM, Laurent Bercot <ska-skaware_at_skarnet.org> wrote:
> Wow. Is it a "mount -o remount", or a umount followed by a mount ?
> If a -o remount has this effect on file handles, then it's probably
> worth reporting to the kernel guys, because it's insane.
>
> Even if the script does something nonsensical such as remounting
> everything read-only, which hardly makes any sense for a tmpfs,
> this is not normal behaviour: when I remount a partition in read-only
> mode, and there are still open descriptors for writing, the mount()
> call fails with EBUSY; it does not silently invalidate all the writing
> descriptors!
>
First reboot in a while so I spent some time tracking this down. It
was caused by some really cute interactions between a few of the
Debian single-user mode system prep scripts. checkfs-bootclean.sh is
safe to run against tmpfs mounts right until you run bootmisc.sh,
which removes the flag files that the clean_all function uses to
identify a tmpfs. So that's been fixed.
>
>
> Last time I looked at a mainstream distro's boot cycle, i.e. almost
> 10 years ago, it was already unnecessarily complex and convoluted; and
> Debian was far from the worst. I doubt it has become simpler since.
>
It probably doesn't help that I'm working against the hardest target
too: laptops. Thankfully, the only place where I really need to
interact with the sysvinit stuff is in the collection of oneshots that
are emulating the single-user portion of the bootcycle. I did find a
script in there that will halt an s6-init system if you run it . That
was fun. It's the only place that I found that actually cares about
what init you're running under. In the case where you have sysvinit
but no initctl control pipe (such as can happen if you mount a new
/run over the old one) it recreates that and then fires off SIGUSR1 at
whatever happens to be init at the time.
The only things left to fix are some file permissions and mounts that
the aforementioned script fixes up, and that ACPI sleep handler
weirdness that I mentioned earlier. Plus, you know, not running a
pre-alpha rc system ;)
>
> systemd will probably make scripting simpler, by moving a lot of the
> complexity into the C code. Which is obviously the worst possible
> solution.
>
Probably. I almost want to build out a systemd machine to see what the
early boot land looks like. Depending on what the system prep stuff
looks like it might be easier to gut. Like I said though, almost.
Cheers!
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Fri Aug 28 2015 - 15:51:56 UTC