Re: On init in Debian
On Wed, Mar 21, 2012 at 10:49:09AM +0100, Martin Wuertele wrote:
> * Marco d'Itri <md@Linux.IT> [2012-03-21 09:34]:
>
> > On Mar 21, Svante Signell <svante.signell@telia.com> wrote:
> >
> > > And how do you expect non-experts be able to solve problems when they
> > > pop up. Buying consultant services from the experts?
> > Non-experts are not able to solve any problem, so this is not an issue.
>
> But they can provide debugging info and some level of analyses that
> helps to triage the problems (and if it's a simple set -x in init
> scripts).
This has been asserted quite a few times in the thread, and I
think it's an oversimplification of the matter. We have:
startpar
init systemd
------------- -------------
(lots of) (lots of)
shell scripts unit files
There's an important distinction between debugging a buggy
service (be it a shell script or unit file) and a buggy
init implementation (be it sysvinit/startpar or systemd or
upstart). Debugging the core sysvinit or systemd code does
require programming expertise, but it only needs doing once.
Once it's tested and known to work well, the chance of a
user running into problems with it is very small. We
initially had problems when startpar was introduced: it was
buggy in certain cases, and some init scripts had incorrect
dependency information, resulting in boot problems. It's
now well tested and works well. I'm sure the same will apply
to systemd, but it will work very well once the initial
teething problems are fixed.
It's not common for users to run into major problems with an
individual init script, but when they do, I don't agreee that
it's easy to debug. init scripts are, by their very nature,
full of horribly complex shell script, and understanding what
everything does for a single service often requires initimate
knowledge of how the service works. While it's possible to
manually fix up a script to work by editing it, the reality is
that only a few people have the expertise to do that. And the
most important point, is that with unit files, you never need
to do that: they are so simple, they should be obviously
correct. The chance of there being a problem in the first place
is vastly reduced.
While it's true that if something goes wrong with systemd,
diagnosing it and fixing it might be difficult, this is mainly
due to our (collective) lack of experience with it rather than
there being anything intrinsically more difficult about it. If
anything, it promises to be vastly simpler and more robust than
the spaghetti mess of shell we currently have to deal with. If
there are corner cases where the boot hangs, that's simply
something which needs finding and fixing.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: