Re: On init in Debian
On Fri, 23 Mar 2012, Samuel Thibault <sthibault@debian.org> wrote:
> > How is this different from copying a known-to-work, statically compiled
> > copy of systemd in?
>
> 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
Actually there is no real limit to the complexity of shell scripts used by
sysvinit. They run programs like sleep, cp, mv, ps, kill, sed, and lots more.
I've encountered lots of init scripts who's purpose was not obvious at all.
Sometimes running them with bash -x still doesn't make it obvious.
> 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? It's a big complex program (bash is bigger
than ANY of the init systems) and it's not easy to debug. Also there's no
requirement that shell scripts be specific to a particular shell. Some init
scripts are executed by bash, some are executed by /bin/sh which may be dash
or bash - this causes extra excitement as the system may boot with a different
interpreter for /bin/sh to that which is used by the package maintainer!
> > 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 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.
> - 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.
> - 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. 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.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Reply to: