Re: On init in Debian
Russell Coker, le Fri 23 Mar 2012 02:25:57 +1100, a écrit :
> > 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. 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.
> Have you tried debugging a shell?
I have. But way more seldomly than init scripts.
> > - I have already had several times to fix init scripts because they were
> > doing something bogus in some particular case. That's a fact.
> Yes, shell scripts do lots of strange stuff, I've written my share of buggy
> init scripts in the past. A good portion of the bugs in shell scripts are due
> to managing pid files, correctly dropping privileges, and other things which
> an ideal process 1 would manage for us.
And will have to do all that correctly too.
> > - That kind of bug *can* happen in systemd too. Nobody writes perfect
> > software. I believe that can be admitted.
> Sure, but given hundreds of random people writing init scripts vs a few people
> writing an init daemon I'm betting on the hundreds of random people writing
> buggy code.
A few people that would have to be expert in all the areas that systemd
implements? There are a lot of knobs in the Debian sysv initscripts,
which are there for a reason that has been determined by experts of
the corresponding area during the past couple of decades. And now we'd
replace that with just one software which hasn't been contributed to by
all the experts that know what knobs are needed? For me, the advertised
array of features of systemd (that sysvinit has always left others do)
is daunting, not advertising.
> > - It's way more involved to debug that when dealing with a binary, not a
> > script. I hope it's admitted too.
> Also a commonly used program is better tested. Run a daemon that isn't really
> popular and have something a little different about your configuration
> (different /bin/sh, different combination of other daemons installed, etc) and
> you may expose weaknesses in someone's shell scripting ability.
Yep, that's one of the reasons why there is an rcS vs rc[2-5]
> It's quite a lot less likely that a random daemon you decide to run
> will do something that's outside the range of things that systemd is
> tested against.
With what effect? Concerning random daemons, I have essentially seen
bogus pidfile or such without real big deal.