By default in Debian 9 systemd is the default. But I still see a lot of things under /etc/init.d directory. Does that mean I still can put things there to start up? Which directory (systemd or init.d) will be executed first?

  • The scripts in init.d will only be executed if there is no systemd-specific until file for that service. – jordanm May 21 '19 at 19:26
  • so: all systemd service will be executed first; then init.d service which are not started from systemd, right? In another word, init.d still work fine in Debian 9, right? – michael morgan May 21 '19 at 19:44
  • The ordering will be a lot more complicated than that. init.d will work fine, but I would advise against using it. – jordanm May 21 '19 at 19:46
  • ok. Some important packages I installed (nis, nfs) seem still putting service files under init.d instead of systemd. – michael morgan May 21 '19 at 20:17

When 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:

# 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.

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 $remote_fs, $network, $named, $portmap and $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.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.