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.
