Simon McVittie <s...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>