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