On Sat, 21 Nov 2020 at 10:42:04 +0100, Vincent Bernat wrote: > I don't think this is very common. Init scripts are very specific to a > distribution. A Debian init script cannot be used for Redhat. A SUSE > init script does not work with Redhat. I find doubtful that the > compatibility would be better with the BSD init scripts (this may not be > what you meaned). AFAIK, OpenBSD does not use initscripts. A FreeBSD > initscript is unlikely to work on any Linux as it sources /etc/rc.subr. > > From my experience, when upstream ships an init script, this is usually > unsable by most distributions (not to the standard), so it has to be > rewritten. Init scripts are not contributed upstream as upstream doesn't > want to handle all this complexity.
For what it's worth, as an upstream and Debian maintainer of dbus, I removed the LSB-style init scripts for Red Hat and Slackware from the upstream source code of dbus, because nobody was testing them and so I had no confidence that they continued to work (Red Hat moved to Upstart and then to systemd, and Slackware used their own init script instead of the one provided upstream, so the relevant downstreams were not even using the versions that were part of dbus stable releases, and they certainly weren't testing development releases). dbus in Debian continues to have a LSB init script that was never sent upstream; Debian is better-placed to maintain that than upstream is (even though at the moment it would be me making changes either way!), and it can continue to take advantage of Debianisms like start-stop-daemon. The LSB/sysv-rc interface (execute arbitrary code, which is going to be a lot simpler if it relies on distro-specific facilities like start-stop-daemon) does not really lend itself to writing portable init scripts. The few portable init scripts that I have seen have generally had robustness issues, precisely because they bend over backwards to avoid using distro-specific facilities. Echoing what Vincent said, my experience has been that systemd units *can* typically be used unmodified across distributions - partly because they are declarative, partly because the upstream part of systemd provides facilities to do typical system service things without having to open-code them or rely on a helper like start-stop-daemon (for example tracking lifetime, dropping privileges, and sending SIGTERM to terminate gracefully or SIGHUP to reload), and partly because the "drop-in" mechanism gives us a way to add distro overrides where needed without necessarily having to patch the unit. smcv