Bug#727708: loose ends for init system decision

[Russ Allbery <rra@debian.org>]

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> Well, no.  I think that even if we select upstart as the default, we
> should enable the systemd community to provide as complete a set of
> integration in Debian as they care to put the work in for.

> That translates directly to an expectation that the maintainer of any
> daemon package must be willing to accept reasonable systemd integration
> patches.

> If the systemd community is very dynamic (and certainly we can't fault
> their dynamism so far) this may well translate to all or almost all
> daemons.  Certainly it could be expected to include most of the core
> daemons where the extra dependencies are most troublesome.

> So I think we need to say what we regard as "reasonable" patches, in
> advance.  As the Debian maintainer for uservd (for example), am I
> entitled to decline to incorporate systemd integration into my package
> on the grounds that the patch involves additional build- and runtime
> dependencies which I consider undesirable ?

Ah!  Okay, now I understand why you think this is linked and something we
should decide here.  Thank you.

Okay, so let me see if I understand what we agree on and what we would
need to debate.  Would you agree with both of these statements?

* If we adopt systemd, then obviously integration with systemd would be
  desirable and should be accepted, including build and runtime
  dependencies as is appropriate for how systemd is integrated into the
  distribution as a whole.

* If a maintainer wishes to integrate with systemd via build and runtime
  dependencies in their daemon, that would be their call, not something
  the TC would decide.  (I think you do agree with this given the
  statement below, but leaving this in as summary.)

If so, then the problem reduces to what to do in the case where someone
requests integration with systemd via a bug report and the maintainer
doesn't want to provide that integration, at least with build or runtime
dependencies or both.

Let's put aside the question of how to handle this on the ports that don't
have systemd for the moment, and hence the conditional build integration
parts, since that was discussed in the other thread and I think there are
possible lightweight schemes that are specific to the case where we just
want to stub out the calls.

I assume that the reason why you're bringing this up, per your original
message, is that you don't want to introduce either build or runtime
dependencies.  I don't, however, understand why; the logic doesn't make
any sense to me.  Both of those dependencies are so lightweight that I
have a hard time seeing how anyone would notice they exist, beyond having
a couple of packages installed on the system that wouldn't otherwise be.

I'm inclined to say that asking maintainers to add those dependencies is
appropriate.  I'm not aware of a precedent for this for something that
we're not committing to supporting for the archive, but it certainly
parallels other deployments in Debian, such as SELinux and multi-arch.

> I think the latter is the right approach, for two reasons.  Firstly, it
> is less work overall.  Secondly, it is proper that the maintainers of an
> init system should be encouraged to provide as simple and nonintrusive
> an integration interface as possible.

I believe that systemd has already provided this, and I find your belief
that it hasn't to be strange.  I certainly don't think that we will
succeed, or *should* succeed, in convincing systemd to adopt a new API
that offers no clear benefit over their existing API and is incompatible
with it.  If I were them, I'd reject it out of hand as a waste of time and
effort.

Incidentally, the tools in the init-system-helpers package are basically
playing the same role as tools that are in the sysv-rc package now.  I
think one could make a pretty good argument that, were we designing this
from scratch today without worrying about history or backward
compatibility, update-rc.d and invoke-rc.d would go into
init-system-helpers, since they're (now) general tools that support a
variety of underlying init systems.

If the dependency on that package is really such a burden, one thing we
could do is just move the two scripts in it into sysv-rc and use sysv-rc
as the package that holds those tools.  I don't really care, and I don't
mind having two packages, but looking at the current contents of both,
they're really quite close to the same thing.  (sysv-rc also continues to
provide a small amount of additional infrastructure for sysvinit, but it's
pretty limited.)

> I think maintainers should not be required to introduce the additional
> build- and runtime dependencies, if they do not wish to.  Obviously if
> they want to then that's fine by me.

Ah, good, okay.  This is less of a conflict than at first I thought we
had.

I definitely understand the desire to not impose requirements on package
maintainers that they don't like, and to minimize the impact of such
requirements.

>> If you feel like Policy should give advice on this, you can bring it up
>> in the context of Policy.

> The TC's mandate includes deciding on policy questions.

I know, but it also contains the following statement:

    Technical Committee makes decisions only as last resort.

    The Technical Committee does not make a technical decision until
    efforts to resolve it via consensus have been tried and failed, unless
    it has been asked to make a decision by the person or body who would
    normally be responsible for it.

Basically, I'm really uncomfortable having this sort of conversation here
among a rather small group of people.  I think it's likely that we're
going to miss implications or impacts, and in some cases it's quite
valuable to have more people available to provide a reality check.

> I'm afraid to say that this is quite a frustrating approach.

> If it will help I can go through the motions of filing a policy bug,
> having everyone point out that this is entangled with the whole init
> system debate, and having you reject my proposal.

> But perhaps we could just pretend I had done that ?

If we're going to discuss it here and now, then my recommendation for
systemd integration is to do what I did with lbcd: use the presence of the
LISTEN_FDS and LISTEN_PID environment variables to trigger socket
activation code, and use the presence of the NOTIFY_SOCKET environment
variable to trigger status notification.  In both cases, clear the
environment variables after recovering the data (unless you're using the
watchdog support) so that they aren't inherited by children.

I think this provides the most natural integration with systemd and
reduces the amount of fiddling that the packager has to do in setting up
the daemon configuration.  It has the advantage of letting the daemon work
either with socket activation or without, using the same unit
configuration, and continuing to work if one cuts and pastes the same
command line into the shell (to test something, for example).

It doesn't hurt anything if someone wanted to add another flag to the
daemon to tell it to look at those environment variables (as long as it
keeps working when that flag is given but they're not set -- that's
important for being able to switch from socket activation to not), but I
don't see any need to do so.

For upstart readiness, obviously one needs some sort of explicit flag or
trigger to enable the raise(SIGSTOP) behavior, since that will otherwise
cause rather obvious problems in getting the daemon to work outside of
upstart.  I prefer to use a command-line flag for this (-Z, per your
recommendation) since it has to be explicitly enabled and there isn't the
same sort of safe fallback if it's missing the way that there is for the
systemd protocol.  I don't see any real problem with using an environment
variable, though, as long as it's unset afterwards so that it's not
inherited by children.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>