Bug#727708: init system discussion status
Uoti Urpala wrote:
> Suppose an upstream releases a new daemon that is intended
> to be used with systemd using socket activation, and as such does not
> contain any code to do double-forking or open listening sockets. Would
> it be forbidden to package this daemon in Debian unless the maintainers
> are willing to add forking, other startup and socket code as Debian-
> specific patches?
Wrong question. As an author of one closed-source daemon that indeed
does not implement double-forking, I made my unofficial Debian package
depend on the "daemon" package. Result: the "daemon" utility performs
that double-forking dance for me and restarts my daemon if it crashes.
If the restart-on-crash functionality is not wanted, then the regular
start-stop-daemon should be sufficient.
So I'd say: Debian should support daemons that don't contain
double-forking or socket-opening code, and should do so without
patching such daemons. Patching or providing one Debian-specific
utility (e.g. start-stop-daemon) should be enough.
Or in other words: it is technically possible to write a
Debian-specific "universal readiness protocol translator" that wraps a
program that provides one readiness protocol and thus makes it
compatible with the init system that expects another protocol.
--
Alexander E. Patrakov
Reply to: