Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.
On Mon, Nov 11, 2013 at 08:20:58PM +0000, Thorsten Glaser wrote:
> Matthias Urlichs dixit:
>
> >A systemd service file is five lines.
>
> Someone has shown that this works with sysvinit as well,
> if you use #!/path/to/some-helper as shebang.
Nice theory, but in practice it is a mess. That people could clean stuff
up has been raised and dismissed various times because nobody cleans it
up.
> >Want more features in your init script? Like, say, a reliable way to
> >figure out if any parts of your server are still running after it
> >crashed?
>
> Ugh, bad server design.
Why?
> >Or a way to determine that it has started up correctly?
>
> An initscript is supposed to not return before it did that.
Why? Also, loads of scripts have sleeps in them.
> >determined environment without stupid surprises like a LOCALE
>
> That’d be the domain of the aforementioned helper.
Theory vs practice again.
> >Or a private tmp?
>
> I shudder at the mere thought of allowing a dæmon to unshare
> its /tmp from the rest of the system, because of the maintenance
> nightmare this creates, from a Unix PoV (maybe it’s “cool” to
> you and “usual” to Plan 9 guys, but things like this, or POSIX
> ACLs, or SELinux, massively make the system opaque to Unix admins).
>
> >Or any other of the cool features systemd offers?
>
> Newsflash: “cool” isn’t always “better”.
Instead of such easy replies, try with: s/cool/nice/
Every reply from you reads as
- I don't see the need
- I don't like it
- Could theoretically be done in another way
while systemd provides an easy consistent way for *every* service. No
rewriting needed. You can easily change some options.
> >SysV init scripts do not even *have* a reliable dependency system.
>
> Sequential booting worked fine for ages, and mostly still does
> (with file-rc, although insserv certainly introduced trouble).
It may have worked fine, but doesn't dismiss the argument that the other
design is better / improved vs the old one.
> >The SysV manager can tell that the thing started and didn't exit
> >nonzero, but that's not always the same thing as "running".
>
> The initscript is supposed to exit nonzero if the dæmon does not
> run. Sure, not too many initscripts do that, but still. (If you
> want a good example, look at postgresql’s, except it doesn’t wait
> long enough on some slow systems.)
"doesn't wait long enough" is enough IMO
You also raise the "supposed to", which is again theory vs practice.
With systemd you have various things which you can rely on. No need to
hope that the init script was properly written. If you want to change an
option you can. This without totally changing the init script to change
it in the way it was "supposed to" be written.
> >This is about features. Many of the features systemd provides (and which
> >I refuse to live without, having become accustomed to them over the last
> >year or so) are, by basic Unix design, not available to something that is
> >not PID 1.
>
> But not everyone needs or wants those features. And, as pointed
> out on the unshared /tmp example above, some of them may be
> positively harmful to maintenance of the system in question.
You didn't point it out, you said it makes it complicated without
stating why.
--
Regards,
Olav
Reply to: