I's probably worth spending a little time trying to get some understanding of the way in which sysVinit and systemd systems work, and in particular, how elements of the two systems can interact.
Before systemd existed, sysVinit systems ran most distros. When systemd appeared, it didn't necessarily eliminate all elements of sysVinit, rather it subsumed and integrated them in many cases.
Since systemd's birth, amongst the distros that have adopted it, many, if not most, have included sysVinit elements in their systems. The example that follows uses a debian systemd installation. The sysVinit elements are apparent if you look into the /etc/init.d directory, and see output such as:
Code:
[tom@min /etc/init.d]$ ls
alsa-utils bluetooth cups-browsed keyboard-setup.sh ofono speech-dispatcher
anacron connman dbus kmod procps ssh
apparmor console-setup.sh dundee lightdm pulseaudio-enable-autospawn sudo
atop cron glances lm-sensors rsync sysstat
atopacct cups gpm networking saned x11-common
And then check the output of the sysVinit style runlevel directories:
Code:
[tom@min /etc]$ ls -lR rc*
rc0.d:
total 0
lrwxrwxrwx 1 root root 20 Nov 15 08:29 K01alsa-utils -> ../init.d/alsa-utils
lrwxrwxrwx 1 root root 14 Nov 19 15:19 K01atop -> ../init.d/atop
lrwxrwxrwx 1 root root 18 Nov 19 15:19 K01atopacct -> ../init.d/atopacct
lrwxrwxrwx 1 root root 19 Nov 15 08:29 K01bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 17 Nov 15 08:29 K01connman -> ../init.d/connman
lrwxrwxrwx 1 root root 22 Nov 15 08:29 K01cups-browsed -> ../init.d/cups-browsed
<snip of large output>
All that output is pure sysVinit filesystem arrangement in a fully systemd functioning system.
What's worth understanding is that each of the sysVinit scripts in the /etc/init.d directory, are converted by systemd on this system, into systemd service units, and then implemented with original intended outcomes of the scripts given effect just the same as if they were run natively as sysVinit scripts. It's quite clear that they are sysVinit scripts if you inspect the contents of any of the files in /etc/init.d. They comply with the necessary sysVinit formatting.
Systemd can thus run a sysVinit style system, and actually does so in the case above, but the reverse is not necessarily the case. A sysVinit system that doesn't have the software to run a systemd system, cannot do it unless it includes the systemd software. Many sysVinit style systems don't do that because of the overheads, redundancy and policy of the creators.
Systemd accomplishes it's conversion of sysVinit scripts to systemd services by the use of what it calls "generators", and sets them up in a tmpfs to run making them available transparently to the user. Systemd has many services that are not in the sysVinit format which is apparent if you inspect the /lib/systemd/system directory which houses many other services.
The notion of what a distro "should" or "should not" do, is a subjective matter and it's a questionable discussion to have without an examination and explanation of the original intentions, justifications and rationalisations of the developers. Not all opinions have the same value. Those that are more informed are likely to carry more weight.
