Re: systemd services that are not equivalent to LSB init scripts
On Sun, 14 Jul 2019 at 09:21:37 -0400, Theodore Ts'o wrote:
> P.S. I'm going to be adding an override in e2fsprogs for
> package-supports-alternative-init-but-no-init.d-script because it
> has false positive, regardless of its claim:
>
> N: Severity: important, Certainty: certain
>
> It most *definitely* is not certain. We went through quite a bit of
> trouble providing alternative functionality via cron, and not via
> (only) systemd timers.
Every LSB init script is equivalent to a systemd service that is
"required" or "wanted" by one of the targets that are reached during boot,
but the converse is not true. Not every systemd service is "required"
or "wanted" by those targets: some systemd services start on-demand,
which is not a concept that exists within the narrower scope of LSB
init scripts. Some of the triggering events have equivalents (at least
approximately) in a broader non-systemd ecosystem that includes things
like cron; others do not.
Putting this one first because I think it's the least ambiguous:
Some systemd system services are meant to be started on-demand via
D-Bus activation (/usr/share/dbus-1/system-services/*.service with
SystemdService= pointing to a systemd.service(5)). If the D-Bus
service has a suitable Exec= line, then dbus-daemon can launch the
daemon via traditional D-Bus activation (dbus-daemon-launch-helper)
on non-systemd-booted systems; but on a systemd system it's best if it
configures SystemdService= to delegate that job to systemd, because unlike
systemd, dbus-daemon is not really designed to be a service manager,
and is certainly not a fully-featured service manager. udisksd in the
udisks2 package is one of the canonical examples of this pattern. This
is probably not allowed by a strict reading of Policy, but in the case
where traditional activation already works (which in practice it usually
does) there's clearly no actual functional bug for non-systemd users -
the service is working as well as it ever did - so it should be allowed.
Some systemd system services are meant to be triggered by systemd timers
(systemd.timer(5)), which trigger execution of a systemd service when
the timer "goes off", and can have an analogous (ana)cron job used on
non-systemd-booted systems. It sounds as though your use-case in e2fsprogs
is a good example of this; apt is another. As with D-Bus above, this
doesn't seem to be allowed by a strict reading of Policy. I think the case
where there is an approximately equivalent cron job should certainly be
allowed. If there is no equivalent cron job, I would personally say that's
a bug but probably not RC; it would be in the spirit of previous Technical
Committee decisions on init systems to expect maintainers to apply good
patches, if someone with an interest in non-systemd inits contributes
a cron job that doesn't seem like it will harm future maintenance.
Some systemd system services are meant to start on-demand via socket
events (systemd.socket(5)), and can work via inetd on non-systemd-booted
systems. 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"?
Some systemd system services are meant to start during suspend/resume by
hooking into targets like suspend.target, and could presumably work via
/etc/pm or /etc/acpi or whatever else non-systemd users use for power
management events on non-systemd-booted systems (I've lost track of what
that would be). tlp-sleep.service in the tlp package is an example, which
appears to hook into elogind via /lib/elogind/system-sleep/49-tlp-sleep,
a mechanism of which I was not previously aware.
Some systemd system services (I don't know of any examples in Debian)
are meant to be triggered by an inotify event (systemd.path(5)), which
could presumably have an equivalent using something like the incron
package if non-systemd users want it badly enough. I don't think the
maintainers of any systemd services that make use of that mechanism
should be expected to invent a whole parallel infrastructure that they
will not, themselves, use, but if non-systemd users build a suitable
mechanism, then it might be reasonable to expect service maintainers
to apply patches that add simple integration "glue" files analogous to
.path units for that other mechanism.
I've deliberately been saying "the non-systemd ecosystem" rather than
"the sysvinit ecosystem" because the latter would be very misleading -
sysvinit itself is really very simple, and its only contribution to any
of this is to run /etc/init.d/rc at runlevel changes. For full coverage
of equivalents of the units I described above it would be at least the
sysvinit/sysv-rc/cron/anacron/dbus-daemon-launch-helper/inetd/elogind/incron
ecosystem, and I'm sure I've missed some.
systemd system services can also be linked to an arbitrary non-boot
unit by declaring that they are WantedBy the other unit, and I don't think
there can be a general solution for that in the non-systemd ecosystem.
smcv
Reply to: