Re: On init in Debian
Tollef Fog Heen, le Fri 23 Mar 2012 10:27:02 +0100, a écrit :
> > What init scripts use from the shell is way less complex than what
> > systemd implements, and it's independant from what is needed to achieve
> > the boot. You can copy over a woking systemd, fine, your system can
> > boot, but you have to debug the issue with the non-working systemd, i.e.
> > go back to a non-booting system.
>
> No, you don't. You can use systemd --test,
Well, that does not test the actual execution.
> you can debug by looking at the logs and the units on the system.
Do these logs really include all the information I'll need? I usually
need to put prints to analyze what is really happening. That means
rebuilding it, restart, etc.
> You can do a test boot by installing the new systemd, then doing: kvm
> -m 512 -snapshot -drive file=/dev/sda or similar.
Which permits to keep the production system running in the meanwhile,
indeed. That may not however test in real conditions.
> > When a bug is in the shell and hits the init scripts (I've never seen
> > such a bug), you can at least debug that outside of the boot process.
>
> How can you do that if your system doesn't boot?
By using the known-to-work /bin/sh to boot the system, and then work on
the particular script that poses problem. With a deamon like systemd,
it's rather all-or-nothing. Of course, systemd can probably be made to
do such kind of isolation of the start bits, to isolate the problem and
work on it. That's still more involved to work on than when dealing with
mere shell scripts.
> > > Have you actually tried systemd and run into problems and not filed
> > > bugs, or are you just spreading FUD here?
> >
> > Call it FUD if you want, but what I believe is true is:
>
> I call it FUD when you are spreading rumours rather than speaking from
> experience, yes.
I'm speaking from experience of having to fix init script details in the
past, for which having to deal with a C implementation would have meant
more time, yes.
> You seem to be making the assumption that you'll spend
> lots of time debugging systemd itself rather than debugging units, this
> in contrast with shell scripts where you spend most of the time
> debugging the shell scripts rather than the shell.
I'm making the assumption that when things go bad, not-low-probability
exists that I'll have to dig in the C files. For instance,
vconsole-setup.c is a reimplementation of the usual shell script for
setting up the console font & keymap. I have had to fix this kind of
script in the past because of forgotten details. Here I'd have to deal
with a C implementation.
> I really hope that we're able to have good enough tools that you can use
> the tools much more than you're debugging them,
The question is not there, but whether when I have to debug them, I'll
have to spend more time. Especially when the effect is the system not
booting...
Just to make it clear: I'm not saying a C-based implementation is bad.
Shell scripts are bad at text manipulation etc. But I believe they at
least permit quick debugging, which is an important matter for bootup.
Samuel
Reply to: