I've now found that the issue was that the service file automatically generated by systemd-sysv-generator lacks an install section with a WantedBy option. I added the following to my generated file at /etc/systemd/system/programexample.service which allowed me to properly enable the service:
[Install]
WantedBy = multi-user.target
After that I ran
systemctl daemon-reload
to ensure my service file was read by systemd.
Now I received a proper notification that my service was actually symlinked somewhere to be "enabled":
[root@centos7-box ~]# systemctl enable programexample.service
Created symlink from /etc/systemd/system/multi-user.target.wants/programexample.service to /etc/systemd/system/programexample.service.
This link helped me better understand the service file.
I am not a fan of the way that systemd-sysv-generator does not include an install section with a WantedBy option by default. If systemd can dynamically read the LSB headers and properly start services at boot, why doesn't it generate the service file accordingly? I suppose some systemd growing pains are to be expected.
Update July 7 2020:
Working with Debian Buster and trying to enable a SysVInit legacy service, I was presented with this wonderful message, which I believe would have saved me some time when I dealt with this issue in 2017:
Synchronizing state of programexample.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable programexample
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
I marked your question as a duplicate.
Read JdeBP great answer here: How does systemd use /etc/init.d scripts?
Received wisdom is that the System V rc scripts 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-generator can recognize the more limited old RedHat comment headers (description:, pidfile:, and so forth). Moreover, in the absence of an LSB header it will fall back to the contents of the /etc/rc?.d symbolic 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.d didn't appear to matter is that you probably had that script enabled via another /etc/rc?.d/ directory. systemd-sysv-generator translates being listed in any of /etc/rc2.d/, /etc/rc3.d/, and /etc/rc4.d/ into a native Wanted-By relationship to systemd's multi-user.target. Run levels are "obsolete" in the systemd world, and you can forget about them.
The question of what the search path is, is in fact actually addressed by what you quoted in your question:
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.
In more detail:
- For the scripts themselves:
systemd-sysv-generator looks for an environment variable named SYSTEMD_SYSVINIT_PATH.
- Each directory is scanned for regular files that have the owner execute permission bit set on, with earlier directories in the path overriding later ones (a mechanism not really exercised in the default case of just the one directory in the search path) and the existence of service units with the same names inhibiting the generation of these nonce ones.
- For the "symbolic link farms":
- There is a similar environment variable named
SYSTEMD_SYSVRCND_PATH.
- Each directory is scanned for subdirectories named
rc[2345].d, which are in turn scanned for directory entries that begin with S and two decimal digits and that are at least 4 characters long. The directory entries are not dereferenced.
Notice that systemd-sysv-generator …
- … does not look at the
K* stuff;
- … does not check that the symbolic link farms are actually filled with symbolic links (They could be character special files or FIFOs for all that it cares, as it only looks at the names.); and
- … does not process the runlevel information from LSB comments (i.e. the
Default-Start: and Default-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 Smoorenburg rc in systemd terminology: the symbolic link farms are the service enable controls, that determine what services are automatically started at bootstrap; whereas the Default-Start: and Default-Stop: comments are (very approximately) service preset controls, that are turned into the enable controls.
Best Answer
These are system facility names in Linux Standard Base. They're not treated like shell variables, they're just special names allowing init scripts to depend on certain system states.
In particular,
$remote_fsand$syslogare defined as follows: