Skip to main content

What is the default path that systemd uses to locate locate System V scripts?

edited body
Source Link
direprobs
  • 1.1k
  • 1
  • 18
  • 31
  1. First, systemd activates runlevelrunlevel<N>.target, where N is the runlevel. 2. For each symbolic link in /etc/rc.d/etc/rc<N>.d, systemd identifies the script in /etc/init.d. 3. systemd associates the script name with a service unit (for example, /etc/init.d/foo would be foo.service). 4. systemd activates the service unit and runs the script with either a start or stop argument, based on its name in rc.drc<N>.d. 5. systemd attempts to associate any processes from the script with the service unit.
  1. First, systemd activates runlevel.target, where N is the runlevel. 2. For each symbolic link in /etc/rc.d, systemd identifies the script in /etc/init.d. 3. systemd associates the script name with a service unit (for example, /etc/init.d/foo would be foo.service). 4. systemd activates the service unit and runs the script with either a start or stop argument, based on its name in rc.d. 5. systemd attempts to associate any processes from the script with the service unit.
  1. First, systemd activates runlevel<N>.target, where N is the runlevel. 2. For each symbolic link in /etc/rc<N>.d, systemd identifies the script in /etc/init.d. 3. systemd associates the script name with a service unit (for example, /etc/init.d/foo would be foo.service). 4. systemd activates the service unit and runs the script with either a start or stop argument, based on its name in rc<N>.d. 5. systemd attempts to associate any processes from the script with the service unit.
Source Link
direprobs
  • 1.1k
  • 1
  • 18
  • 31

What is the default path that systemd uses to locate locate System V scripts?

Is /etc/init.d the default search path that the systemd generator uses to convert native SysV script to unit files, and falls back to /etc/rc?.d or vice versa?

From this answer by @JdeBP:

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-generator generates the service units that run the System V rc scripts from /etc/init.d, if it doesn't find a native systemd service unit by that name already existing in the other six locations.

But, How Linux Works book mentions something different:

  1. First, systemd activates runlevel.target, where N is the runlevel. 2. For each symbolic link in /etc/rc.d, systemd identifies the script in /etc/init.d. 3. systemd associates the script name with a service unit (for example, /etc/init.d/foo would be foo.service). 4. systemd activates the service unit and runs the script with either a start or stop argument, based on its name in rc.d. 5. systemd attempts to associate any processes from the script with the service unit.

As far as I can tell, the procedure goes in the following way: systemd finds SysV scripts in /etc/init.d and depending on the runlevel, systemd decides to start or stop the scripts according to the symlink name (K* or S*) from /etc/rc?.d. This makes sense, because once the SysV script is converted into a native systemd unit file, the decision to start or to stop the process has to be obtained from /etc/rc?.d. For example, I'm running Ubuntu 17.04:

$ ls -l /etc/rc5.d lrwxrwxrwx 1 root root 15 Aug 4 00:10 S01acpid -> ../init.d/acpid lrwxrwxrwx 1 root root 17 Aug 4 00:10 S01anacron -> ../init.d/anacron lrwxrwxrwx 1 root root 16 Aug 4 00:10 S01apport -> ../init.d/apport lrwxrwxrwx 1 root root 22 Aug 4 00:10 S01avahi-daemon -> ../init.d/avahi-daemon ...many more... 

I can see that all of the symlinks to the scripts have the same execution order 01, and this is done intentionally so to exploit parallelism in systemd, so systemd-sysv-generator uses /etc/rc?.d to also determine the order of the dependencies (e.g, Before, After).

Since the LSB header within scripts determine the runlevel in which scripts are run, I'm more to likely lean towards the idea that systemd-sysv-generator defaults to /etc/init.d to decide which scripts to start in which runlevel instead of /etc/rc?.d, except if that can't be determined from the LSB header within the script. Are my assumptions right?

systemd-sysv-generator(8)

LSB headers[2] in SysV init scripts are interpreted, and the ordering specified in the header is turned into dependencies between the generated unit and other units. The LSB facilities "$remote_fs", "$network", "$named", "$portmap", "$time" are supported and will be turned into dependencies on specific native systemd targets.

But the man page doesn't mention anything related to the case where there's no LSB header. Pretty much over complicated :.