Re: Minimal init

[Fernando Lemos <fernandotcl@gmail.com>]

On Fri, Jul 22, 2011 at 11:57 AM, Juliusz Chroboczek <jch@pps.jussieu.fr> wrote:
>>>No, I don't think so.  If these external tools double fork then they
>>>are just wrong.
>
>> Double Forking has been the right way to do it for decades.
>
> It has been the default way for most daemons, granted.  (Getty is
> a notable exception.)
>
>> Demanding from upstreams that they change their software this
>> fundamentally to cater for a new init system is [...] unrealistic
>
> Runit has been around for a decade or so.  Most daemons known to me have
> a command-line flag that prevents forking.
>
> Remember, preventing forking is about *removing* code from daemons, not
> adding new code.  Adding a flag to avoid forking is a trivial exercice,
> and it's a rare upstream that will refuse the usually trivial patch.

Well, to be fair, preventing forking is *adding* code to parse the
right option and skip the calls that do the double forking. It should
be, though, a fairly simple change.

>From what I've seen in Lennart's posts, adding systemd support doesn't
seem to be too complicated. Some bigger changes may be required for
more complex daemons. It's understandable that upstream might not
accept them at first. In an hyphotetical scenario where systemd
becomes the default init system in Debian, not having a systemd init
file could be an overridable lintian warning or something like that.

I'd like to stress that systemd apparently handles LSB scripts pretty
well, even running them in parallel whenever possible. I find it
perfectly natural that it'll take time for some upstreams to get
confortable merging those patches. Package maintainers that prefer not
to ship those patches could opt to ship a SysV init script instead.
This backwards compatibility isn't going away in the foreseeable
future.

I also think it wouldn't be wise for an upstream to ignore systemd
compatibility patches unless those require massive changes to the code
(which could be a symptom of more serious upstream problems or perhaps
bad design decisions).