SysV, Upstart and systemd init script coexistence
Only one init system can be active at once. On 16.04, that's systemd.
A number of packages ship with files for multiple init systems, so they can be managed with multiple init systems on different OSes. On Ubuntu, sometimes scripts for multiple init systems get installed, even though they are not all used at the same time.
Newer init systems try to maintain compatibility with older ones. In particular, systemd tries to maintain compatibility with both Upstart and SysV init scripts.
In the case of the "init.d" script you mentioned, that is a "SysV" init script, not an Upstart script. Also, "SysV" init scripts would only be started on boot if they were symlinked to a directory like "/etc/rc5.d". You'll find that Network Manager does not have a symlink installed there.
To understand how systemd
manages old "SysV" init scripts, see How does systemd use /etc/init.d scirpts?.
Now, to answer the question about why it works to restart Network Manager with "service network-manager restart". The service
command is used with both Upstart scripts and SysV init scripts, preferring the former. Network Manager also has an Upstart script installed on 16.04 at /etc/init/network-manager.conf
.
If you review the output of sudo strace service network-manager restart
, you can get a sense of what's happening. First, the output shows that systemctl
is being called, indicating that the command is being redirected to systemd. First, shortly after it opens /usr/bin/service
, you can see it start to read in the file as a shell script:
open("/usr/sbin/service", O_RDONLY) = 3
...
read(10, "#!/bin/sh\n\n#####################"..., 8192) = 8192
Now that we know that service
is a shell script, we can go check out the source code of it. In the source code, we find that is_systemd
is detected and set. For the systemd case, you can see that the command gets rewritten to be systemctl restart network-manager
.
So while the three init systems co-exist and have some compatibility, there are layers of complexity. To minimize the complexity of what's happening going forward, it's best to use systemd unit files and the systemctl
tool to manage services.