systemd starts up, or when
systemctl daemon-reload is run,
systemd runs a
systemd-sysv-generator program, which will make a list of
/etc/init.d scripts and generate corresponding
.service units for them unless a systemd-native
.service unit already exists for them.
The generator will interpret any LSB header blocks in
init.d scripts. They look like this:
### BEGIN INIT INFO
# Provides: apache2
# Required-Start: $local_fs $remote_fs $network $syslog $named
# Required-Stop: $local_fs $remote_fs $network $syslog $named
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# X-Interactive: true
# Short-Description: Apache2 web server
# Description: Start the web server
# This script will start the apache2 web server.
### END INIT INFO
Any described dependencies (here
$local_fs $remote_fs $network $syslog $named) will be translated into corresponding systemd dependencies. Because there is not always a simple one-to-one mapping between
init.d scripts and systemd services, some LSB dependencies like
$time are specially mapped into corresponding systemd
.target units by the generator.
The auto-generated wrapper services will simply run the corresponding
init.d script. All the wrapper scripts are ordered to run after systemd
basic.target, as soon as their dependencies allow. This makes the LSB headers rather important: if you're relying on the generator mechanism and your list of dependencies is incomplete,
systemd is quite likely to attempt running your
init.d script too soon, before the things it depends on are ready.
It's also possible that some packaged service has just one
init.d script, but two or more systemd service files (think about NFS services for example). In such cases, the package will not rely on the generator, but instead will provide both the
init.d script and the service files - with non-overlapping names. The package will also provide a symbolic link at
/lib/systemd/system/<name of init script>.service, pointing to
/dev/null. This makes
systemd treat the service autogenerated from the init script as permanently masked, and the native unit files will handle the service process(es) instead.