Re: Is missing SysV-init support a bug?
On 26 August 2016 at 00:11, Sven Hartge <sven@svenhartge.de> wrote:
> Hi all!
>
> I just saw the new conntrack-tools (1:1.4.4-2) package in Sid, which
> has as a change
>
> * [917beed] conntrackd: get rid of the sysvinit support
>
> and I wondered, if this is a bug (and at what severity) or not.
>
> While I run all my personal computers on systemd (on Sid) and nearly all
> servers at work have been switched to systemd during the Wheezy->Jessie
> upgrade, there will still be people left running the classic SysV-Init
> and as far as I know it has not been deprecated/removed for Stretch.
> So leaving them out in the cold like this seems wrong to me.
>
Hi!
here the author of that changelog line.
The rationale for the change was:
* the default init system in debian is systemd
* I don't have any sysvinit system to keep sysvinit files under any
kind of maintenance
* sysvinit conntrackd script is really poor, to reliably use
conntrackd as a systemd daemon you should use systemd
* conntrackd & systemd are very good integrated (using libsystemd)
* systemd is starting to drop support for some sysvinit mechanisms [0]
* it's time to let sysvinit die
So, obviously from my point of view, lack of sysvinit support is not a bug.
The conntrackd software is a very specific daemon which is usually run
in a very concrete scenario.
In most of these scenarios, you will need the software to be started
and stopped *reliably*,
ordering other system services with it *reliably* (for example, at system boot).
Right now, conntrackd is integrated with libsystemd so the daemon
reports startup & shutdown
reliably to systemd (also includes watchdog support).
If you are about to build a firewall cluster and you choose between
sysvinit and systemd,
no serious implementation would use sysvinit, so I think the sysvinit
support here is simply irrelevant.
[0] https://sources.debian.net/src/systemd/231-4/debian/systemd.NEWS/
--
Arturo Borrero González
Reply to: