[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: