Of course it does.
If they weren't started by the service management subsystem, they won't be tracked by the service management subsystem. And they won't be proper dæmons, really.
background on van Smoorenburg
rc compatibility mechanisms
further reading: https://unix.stackexchange.com/a/233581/5132
The van Smoorenburg
rc compatibility mechanism provided by systemd is a generator. It ensures that there is a generated
abc.service service that runs
/etc/init.d/abc start at service start and
/etc/init.d/abc stop at service stop.
Note, at this point, that the existence of
/usr/lib/systemd/system/abc.service completely prevents the generation of an
abc.service by systemd's generator.
This is the entire extent of van Smoorenburg
rc compatibility in vanilla systemd. The ability for the superuser to directly invoke
/etc/init.d/abc in various ways, and have that connect up to systemd is provided as an augmentation to vanilla systemd by the operating system's individual developers.
The Debian and Ubuntu people, for example, provide a hook in their own
/lib/lsb/init-functions.d/ subsystem that acts as follows:
- If the hook detects that the
init.d script is being invoked as the ExecStart/ExecStop of a generated systemd service, it does nothing special and just runs the rest of the script as it stands.
- If the hook detects that the
init.d script is being invoked directly, not as part of a generated systemd service, it transforms
/etc/init.d/name verb into
systemctl verb name and switches to that, not running the rest of the script. (Some verbs it passes through, but you are talking of
stop, which are handled in the way explained here.)
in the absence of the compatibility mechanisms
Not all operating systems have such a van Smoorenburg
rc compatibility mechanism that translates the direct invocation of
/etc/init.d/name verb into systemd's way of doing things. Some operating systems (such as the one run by the person at "Why does `init 0` result in "Excess Arguments" on Arch install?", for example) provide no van Smoorenburg
rc compatibility at all, not providing a hook like Debian's/Ubuntu's and even outright disabling the compatibility mechanism that comes with vanilla systemd.
On such an operating system, running the van Smoorenburg
rc script directly just runs that script as-is.
Such a script does not start a service under service management. It does things such as double-forking and whatnot, in vain and in most cases fruitless attempts to run in the same environment that actual service dæmons run in. (Much of this so-called "dæmonization" stuff does not work and has not worked since the 1980s; this being the reason that proper dæmon management systems were invented in the early 1990s in the first place.) But as far as service management is concerned it is just the superuser in an interactive login session forking stuff.
Indeed, systemd will consider such directly invoked van Smoorenburg
rc scripts and all of the vainly "dæmonized" programs that they fork off into the background to be running as part of the user's interactive session scope inside the user's slice, not as services that run outwith user sessions in the system slice.
Worse, it ends up using the highly flawed mechanisms of the van Smoorenburg
rc system, such as killing all processes running anywhere that match the service name at service stop, instead of just the specific service processes that the service manager started and is tracking. This is why
/etc/init.d/name stop is appearing to work for you. The script is killing all processes that match a name, which just happens to also include the processes that run under the service manager. This indiscriminate killing of everything is a bug, though, not a feature. This is only the appearance of proper functionality, and it will bite you down the road, as it has bitten so many system administrators in the past several decades.
the correct thing to do
If you lack such compatibility mechanisms, then do not invoke van Smoorenburg
rc scripts directly. It is as simple as that. Use the
systemctl commands to communicate with systemd's service management; but do not run
/etc/init.d/anything directly for stopping, starting, and obtaining the statuses of services.
A subordinate point is that you should not be mucking around with
/usr/lib/systemd/system/abc.service just to try to bodge the van Smoorenburg
rc script into sort-of working.
Type=forking is almost certainly wrong for your service. (It does not match almost all actual services in the wild.) And if the people who came up with
/usr/lib/systemd/system/abc.service managed to get rid of the well-known-to-be-broken PID file mechanism that is wholly unnecessary for true service management, it is outright daft to be putting it back in again.