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

Re: On init in Debian



Tollef Fog Heen, le Thu 22 Mar 2012 15:47:45 +0100, a écrit :
> > Stig Sandbeck Mathisen, le Thu 22 Mar 2012 13:35:15 +0100, a écrit :
> > > Samuel Thibault <sthibault@debian.org> writes:
> > > 
> > > > Because the issue at stake might lie in systemd itself, not the unit
> > > > file.
> > > 
> > > And if /bin/sh breaks on an init style system, you can fix it with an
> > > editor?
> > 
> > You can cp a known-to-work-statically-compiled /bin/sh there.
> 
> 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
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 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.
- That kind of bug *can* happen in systemd too. Nobody writes perfect
  software. I believe that can be admitted.
- It's way more involved to debug that when dealing with a binary, not a
  script. I hope it's admitted too.
- sysvinit has the same issue with its /sbin/init, except that the
  surface of the bugs is way smaller. I have hit a bug there once,
  too. Only once, with very minor effect. It's much less of a fact, but
  I believe that can be admitted too.

Samuel


Reply to: