[Linux]systemd和sysV

转自：https://www.cnblogs.com/EasonJim/p/7168216.html

在Debian8中systemd和sysVinit同时存在，NTP就是在/etc/init.d/ntp中启动

首先了解以下Ubuntu运行级别（init）对应工具的变化历史：

1、Ubuntu 6.10及以前版本使用Sysvinit。

2、Ubuntu 14.10及以前版本使用Upstart但是还留着Sysvinit并存。

https://wiki.ubuntu.com/Upstart

https://help.ubuntu.com/community/UpstartHowto

3、Ubuntu 15.04开始预设使用Systemd，但是可以在开机选项选择使用Systemd或Upstart，但是不可同時使用Sysvinit或Upstart并存。

https://wiki.ubuntu.com/SystemdForUpstartUsers

整个Linux的init发展历史：

https://zh.wikipedia.org/wiki/Init

详细介绍三个体系：Sysvinit、Upstart、Systemd

Sysvinit：https://www.ibm.com/developerworks/cn/linux/1407_liuming_init1/index.html

Upstart：https://www.ibm.com/developerworks/cn/linux/1407_liuming_init2/index.html

Systemd：https://www.ibm.com/developerworks/cn/linux/1407_liuming_init3/index.html

总结Sysvinit：

对于其它两项在Ubuntu上已经有介绍其使用方法，主要是Sysvinit比较历史悠久，其主要就是一个Shell脚本，并且是放置在/etc/init.d文件夹下。然后通过update-rc.d命令进行运行级别的操作来达到服务的启动。下面是一些服务脚本的编写参考：

其实系统提供的说明文档，在/etc/init.d/README

https://gist.github.com/naholyr/4275302

https://www.cyberciti.biz/tips/linux-write-sys-v-init-script-to-start-stop-service.html

来自：stackexchange的回答

chaos' answer is what some documentation says. But it's not what systemd actually does. (It's not what van Smoorenburg rc did, either. The van Smoorenburg rc most definitely did not ignore LSB headers, which insserv used to calculate static orderings, for starters.) The Freedesktop documentation, such as that "Incompatibilities" page, is in fact wrong, on these and other points. (The HOME environment variable in fact is often set, for example. This went wholly undocumented anywhere for a long time. It's now documented in the manual, at least, but that Freedesktop WWW page still hasn't been corrected.)

The native service format for systemd is the service unit. systemd's service management proper operates solely in terms of those, which it reads from one of nine directories where (system-wide) .service files can live. /etc/systemd/system, /run/systemd/system, /usr/local/lib/systemd/system, and /usr/lib/systemd/system are four of those directories.

The compatibility with van Smoorenburg rc scripts is achieved with a conversion program, named systemd-sysv-generator. This program is listed in the /usr/lib/systemd/system-generators/directory and is thus run automatically by systemd early in the bootstrap process at every boot, and again every time that systemd is instructed to re-load its configuration later on.

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 van Smoorenburg 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.

systemd service management only knows about service units. These automatically (re-)generated service units are written to invoke the van Smoorenburg rc scripts. They have, amongst other things:

[Unit]
SourcePath=/etc/init.d/wibble
[Service]
ExecStart=/etc/init.d/wibble start
ExecStop=/etc/init.d/wibble stop

Received wisdom is that the van Smoorenburg 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?.dsymbolic 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.