Re: Proposal for next steps for systemd-related policy
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
Reply to: