1 |
On Sun, 26 May 2013 10:58:23 +0200 |
2 |
Robert David <robert.david.public@×××××.com> wrote: |
3 |
|
4 |
> On Sun, 26 May 2013 08:43:32 +0200 |
5 |
> Michał Górny <mgorny@g.o> wrote: |
6 |
> |
7 |
> > On Sat, 25 May 2013 11:54:48 +0200 |
8 |
> > Luca Barbato <lu_zero@g.o> wrote: |
9 |
> > |
10 |
> > > - /sbin/init (or whatever linux currently calls by default with top |
11 |
> > > priority) should be either a symlink to the actual implementation |
12 |
> > > or a wrapper such as our gcc one. I like better the latter since it |
13 |
> > > is overall safer. The former might or might work since linux has |
14 |
> > > some fallback capabilities but hadn't been tested. |
15 |
> > |
16 |
> > Increased complexity is never safer. And a wrapper means the |
17 |
> > additional complexity gets there every boot. And considering how the |
18 |
> > discussion goes, the wrapper will grow openrc-size in a few months... |
19 |
> > |
20 |
> > Symlinks are simple. They're filesystem feature, they're handled |
21 |
> > by kernel. The worst thing that could happen is symlink target |
22 |
> > disappearing -- but then it's: |
23 |
> > |
24 |
> > a) our responsibility to make sure to call eselect-init (if applies) |
25 |
> > when uninstalling an init system, |
26 |
> > |
27 |
> > b) something that would fail anyway if user did that by hand. |
28 |
> > |
29 |
> > Linux fallback mechanism is *good enough*. You may think that fallback |
30 |
> > to sysvinit is good but it's not. *If* I have my system set up to boot |
31 |
> > X, at some point the config for Y will get seriously outdated. |
32 |
> > |
33 |
> > I use systemd for a few months now, and last time I checked openrc |
34 |
> > boots somehow. But considering the general complexity of it, I |
35 |
> > wouldn't be much surprised if it failed in funny ways (like not being |
36 |
> > able to handle automounts properly), caused cruft on the filesystem |
37 |
> > or even caused *damage*. |
38 |
> > |
39 |
> > And since you've been failing long at keeping init.d scripts simple |
40 |
> > and reasonable, the damage potential is not something purely |
41 |
> > theoretical. |
42 |
> > |
43 |
> > That said, switching /sbin/init is the reasonable way. If it fails, |
44 |
> > Linux runs /bin/sh. EOT. You broke, you fix, any way you like. Without |
45 |
> > unexpectedly switching init system to something else just because it |
46 |
> > was around. |
47 |
> |
48 |
> I agree with this. But changing symlinks is not as easy on running |
49 |
> system (since it can cause inconsistence during rebooot). |
50 |
|
51 |
It is *easy*. |
52 |
|
53 |
ln -s /sbin/newinit /sbin/init.new |
54 |
mv /sbin/init.new /sbin/init |
55 |
|
56 |
Easy and atomic. The inconsistency potential is similar to one given by |
57 |
init upgrades. Yet we don't do anything magical to defer init upgrade |
58 |
until reboot, and that's why the upgrades go smoothly. |
59 |
|
60 |
> I think that safest way not using wrapper is to stop all services |
61 |
> and keep only mounted /, than change things (symlinks,configuration |
62 |
> update) and reboot. |
63 |
|
64 |
This can be done two ways. |
65 |
|
66 |
One is hacking into init (RC) reboot procedure. It's fragile, it needs |
67 |
to be fit into the right moment and I'm not sure if all inits will |
68 |
handle this without actually needing to patch the code. And in the end, |
69 |
the init gets replaced before init stops working anyway. |
70 |
|
71 |
The other is going beside init and directly into the reboot. This |
72 |
either requires kernel hacking (please don't!) or hacking the reboot |
73 |
procedure in init code. And of course remounting R/W, then writing, |
74 |
remounting back... |
75 |
|
76 |
-- |
77 |
Best regards, |
78 |
Michał Górny |