Systemd is not fully backwards compatible with System V init scripts
One of systemd's selling points is that it's backwards compatible
with your existing System V init scripts, so that you can do a
gradual transition instead of having to immediately convert all of
your existing SysV init scripts to systemd
.service files. For
the most part this works as advertised and much of the time it works.
However, there are areas where systemd has chosen to be deliberately
incompatible with SysV init scripts.
If you look at some System V init scripts, you will find comment blocks at the start that look something like this:
### BEGIN INIT INFO # Provides: something # Required-Start: $syslog otherthing # Required-Stop: $syslog [....] ### END INIT INFO
Real System V init ignores all of these because all it does is run init scripts in strictly sequential ordering based on their numbering (and names, if you have two scripts at the same numerical ordering). By contrast, systemd explicitly uses this declared dependency information to run some SysV init scripts in parallel instead of in sequential order. If your init script has this LSB comment block and declares dependencies at all, at least some versions of systemd will start it immediately once those dependencies are met even if it has not yet come up in numerical order.
(CentOS 7 has such a version of systemd, which it labels as 'systemd 208' (undoubtedly plus patches).)
Based on one of my sysadmin aphorisms,
you can probably guess what happened next: some System V init scripts
have this LSB comment block but declare incomplete dependencies.
On a real System V init script this does nothing and thus is easily
missed; in fact these scripts may have worked perfectly for a decade
or more. On a systemd system such as CentOS 7, systemd will start
these init scripts out of order and they will start failing, even
if what they depend on is other System V init scripts instead of
things now provided directly by systemd
This is a deliberate and annoying choice on systemd's part, and I maintain that it is the wrong choice. Yes, sure, in an ideal world the LSB dependencies would be completely correct and could be used to parallelize System V init scripts. But this is not an ideal world, it is the real world, and given that there's been something like a decade of the LSB dependencies being essentially irrelvant it was completely guaranteed that there would be init scripts out there that mis-declared things and thus that would malfunction under systemd's dependency based reordering.
(I'd say that the systemd people should have known better, but I
rather suspect that they considered the issue and decided that it
was perfectly okay with them if such 'incorrect' scripts broke.
'We don't support that' is a time-honored systemd tradition, per