Re: Proposal for next steps for systemd-related policy
Simon McVittie <smcv@debian.org> writes:
> On Sun, 29 Dec 2019 at 10:47:44 -0800, Russ Allbery wrote:
>> We probably also want to recommend Type=notify where possible and
>> Type=exec where not, over Type=forking, when the daemon supports
>> that.
> I'm not sure what you mean by "where possible" - it'll usually be
> possible to implement Type=notify (even if a libsystemd dependency is
> unacceptable or not feasible in the implementation language, the
> protocol is designed to be reimplementable) but it won't always be
> useful.
I mean something relatively modest. If upstream already supports
systemd's notification protocol, I think we should recommend that as the
best choice. (I'm dubious about asking Debian packagers to add support.)
> Type=exec doesn't provide a way for the daemon to signal that it has
> opened listening sockets or done whatever else is necessary for units
> that depend on it to be able to start without error, so daemons that
> might be depended on by other units will normally need to use either
> Type=notify, Type=dbus or Type=forking, then make sure they do basic
> setup (listen on sockets, etc.) before they notify, request their D-Bus
> names or do the traditional double-fork daemonization trick (whichever
> is appropriate for their Type).
Ah, yes, it's a good point that Type=forking when properly implemented is
somewhat better than Type=exec on getting dependency ordering correct.
But this is the sort of nuance that I think we should document somewhere.
Getting Type=forking right is surprisingly complicated. The best
documentation for how to do that I've seen is, ironically, in the systemd
documentation, in daemon(7). If the daemon double-forks and exits and
then binds to network sockets and so forth, which is common, the
advantages over Type=exec are basically lost.
> However, I don't think this is necessarily in-scope for Policy?
> Implementing readiness-signalling if required seems like it might be the
> sort of "don't be buggy" requirement that shouldn't necessarily need to
> be said explicitly.
Right, what I think is in scope for Policy is advising packagers on which
readiness signaling mechanism to use if upstream supports several. If one
is relatively new to packaging daemons, this may not be something on one's
radar to look at, but there are substantial, if subtle, advantages to
using Type=notify if upstream already supports it. (Type=dbus is fine, of
course, and we probably shouldn't doument that as well, although my guess
is that things that register with D-Bus are more likely to already know
about these subtleties.)
> I say "when run from a systemd service" so that services like
> dbus-daemon meet this recommendation - by default it double-forks for
> compatibility with LSB-style init scripts and its own historical
> behaviour, but the systemd unit dbus.service runs "dbus-daemon --nofork"
> which disables the double-fork code path, and I think that's a perfectly
> good implementation of what we want.
Yes, completely agreed.
>> - DynamicUser without useradd of a system user
> One warning for this one is that users referred to in dbus-daemon
> system.d/*.conf snippets, typically <policy user="..."><allow own="...">,
> currently need to be pre-created by sysusers.d, useradd or equivalent
> (because dbus-daemon resolves usernames to uids during its own
> startup/reload, to populate internal data structures that are all
> designed in terms of uids). Other references to users in non-D-Bus
> configuration might well behave similarly.
Right, there are a lot of subtleties for when DynamicUser can and can't be
used that we'll need to hash out and document.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: