On Mon, Jan 01, 2018 at 08:42:52AM -0800, Josh Triplett wrote:
It seems easy enough to just write a "missing" init script, or accept a patch for one. It seems far harder to do so for a service that provides no daemonization support at all, expects socket or D-Bus activation, integrates with containerization, or otherwise makes use of the variety of mechanisms that make it far easier to write more capable and secure services these days.
I think the level of complexity is an important factor as well. For a simple "start this daemon" script, it's not a big deal. If the script needs to have a bunch of complex logic to support different use cases it doesn't make sense at this point to write both a systemd target and an init script--the init script isn't going to get much testing, and it's likely that there will be more bugs in the complicated logic than there'd be for someone who just hard codes their own requirements into rc.local (or whatever). As an example think of something like openvpn--if the init script didn't already exist, it would be a lot easier for someone to just kick off a single openvpn process than to make sure that all the logic that sets up multiple processes with different configurations was working properly on both systemd & sysvinit systems. As the number of sysvinit users continues to decline, I think simpler is better to minimize bugs in seldom-used code paths.
Mike Stone