How does systemd use /etc/init.d scripts?
I just switched to debian jessie, and most things run okay, including my graphical display manager
The thing is, I just don't understand how this works. Obviously my
/etc/init.d/wdmscript is called, because when I put an early
exitin there, wdm is not started. But when I alternatively rename the
/etc/rc3.ddirectory (my default runlevel used to be 3), then wdm is still started.
I could not find out how systemd finds this script and I do not understand what it does to all the other init.d scripts.
- When and how does systemd run init.d scrips?
- In the long run, should I get rid of all init.d scripts?
chaos' answer is what some documentation says. But it's not what systemd actually does. (It's not what van Smoorenburg
rcdid, either. The van Smoorenburg
rcmost definitely did not ignore LSB headers, which
insservused to calculate static orderings, for starters.) The Freedesktop documentation, such as that "Incompatibilities" page, is in fact wrong, on these and other points. (The
HOMEenvironment variable in fact is often set, for example. This went wholly undocumented anywhere for a long time. It's now documented in the manual, at least, but that Freedesktop WWW page still hasn't been corrected.)
The native service format for systemd is the service unit. systemd's service management proper operates solely in terms of those, which it reads from one of nine directories where (system-wide)
.servicefiles can live.
/usr/lib/systemd/systemare four of those directories.
The compatibility with van Smoorenburg
rcscripts is achieved with a conversion program, named
systemd-sysv-generator. This program is listed in the
/usr/lib/systemd/system-generators/directory and is thus run automatically by systemd early in the bootstrap process at every boot, and again every time that systemd is instructed to re-load its configuration later on.
This program is a generator, a type of ancillary utility whose job is to create service unit files on the fly, in a tmpfs where three more of those nine directories (which are intended to be used only by generators) are located.
systemd-sysv-generatorgenerates the service units that run the van Smoorenburg
/etc/init.d, if it doesn't find a native systemd service unit by that name already existing in the other six locations.
systemd service management only knows about service units. These automatically (re-)generated service units are written to invoke the van Smoorenburg
rcscripts. They have, amongst other things:
[Unit] SourcePath=/etc/init.d/wibble [Service] ExecStart=/etc/init.d/wibble start ExecStop=/etc/init.d/wibble stop
Received wisdom is that the van Smoorenburg
rcscripts must have an LSB header, and are run in parallel without honouring the priorities imposed by the
/etc/rc?.d/system. This is incorrect on all points.
In fact, they don't need to have an LSB header, and if they do not
systemd-sysv-generatorcan recognize the more limited old RedHat comment headers (
pidfile:, and so forth). Moreover, in the absence of an LSB header it will fall back to the contents of the
/etc/rc?.dsymbolic link farms, reading the priorities encoded into the link names and constructing a before/after ordering from them, serializing the services. Not only are LSB headers not a requirement, and not only do they themselves encode before/after orderings that serialize things to an extent, the fallback behaviour in their complete absence is actually significantly non-parallelized operation.
The reason that
/etc/rc3.ddidn't appear to matter is that you probably had that script enabled via another
systemd-sysv-generatortranslates being listed in any of
/etc/rc4.d/into a native
Wanted-Byrelationship to systemd's
multi-user.target. Run levels are "obsolete" in the systemd world, and you can forget about them.
- systemd-sysv-generator. systemd manual pages. Freedesktop.org.
- "Environment variables in spawned processes".
systemd.exec. systemd manual pages. Freedesktop.org.
In Debian the system-generators directory doesn't live on /usr/lib, but /lib https://packages.debian.org/sid/amd64/systemd/filelist
Thank you, thank you, thank you for this! Dealing with a mix of Debian 8 and RH/CentOS 7 systems has made management of SysVInit vs Systemd service dependency management a bit of a headache but this explanation of what systemd is doing has helped my understanding greatly.
This generator does work. I'd also mention, for followers, that if you have an older version of `systemd` and an /etc/init.d script isn't set to "boot on start" it will still work as expected but won't show up in the show-units lists: https://unix.stackexchange.com/a/518894/8337
This generator does work. I'd also mention, for followers, that if you have an older version of systemd and an /etc/init.d script that isn't set to "boot on start" it will still start/stop as expected using systemctl but won't show up in the show-units lists:https://unix.stackexchange.com/questions/517872/systemctl-list-all-possible-including-disabled-services/518894#518894 also NB that you basically "can't" control these service by running /etc/init.d/xx directly anymore or systemd gets...confused as to what is running and what isn't :|