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