1 |
On Sat, 25 May 2013 11:54:48 +0200 |
2 |
Luca Barbato <lu_zero@g.o> wrote: |
3 |
|
4 |
> - /sbin/init (or whatever linux currently calls by default with top |
5 |
> priority) should be either a symlink to the actual implementation or a |
6 |
> wrapper such as our gcc one. I like better the latter since it is |
7 |
> overall safer. The former might or might work since linux has some |
8 |
> fallback capabilities but hadn't been tested. |
9 |
|
10 |
Increased complexity is never safer. And a wrapper means the additional |
11 |
complexity gets there every boot. And considering how the discussion |
12 |
goes, the wrapper will grow openrc-size in a few months... |
13 |
|
14 |
Symlinks are simple. They're filesystem feature, they're handled |
15 |
by kernel. The worst thing that could happen is symlink target |
16 |
disappearing -- but then it's: |
17 |
|
18 |
a) our responsibility to make sure to call eselect-init (if applies) |
19 |
when uninstalling an init system, |
20 |
|
21 |
b) something that would fail anyway if user did that by hand. |
22 |
|
23 |
Linux fallback mechanism is *good enough*. You may think that fallback |
24 |
to sysvinit is good but it's not. *If* I have my system set up to boot |
25 |
X, at some point the config for Y will get seriously outdated. |
26 |
|
27 |
I use systemd for a few months now, and last time I checked openrc |
28 |
boots somehow. But considering the general complexity of it, I wouldn't |
29 |
be much surprised if it failed in funny ways (like not being able to |
30 |
handle automounts properly), caused cruft on the filesystem or even |
31 |
caused *damage*. |
32 |
|
33 |
And since you've been failing long at keeping init.d scripts simple |
34 |
and reasonable, the damage potential is not something purely |
35 |
theoretical. |
36 |
|
37 |
That said, switching /sbin/init is the reasonable way. If it fails, |
38 |
Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without |
39 |
unexpectedly switching init system to something else just because it |
40 |
was around. |
41 |
|
42 |
> - init gets effectively switched only at boot/reboot, eselect init must |
43 |
> keep track of the current active init and make sure the current init |
44 |
> configuration is used till the system reboots, if we use the wrapper |
45 |
> approach, it would pick up what's the new init at boot and that would be |
46 |
> enough for simple cases, hooks on reboot are still needed for more |
47 |
> complex ones. |
48 |
|
49 |
Pointless and overcomplex. If an init system actually fails to work |
50 |
when /sbin/init doesn't point to it, it is seriously broken by design. |
51 |
And because of that breakage, we keep stuff like 'telinit' or 'reboot' |
52 |
intact, and because of it systemd has 'pass-through' mode when linked |
53 |
to /sbin/init. |
54 |
|
55 |
> - we could try to not have the changes to the current init systems |
56 |
> ebuild or reduce them to the bare minimum (e.g. not overwrite /sbin/init) |
57 |
|
58 |
Which means the kernel fallback will be dangerously active |
59 |
as I explained before. Just don't do it. |
60 |
|
61 |
> # FOCUS |
62 |
> |
63 |
> My interest is mostly if not all on bb-init-openrc and slightly on |
64 |
> runit-openrc. |
65 |
> |
66 |
> There are enough people involved in systemd and since I still consider |
67 |
> it a dangerously frail implementation of a bad idea is better if I do |
68 |
> not touch it at all. |
69 |
|
70 |
You've been able to keep this thread on topic very long. Good job! |
71 |
|
72 |
-- |
73 |
Best regards, |
74 |
Michał Górny |