1 |
On 5/26/13 8:43 AM, Micha³ Górny wrote: |
2 |
> On Sat, 25 May 2013 11:54:48 +0200 |
3 |
> Luca Barbato <lu_zero@g.o> wrote: |
4 |
> |
5 |
>> - /sbin/init (or whatever linux currently calls by default with top |
6 |
>> priority) should be either a symlink to the actual implementation or a |
7 |
>> wrapper such as our gcc one. I like better the latter since it is |
8 |
>> overall safer. The former might or might work since linux has some |
9 |
>> fallback capabilities but hadn't been tested. |
10 |
> |
11 |
> Increased complexity is never safer. And a wrapper means the additional |
12 |
> complexity gets there every boot. And considering how the discussion |
13 |
> goes, the wrapper will grow openrc-size in a few months... |
14 |
|
15 |
Openrc is small, but the wrapper really needs to know which is which and |
16 |
worst case switch inittab. |
17 |
|
18 |
> Symlinks are simple. They're filesystem feature, they're handled |
19 |
> by kernel. The worst thing that could happen is symlink target |
20 |
> disappearing -- but then it's: |
21 |
> |
22 |
> a) our responsibility to make sure to call eselect-init (if applies) |
23 |
> when uninstalling an init system, |
24 |
> |
25 |
> b) something that would fail anyway if user did that by hand. |
26 |
> |
27 |
> Linux fallback mechanism is *good enough*. You may think that fallback |
28 |
> to sysvinit is good but it's not. *If* I have my system set up to boot |
29 |
> X, at some point the config for Y will get seriously outdated. |
30 |
|
31 |
Have you tested it? Do you know what is the reaction of do_exec on a |
32 |
dangling symlink? |
33 |
|
34 |
> I use systemd for a few months now, and last time I checked openrc |
35 |
> boots somehow. But considering the general complexity of it, I wouldn't |
36 |
> be much surprised if it failed in funny ways (like not being able to |
37 |
> handle automounts properly), caused cruft on the filesystem or even |
38 |
> caused *damage*. |
39 |
|
40 |
openrc is *simpler* much *simpler* than systemd, stop with that. |
41 |
|
42 |
> And since you've been failing long at keeping init.d scripts simple |
43 |
> and reasonable, the damage potential is not something purely |
44 |
> theoretical. |
45 |
|
46 |
wc -l is a good answer to your concern. Some scripts have to be |
47 |
simplified, that's a given (e.g. Fabio pointed the lvm one can be |
48 |
improved a lot) but it isn't the case for most of them. |
49 |
|
50 |
> Pointless and overcomplex. If an init system actually fails to work |
51 |
> when /sbin/init doesn't point to it, it is seriously broken by design. |
52 |
> And because of that breakage, we keep stuff like 'telinit' or 'reboot' |
53 |
> intact, and because of it systemd has 'pass-through' mode when linked |
54 |
> to /sbin/init. |
55 |
|
56 |
Check your facts, systemd either understands a flavour of inittab or the |
57 |
other or none at all. |
58 |
|
59 |
> Which means the kernel fallback will be dangerously active |
60 |
> as I explained before. Just don't do it. |
61 |
|
62 |
It is not dangerous beside for those that have an inittab with rm -fR / |
63 |
|
64 |
lu |