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 Vrc
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:
- First, systemd activates
runlevel<N>
.target, where N is the runlevel.- For each symbolic link in
/etc/rc<N>.d
, systemd identifies the script in /etc/init.d.- systemd associates the script name with a service unit (for example, /etc/init.d/foo would be foo.service).
- systemd activates the service unit and runs the script with either a start or stop argument, based on its name in
rc<N>.d
.- 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 :.
Best Answer
I marked your question as a duplicate.
Read JdeBP great answer here: How does systemd use /etc/init.d scripts?
The question of what the search path is, is in fact actually addressed by what you quoted in your question:
In more detail:
systemd-sysv-generator
looks for an environment variable namedSYSTEMD_SYSVINIT_PATH
.systemd-sysv-generator
scans one by one.systemd-sysv-generator
falls back upon a compiled-in default, which in vanilla systemd is the single directory/etc/init.d/
.SYSTEMD_SYSVRCND_PATH
.systemd-sysv-generator
scans one by one.systemd-sysv-generator
falls back upon a compiled-in default, which in vanilla systemd is the single directory/etc/rc.d/
.rc[2345].d
, which are in turn scanned for directory entries that begin withS
and two decimal digits and that are at least 4 characters long. The directory entries are not dereferenced.Notice that
systemd-sysv-generator
…K*
stuff;Default-Start:
andDefault-Stop:
comments).Remember, in respect of the third point, that in vanilla van Smoorenburg
rc
the runlevel information from LSB comments does not directly control bootstrap/shutdown behaviour. That's the remit of the symbolic link farm directories. Describing van Smoorenburgrc
in systemd terminology: the symbolic link farms are the service enable controls, that determine what services are automatically started at bootstrap; whereas theDefault-Start:
andDefault-Stop:
comments are (very approximately) service preset controls, that are turned into the enable controls.