Bug#727708: init system discussion status
"Alexander E. Patrakov" <patrakov@gmail.com> writes:
> 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.
This is fine for daemons that don't fork (as you say, start-stop-daemon is
probably adequate), but less appealing for daemons that are written to
require socket activation. You would basically have to write the socket
binding code that systemd provides.
That being said, this problem seems fairly theoretical. I'm not aware of
any upstream code that *requires* socket activation and that people want
to package for Debian for jessie, so I'm inclined to err on the side of
supporting interoperability with sysvinit for the next stable. If the
problem later comes up, we can always take a look.
If we select either upstart or systemd, we're going to be taking a rather
dramatic step forward. I don't think there's a need to rush it too much,
and there are some major advantages in allowing users to switch back to
sysvinit in jessie if they need to. (More on that in a later message.)
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: