Re: If Linux Is About Choice, Why Then ...
On Sun, Apr 09, 2017 at 08:41:28AM +0100, Joe wrote:
> Someone correct me if I'm wrong, but I run sid and see things come and
> go. Didn't we have this:
>
> https://wiki.debian.org/LSBInitScripts
>
> long before systemd?
This and start-stop-daemon and probably a few other things are all
hacks that were layered on top of sysvinit, in an attempt to work around
its limitations and produce some kind of management system.
Ultimately, all of these hacks are fragile and doomed to failure.
The basic design concept of sysvinit is that you launch a daemon in
the background and record its PID in a file on disk. Later, if you want
to stop it, or see if it's still running, you open up this PID file,
read the PID from it, and ask the kernel about the process with that ID.
Sounds OK, right? At least, if don't have much experience with system
administration.
The problem is, PIDs get recycled. If the daemon died 17 days ago, and
something else came along and used that PID, the sysvinit approach of
checking that the PID is still running will give the wrong result.
Add to that the very real problem of the legacy behavior of daemons that
originated in the 1980s: they double-fork themselves into the background,
on purpose. This severs their tie to the parent process. That means
you can't even *get* the PID of the actual daemon from the outside.
The daemon itself has to discover its *own* PID and write that to a PID
file. And your init structure has to rely on that somehow? That's what
the start-stop-daemon hack was introduced to try to work around, by
the way.
Hacks on top of hacks to work around hacks. That's sysvinit. It is not
salvageable.
Does that mean systemd is the ideal replacement? No. Systemd has these
overreaching tendrils in places it's got no business sticking tendrils.
Why does it have its own ntp daemon? Why does it implement file system
automount behavior? These things already exist as userspace processes.
Mature, trusted userspace processes, sometimes with multiple competing
alternatives already.
But then on the other hand, what else would you use instead of systemd?
Nobody has proposed a superior alternative yet, that I've seen.
So, IMHO, the best thing to do is to use systemd, but don't use any of
its optional intrusive tendrils. Other people have other opinions, and
that's awesome. A healthy, vigorous competitive environment benefits
all of us.
My wheezy servers use wheezy's sysvinit + daemontools. My locally
installed services are managed by daemontools. Debian's services are
managed by sysvinit.
On my jessie machines, I have systemd (with its syvinit compat layer)
plus daemontools, started as a systemd service. I'm slowly transitioning
my local stuff from daemontools to systemd services, but I am in no hurry
to do so.
Reply to: