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
