On Sun, 26 May 2013 13:40:03 +0200 Luca Barbato <[email protected]> wrote:
> On 5/26/13 12:57 PM, Michał Górny wrote: > > Switch inittab? Now you added really dangerous behavior to the wrapper > > code. I can hardly even express this in words. > > I need it for my purpose, bb-init syntax isn't the same as sysv. Then you need to use a different file. Feel free to rename either inittab but don't even think of switching files like this. > > You are telling me that a wrapper, a thing that gets executed *every* > > boot needs to do some random magic to know which init system was in use > > and which one is supposed to be in use, and then conditionally move > > around configuration files necessary for it to run. This is just > > *INSANE*. > > I like to think it normal and the wrapper doesn't need to run every time > but only when a switch had been requested. And only if you prefer doing > the switch at boot time instead than at shutdown. Well, that makes it a bit less destructive. Though I still don't like the idea. > > And what will happen if moving the files fail? What if half of > > configuration belongs to old init, and half to new? And it all happens > > automagically on boot, on an incomplete system without any console > > started, without Internet connection established and without any > > serious mean of help. > > You can: > > - consider rolling back > - drop to a shell > > Nothing so terrible. Sounds like an initramfs... > > What I'm telling is: if user uses A as init system (and wanted to switch > > to B), last thing he'd expect is C being started. Configuration for > > OpenRC may be long unmaintained, may start services which are not > > supposed to be started anymore and so on. > > The safest would be dropping to a shell in your scenario. > > As I stated from start the "switch on boot" would work so the wrapper > checks a switch had been requested, it knows the current init, that must > work since worked the previous boot, the next init, that supposedly > should work, does the pivoting, shuffling and such and the next boot it > just hands over to the current init. It all depends on how it is implemented. If we decide not to touch /sbin/init, then sysvinit will be the effective fallback at some earlier or later point, depending on what will fail. This is what I really dislike. > > We're not talking about percentages here. A *single* fragile script is > > enough to cause trouble. Ten good ones won't revert it. > > A single fragile script can be fixed I guess, which is the one you have > in mind that is concerning? You could've asked me that when I was still using OpenRC. I don't really want to grep the 40 scripts right now, and I don't think I have the worse cases installed here. > > What are you talking about now? I was just saying that *if* you > > link /sbin/init to systemd, and you're running sysvinit, 'init foo' > > will be passed through to telinit. > > > > But now I see that I was wrong and it actually happened when > > 'systemctl' was symlinked to 'init'. Nevermind then. > > > > In any case, keeping all the tools like 'telinit' should be *enough* to > > keep the current init running and rebooting. > > You are focused on systemd, I'm focused on bb-init among the rest, it > uses a different syntax for the inittab, so if you want to switch from > one or another you either prepare a least-action script that switch the > inittab on reboot or a first-action script that does that on boot. > > For your needs probably just pivoting a symlink should work almost fine, > as long your stay sysvinit compatible, yet doing that as early init or > as post kill-all should work better even in your case. Well, you're transforming a simple idea with potentially relatively wide audience into a horror story with a single user. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
