1 |
Tom Wijsman posted on Tue, 28 May 2013 13:56:19 +0200 as excerpted: |
2 |
|
3 |
> You're making a lot of statements like this but don't back them up. |
4 |
> |
5 |
> Why would this work best for this situation? What's wrong with the rest? |
6 |
|
7 |
While as long as it stays out of my way enough so I don't have to worry |
8 |
about it, I don't particularly care (to the point I debated simply not |
9 |
replying), your post did make me aware of the fact that I was claiming |
10 |
negatives on the other methods without backing up the claims... because |
11 |
from here they were evident, and others had made them well enough I |
12 |
didn't need to. |
13 |
|
14 |
However, I guess if I claim something I owe it to my readers to be |
15 |
prepared to back it up, so... |
16 |
|
17 |
As I've read the thread, there seem to be four issues with most of the |
18 |
other methods discussed, three related, one separate. |
19 |
|
20 |
1) Changing an initsystem with the system up and running in normal state |
21 |
risks not being able to shut down properly. While some init-systems may |
22 |
either not have that problem or be able to work around it in a trivial |
23 |
way, getting something robust enough to work reliably across all of them, |
24 |
in all sorts of weird site configurations, will be... challenging, to say |
25 |
the least. |
26 |
|
27 |
2) Doing it at shutdown has problems of its own, including the incomplete |
28 |
switch crash scenario as well as having to do it late enough in the |
29 |
process that the operational-switch issues of #1 aren't triggered. |
30 |
|
31 |
The two problems above lead to the idea of not actually doing the change |
32 |
on a running system, but rather, simply using a trigger mechanism to |
33 |
trigger it at next boot. I didn't see it specifically stated what that |
34 |
would be, but at least here I envisioned it as comparable to the .fsck |
35 |
(whatever it's named) file dropped in root to trigger an fsck at the next |
36 |
boot, only in this case it would trigger the init-system switch. |
37 |
|
38 |
3) Except... any switch has to occur VERY early in the boot process, |
39 |
before the existing init-system has already gotten us into the |
40 |
operational-switch situation of #1 that we were trying to avoid. |
41 |
Effectively, our switcher must be called as init either by the kernel |
42 |
itself or by the initr*, where it can do its thing before calling the |
43 |
normal init-system it might have just switched to. |
44 |
|
45 |
3b) Except... at that point root isn't writable, and a robust solution to |
46 |
get it writable in ordered to actually make the switch permanent, that |
47 |
works on all the strange root-on-whatever systems out there, AND works |
48 |
with at least systemd and openrc and bb-init (with extensibility to |
49 |
others), AND inserts extremely minimal delay and code into the routine |
50 |
"no changes, just boot the same way you did last time" case, AND doesn't |
51 |
take control away from the individual init-system package maintainers, |
52 |
AND doesn't impose a huge burden on individual init-system package |
53 |
maintainers, AND fills ALL these requirements suitably robustly that it |
54 |
works well to say at least two-nines reliability... |
55 |
|
56 |
No wonder someone mentioned that it looked like a case for an initr*... |
57 |
but on gentoo anyway, requiring that has at least political problems of |
58 |
its own. |
59 |
|
60 |
It's beginning to look rather like a Sisyphean task... Which it might |
61 |
actually be. |
62 |
|
63 |
But it occurred to me that we actually do have a demonstrated workable |
64 |
and long used in actual practice exception to the normal boot case as |
65 |
precedent, where such maintenance tasks traditionally occur, single user |
66 |
mode. Then I began thinking how that fit the requirements and use case |
67 |
as outlined, including the (semi-?)automated bit. |
68 |
|
69 |
Which is how I came to post the idea of the sub-thread starter. Not to |
70 |
rehash everything I wrote there, but it seems to me to have the best |
71 |
chance at doing what is otherwise looking to be a Sisyphean task. With |
72 |
the extremely minimal two-case-only code inserted between kernel/initr* |
73 |
and the selected init-system at boot, it fills the quick and simple |
74 |
normal-case boot requirement. All the rest of the code is out of the |
75 |
way. The rest of the code then runs as a semi-automated single-user-mode |
76 |
equivalent. And having even that minimal normal-boot-mode insert under |
77 |
control of a USE flag allows people to get even that out of the way if |
78 |
they're not interested. |
79 |
|
80 |
Meanwhile, it's worth pointing out explicitly that by choosing this |
81 |
insertion point, root must already be at least mounted and accessible in |
82 |
read-only mode, whether by kernel command-line, initr*, or whatever, or |
83 |
the direct init invocation we're replacing wouldn't work. Thus, the |
84 |
whole issue of possibly initr* userspace or kernel commandline getting |
85 |
exotic root-on-whatever even mountable in the first place, is already |
86 |
taken care of, yet real-init hasn't yet executed, so we don't have to |
87 |
worry about messing with an already functioning init-system, thus leaving |
88 |
it no way to "climb down". |
89 |
|
90 |
4) Finally, the fact that each init-system package gets to control its |
91 |
own switcher-mode script keeps control of it with the init-system package |
92 |
maintainers, allowing them to choose as complex or simple a script as |
93 |
they need/wish, reasonably addressing the whole maintainer control |
94 |
problem so evident in another current thread. |
95 |
|
96 |
|
97 |
Beyond that, the idea is extremely flexible and extensible, as mentioned. |
98 |
|
99 |
And one final point I didn't mention in the initial proposal, that I can |
100 |
add here. Presumably, the init-switcher package would include a library |
101 |
function that could be invoked by the individual switcher scripts, that |
102 |
would re-mount root rw, to handle any write-needed changes such as |
103 |
switching out inittab for bb-init as well as to make the init-system |
104 |
choice permanent, plus another to remount ro again before either reboot |
105 |
or handing off to the chosen init-system, as deemed appropriate. These |
106 |
would be issues likely to need addressed by all/most init-switcher |
107 |
scripts, so a common solution is reasonable. Of course if the individual |
108 |
script didn't need that or was an extension to some other purpose, the |
109 |
functions need not be called. |
110 |
|
111 |
-- |
112 |
Duncan - List replies preferred. No HTML msgs. |
113 |
"Every nonfree program has a lord, a master -- |
114 |
and if you use the program, he is your master." Richard Stallman |