1 |
On Sun, 26 May 2013 11:55:24 +0200 |
2 |
Luca Barbato <lu_zero@g.o> wrote: |
3 |
|
4 |
> On 5/26/13 8:43 AM, Michał Górny wrote: |
5 |
> > On Sat, 25 May 2013 11:54:48 +0200 |
6 |
> > Luca Barbato <lu_zero@g.o> wrote: |
7 |
> > |
8 |
> >> - /sbin/init (or whatever linux currently calls by default with top |
9 |
> >> priority) should be either a symlink to the actual implementation or a |
10 |
> >> wrapper such as our gcc one. I like better the latter since it is |
11 |
> >> overall safer. The former might or might work since linux has some |
12 |
> >> fallback capabilities but hadn't been tested. |
13 |
> > |
14 |
> > Increased complexity is never safer. And a wrapper means the additional |
15 |
> > complexity gets there every boot. And considering how the discussion |
16 |
> > goes, the wrapper will grow openrc-size in a few months... |
17 |
> |
18 |
> Openrc is small, but the wrapper really needs to know which is which and |
19 |
> worst case switch inittab. |
20 |
|
21 |
Switch inittab? Now you added really dangerous behavior to the wrapper |
22 |
code. I can hardly even express this in words. |
23 |
|
24 |
You are telling me that a wrapper, a thing that gets executed *every* |
25 |
boot needs to do some random magic to know which init system was in use |
26 |
and which one is supposed to be in use, and then conditionally move |
27 |
around configuration files necessary for it to run. This is just |
28 |
*INSANE*. |
29 |
|
30 |
Did anyone notice already that moving stuff around actually requires |
31 |
rootfs mounted R/W? Which means the wrapper needs to repeat a fair bit |
32 |
of init/RC work. |
33 |
|
34 |
And what will happen if moving the files fail? What if half of |
35 |
configuration belongs to old init, and half to new? And it all happens |
36 |
automagically on boot, on an incomplete system without any console |
37 |
started, without Internet connection established and without any |
38 |
serious mean of help. |
39 |
|
40 |
> > Symlinks are simple. They're filesystem feature, they're handled |
41 |
> > by kernel. The worst thing that could happen is symlink target |
42 |
> > disappearing -- but then it's: |
43 |
> > |
44 |
> > a) our responsibility to make sure to call eselect-init (if applies) |
45 |
> > when uninstalling an init system, |
46 |
> > |
47 |
> > b) something that would fail anyway if user did that by hand. |
48 |
> > |
49 |
> > Linux fallback mechanism is *good enough*. You may think that fallback |
50 |
> > to sysvinit is good but it's not. *If* I have my system set up to boot |
51 |
> > X, at some point the config for Y will get seriously outdated. |
52 |
> |
53 |
> Have you tested it? Do you know what is the reaction of do_exec on a |
54 |
> dangling symlink? |
55 |
|
56 |
And did you? You keep repeating this and jumping straight to developing |
57 |
work-arounds without even waiting for an answer. And I think William |
58 |
has already spoken that the code supports it. |
59 |
|
60 |
In any case, I've just tested it. Replaced /sbin/init with a dangling |
61 |
symlink, rebooted with init=/sbin/init and the kernel ran /bin/sh |
62 |
as a fallback. |
63 |
|
64 |
> > I use systemd for a few months now, and last time I checked openrc |
65 |
> > boots somehow. But considering the general complexity of it, I wouldn't |
66 |
> > be much surprised if it failed in funny ways (like not being able to |
67 |
> > handle automounts properly), caused cruft on the filesystem or even |
68 |
> > caused *damage*. |
69 |
> |
70 |
> openrc is *simpler* much *simpler* than systemd, stop with that. |
71 |
|
72 |
OpenRC relies on a few layers of various tools plus a lot of init |
73 |
scripts written by different people. Those init scripts include tasks |
74 |
such as parsing configuration files (well, more of grepping them) |
75 |
and manipulating runtime files. The complexity of OpenRC is the sum |
76 |
of all that. |
77 |
|
78 |
To make this point cleaner to you: what if the fallback ran systemd |
79 |
instead? As in, init gets broken somehow and kernel falls back to |
80 |
starting systemd on your unprepared OpenRC system. Is this a behavior |
81 |
you'd like? |
82 |
|
83 |
What I'm telling is: if user uses A as init system (and wanted to switch |
84 |
to B), last thing he'd expect is C being started. Configuration for |
85 |
OpenRC may be long unmaintained, may start services which are not |
86 |
supposed to be started anymore and so on. |
87 |
|
88 |
> > And since you've been failing long at keeping init.d scripts simple |
89 |
> > and reasonable, the damage potential is not something purely |
90 |
> > theoretical. |
91 |
> |
92 |
> wc -l is a good answer to your concern. Some scripts have to be |
93 |
> simplified, that's a given (e.g. Fabio pointed the lvm one can be |
94 |
> improved a lot) but it isn't the case for most of them. |
95 |
|
96 |
We're not talking about percentages here. A *single* fragile script is |
97 |
enough to cause trouble. Ten good ones won't revert it. |
98 |
|
99 |
> > Pointless and overcomplex. If an init system actually fails to work |
100 |
> > when /sbin/init doesn't point to it, it is seriously broken by design. |
101 |
> > And because of that breakage, we keep stuff like 'telinit' or 'reboot' |
102 |
> > intact, and because of it systemd has 'pass-through' mode when linked |
103 |
> > to /sbin/init. |
104 |
> |
105 |
> Check your facts, systemd either understands a flavour of inittab or the |
106 |
> other or none at all. |
107 |
|
108 |
What are you talking about now? I was just saying that *if* you |
109 |
link /sbin/init to systemd, and you're running sysvinit, 'init foo' |
110 |
will be passed through to telinit. |
111 |
|
112 |
But now I see that I was wrong and it actually happened when |
113 |
'systemctl' was symlinked to 'init'. Nevermind then. |
114 |
|
115 |
In any case, keeping all the tools like 'telinit' should be *enough* to |
116 |
keep the current init running and rebooting. |
117 |
|
118 |
> > Which means the kernel fallback will be dangerously active |
119 |
> > as I explained before. Just don't do it. |
120 |
> |
121 |
> It is not dangerous beside for those that have an inittab with rm -fR / |
122 |
|
123 |
n/c |
124 |
|
125 |
-- |
126 |
Best regards, |
127 |
Michał Górny |