Bug#727708: init system other points, and conclusion
Hi Ian,
My apologies in advance for answering only to one email, but quoting
several. It could be that you had some threading in mind which my reply
might break.
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> * systemd's readiness protocol is an unattractive implementation
> target for an upstream daemon author. I think this is an important
> weakness, if it remains unaddressed.
We talked about this in #732157 already, but I think it is worth
summarizing it here: for modern daemons, libsystemd-daemon is a widely
available library which can be trivially added. In case dependencies
absolutely need to be kept at a minimum, the less preferably alternative
of dropping that library’s code into the daemon’s code base exists. If
both of those are unsatisfactory, one can implement it by oneself, which
you deem unattractive. I tend to agree, but I think you are overstating
this as an “important weakness”. Most daemons do not even need any
readiness notification whatsoever. Using socket activation or forking
after initialization is enough.
> I'm treating the config fragments as part of the packaging, rather
> than as something upstreamish, because in practice they are inherently
> un-debuggable without access to a system running the corresponding
> daemon. They are also small enough that any distro which cares could
> easily ship their own (and might need to).
I don’t understand that reasoning. By “daemon”, do you mean init system
or actual daemon for which the service file is intended? Also, why would
a distro ship its own? Even in the rare case that an upstream-provided
service file is (and stays!) unsuitable for Debian, a patch is all that
is necessary.
> There was less support from the Debian policy manual. Perhaps there
> is some other systemd Debian packaging guidance somewhere which I
> didn't find.
There is https://wiki.debian.org/Systemd/Packaging which is the first
Google hit for “debian systemd packaging”. Until a while ago, the page
was changing a lot while we were still hashing out details about
packaging. By now, I’d say we could add this to the policy manual.
> The unit files were somewhat harder to write. It wasn't just that the
> systemd unit file offered a great many more options, although that was
> a factor. The two-unit split of systemd socket activation was more
> fiddly. And systemd wants each directive to be in a particular
> "[section]".
See also http://0pointer.de/blog/projects/systemd-for-admins-3.html
(“How Do I Convert A SysV Init Script Into A systemd Service File?”).
I do admit that this is hard to find if you don’t know it exists. It
_is_ linked to from the main systemd website, though, but I cannot
expect that everybody reads the entire body of documentation.
> Also, the approach to the systemd integration introduces a new runtime
> package dependency on "init-system-helpers", which despite its
> generic-sounding name actually contains only helpers for systemd and
> is maintained in Debian by the systemd maintainers.
It has already been pointed out elsewhere in the thread, but given that
I introduced this package, I’d like to stress again that I will gladly
accept other init system’s helper programs to this package. The package
name and description is not misleading; I really mean it.
> The same appears to be the case for systemd's interactions with Debian
> as a downstream. Pressure has had to be applied on issues such as
> separate /usr (and much documentation still contains claims that this
> is "broken"); I asked for systemd to be able to execute programs from
> PATH rather than requiring unit files to specify the absolute path and
> was rebuffed (#...)
#732981 is the bug reference that you didn’t include by accident, I
think :).
> This is exacerbated by the fact that systemd's Debian maintainers are
> (IMO) much too deferential to upstream.
> […]
> In short, the systemd community feels, to me, arrogant and
> controlling. I am far from the first to say something like this, but
> I've now experienced things for myself and I concur with the
> criticism.
Given that I am the one who responded to both your referenced bug
reports, let me provide my perspective in this bug. Upstream does not
want to provide the features you asked for, and I’ll not comment on
that, apart from stating that it’s not obvious that they are a good idea
(one can see that from the discussion on the bugs).
You then asked for these features to be carried as a patch in the Debian
systemd package, and both requests were rejected. I think this is what
you refer to when saying “the systemd Debian maintainers are much too
deferential to upstream”. The reason why we don’t want to carry these
patches is that they significantly alter the public API between systemd
and the daemon authors — but in Debian only!
As stated in the bug, my rule of thumb is whether people need to
differentiate between Debian and “all other distributions”. E.g., with
your simpler readiness notification proposal, daemon authors could use
that on Debian, but would need to conditionally compile code for Debian
while they also still need to ship code for the current API. This is not
a simplification at all. Similarly, with the $PATH thing, we’d introduce
the need to patch _every_ single upstream unit in our Debian
packages. Even worse, unit file authors would be surprised when their
unit file does not work on other systems when it was written and tested
on Debian (where one could use $PATH).
> Furthermore, in my view the responses of Debian's upstart maintainers
> to my bug reports about upstart have been exemplary. There has been,
> for example, no resistance (from them or AFAICT from upstream) to
> supporting the systemd socket activation protocol.
I’d like to point out that with features that are universally accepted
(and especially by upstream), the response of systemd contributors was
exemplary, too. Zbigniew Jędrzejewski-Szmek in particular has reacted to
documentation clarification requests and even feature requests like the
globbing of units in record time. Thanks for that!
--
Best regards,
Michael
Reply to: