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. 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). 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. I think perhaps a better recommendation might be that it's preferred for systemd services that run daemons to run them as a foreground process (without forking or "daemonizing" during startup), with a footnote or parenthetical note saying that this recommendation is incompatible with Type=forking, which should therefore only be used if readiness-signalling is required and alternatives like the preferred Type=notify or Type=dbus are unavailable? 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. > - 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. smcv