Re: systemd services that are not equivalent to LSB init scripts
On Sun, Jul 14, 2019 at 07:23:31PM +0100, Simon McVittie wrote:
> micro-httpd appears to be an example of this - I'm a bit surprised
> there aren't more. Perhaps this indicates limitations in the infrastructure
> around inetd services making it hard to implement "use systemd.socket(5)
> under systemd or inetd otherwise"?
I'll note that it's a bit tricky even in the cron vs systemd.timer use
case. That's what I was referring to when I said we had to go through
some effort just to enable the "use cron" functionality, since we had
to make sure that this was inhibited in the case where cron and
systemd is enabled on the system.
So requiring support of non-systemd ecosystems is in general, going to
require extra testing. In the case of cron/systemd.timers, this means
testing and/or careful code inspection to make sure the following
cases work:
* systemd && cron
* systemd && !cron
* !systemd && cron
Support of non-systemd ecosystems is not going to be free, and some
cases, it is not going to be fun, something which many have asserted
should be something we should be striving for. The challenge is how
do we develop the consensus to decide whether or not we force
developers to pay this cost.
And if we don't, is it better to just let this rot where we allow
developers to violate current policy with a wink and a nudge until
it's clear that we do have consensus? Or do we force them to do the
work? Or do we somehow go through the pain and effort to try to
determine what that consensus actually is?
- Ted
Reply to: