[gentoo-dev] Re: Switchup-mode and boottime selector? Was: eselect init

[Duncan <1i5t5.duncan@cox.net>]

Tom Wijsman posted on Tue, 28 May 2013 13:56:19 +0200 as excerpted:

> You're making a lot of statements like this but don't back them up.
> 
> Why would this work best for this situation? What's wrong with the rest?

While as long as it stays out of my way enough so I don't have to worry 
about it, I don't particularly care (to the point I debated simply not 
replying), your post did make me aware of the fact that I was claiming 
negatives on the other methods without backing up the claims... because 
from here they were evident, and others had made them well enough I 
didn't need to.

However, I guess if I claim something I owe it to my readers to be 
prepared to back it up, so...

As I've read the thread, there seem to be four issues with most of the 
other methods discussed, three related, one separate.

1) Changing an initsystem with the system up and running in normal state 
risks not being able to shut down properly.  While some init-systems may 
either not have that problem or be able to work around it in a trivial 
way, getting something robust enough to work reliably across all of them, 
in all sorts of weird site configurations, will be... challenging, to say 
the least.

2) Doing it at shutdown has problems of its own, including the incomplete 
switch crash scenario as well as having to do it late enough in the 
process that the operational-switch issues of #1 aren't triggered.

The two problems above lead to the idea of not actually doing the change 
on a running system, but rather, simply using a trigger mechanism to 
trigger it at next boot.  I didn't see it specifically stated what that 
would be, but at least here I envisioned it as comparable to the .fsck 
(whatever it's named) file dropped in root to trigger an fsck at the next 
boot, only in this case it would trigger the init-system switch.

3) Except... any switch has to occur VERY early in the boot process, 
before the existing init-system has already gotten us into the 
operational-switch situation of #1 that we were trying to avoid.  
Effectively, our switcher must be called as init either by the kernel 
itself or by the initr*, where it can do its thing before calling the 
normal init-system it might have just switched to.

3b) Except... at that point root isn't writable, and a robust solution to 
get it writable in ordered to actually make the switch permanent, that 
works on all the strange root-on-whatever systems out there, AND works 
with at least systemd and openrc and bb-init (with extensibility to 
others), AND inserts extremely minimal delay and code into the routine 
"no changes, just boot the same way you did last time" case, AND doesn't 
take control away from the individual init-system package maintainers, 
AND doesn't impose a huge burden on individual init-system package 
maintainers, AND fills ALL these requirements suitably robustly that it 
works well to say at least two-nines reliability...

No wonder someone mentioned that it looked like a case for an initr*... 
but on gentoo anyway, requiring that has at least political problems of 
its own.

It's beginning to look rather like a Sisyphean task... Which it might 
actually be.

But it occurred to me that we actually do have a demonstrated workable 
and long used in actual practice exception to the normal boot case as 
precedent, where such maintenance tasks traditionally occur, single user 
mode.  Then I began thinking how that fit the requirements and use case 
as outlined, including the (semi-?)automated bit.

Which is how I came to post the idea of the sub-thread starter.  Not to 
rehash everything I wrote there, but it seems to me to have the best 
chance at doing what is otherwise looking to be a Sisyphean task.  With 
the extremely minimal two-case-only code inserted between kernel/initr* 
and the selected init-system at boot, it fills the quick and simple 
normal-case boot requirement.  All the rest of the code is out of the 
way.  The rest of the code then runs as a semi-automated single-user-mode 
equivalent.  And having even that minimal normal-boot-mode insert under 
control of a USE flag allows people to get even that out of the way if 
they're not interested.

Meanwhile, it's worth pointing out explicitly that by choosing this 
insertion point, root must already be at least mounted and accessible in 
read-only mode, whether by kernel command-line, initr*, or whatever, or 
the direct init invocation we're replacing wouldn't work.  Thus, the 
whole issue of possibly initr* userspace or kernel commandline getting 
exotic root-on-whatever even mountable in the first place, is already 
taken care of, yet real-init hasn't yet executed, so we don't have to 
worry about messing with an already functioning init-system, thus leaving 
it no way to "climb down".

4) Finally, the fact that each init-system package gets to control its 
own switcher-mode script keeps control of it with the init-system package 
maintainers, allowing them to choose as complex or simple a script as 
they need/wish, reasonably addressing the whole maintainer control 
problem so evident in another current thread.


Beyond that, the idea is extremely flexible and extensible, as mentioned.

And one final point I didn't mention in the initial proposal, that I can 
add here.  Presumably, the init-switcher package would include a library 
function that could be invoked by the individual switcher scripts, that 
would re-mount root rw, to handle any write-needed changes such as 
switching out inittab for bb-init as well as to make the init-system 
choice permanent, plus another to remount ro again before either reboot 
or handing off to the chosen init-system, as deemed appropriate.  These 
would be issues likely to need addressed by all/most init-switcher 
scripts, so a common solution is reasonable.  Of course if the individual 
script didn't need that or was an extension to some other purpose, the 
functions need not be called.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman