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

Re: Bug#727708: tech-ctte: Decide which init system to default to in Debian.

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.

>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

Ugh, bad server design.

>Or a way to determine that it has started up correctly?

An initscript is supposed to not return before it did that.

>determined environment without stupid surprises like a LOCALE 

That’d be the domain of the aforementioned helper.

>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”.

>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).

>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.)

>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.

„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
	-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Reply to: