我只是改用了debian jessie，大多数事情都可以正常运行，包括我的图形显示管理器wdm。

问题是，我只是不了解它是如何工作的。显然，我的/etc/init.d/wdm脚本被调用了，因为当我在其中放置早期的exit时，wdm无法启动。但是，当我重命名/etc/rc3.d目录（我的默认运行级别以前是3）时，wdm仍然会启动。

我无法找到systemd如何找到此脚本，并且我不明白它的作用


从长远来看，我应该摆脱所有init.d吗？
从长远来看，我应该摆脱所有init.d吗？脚本？


#1 楼

混乱的答案就是一些文档所说的。但这不是systemd实际执行的操作。 （也不是van Smoorenburg rc所做的。vanSmoorenburg rc绝对不会忽略LSB标头，对于初学者来说，insserv用来计算静态顺序。）Freedesktop文档，例如“不兼容”页面，实际上是在这些和其他观点上的错误。 （例如，实际上经常设置HOME环境变量。很长一段时间以来，它在任何地方都没有记录。至少现在在手册中有记录，但是Freedesktop WWW页面仍未得到纠正。） >
systemd的本机服务格式是服务单元。 systemd的服务管理适当地仅根据那些内容进行操作，它从9个目录中的一个（系统范围内的.service文件可以存在）读取该目录。 /etc/systemd/system，/run/systemd/system，/usr/local/lib/systemd/system和/usr/lib/systemd/system是这些目录中的四个。

与van Smoorenburg rc脚本的兼容性是通过一个名为systemd-sysv-generator的转换程序实现的。该程序在/usr/lib/systemd/system-generators/目录中列出，因此在每次引导时由systemd在引导过程的早期自动运行，并在以后每次指示systemd重新加载其配置时再次运行。

此程序是生成器，是一种辅助实用程序，其作用是在tmpfs中动态创建服务单元文件，在这9个目录（仅由生成器使用）中还存在三个目录。如果systemd-sysv-generator找不到在其他六个位置已经存在的本机systemd服务单元，则从rc生成运行van Smoorenburg /etc/init.d脚本的服务单元。

系统服务管理仅了解服务单元。编写这些自动（重新）生成的服务单元以调用van Smoorenburg rc脚本。它们具有以下优点：众所周知，van Smoorenburg rc脚本必须具有LSB头，并且在不遵循/etc/rc?.d/系统施加的优先级的情况下并行运行。这在所有点上都是不正确的。

实际上，它们不需要LSB头，如果没有，则systemd-sysv-generator可以识别出更为有限的旧RedHat注释头（description:，pidfile:和等等）。而且，在没有LSB头的情况下，它将退回到/etc/rc?.d符号链接服务器场的内容，读取编码为链接名称的优先级，并从它们中构造一个前后顺序，从而对服务进行序列化。 LSB头不仅是必需的，而且它们本身不仅在将事情序列化到一定程度的顺序之前/之后进行编码，而且在完全不存在的情况下，回退行为实际上是非常不并行的操作。

/etc/rc3.d似乎无关紧要的原因是，您可能已通过另一个/etc/rc?.d/目录启用了该脚本。 systemd-sysv-generator将列在/etc/rc2.d/，/etc/rc3.d/和/etc/rc4.d/中的任何一个转换为与systemd的Wanted-By的本机multi-user.target关系。运行级别在systemd世界中已“过时”，您可以将它们忘掉。

进一步阅读




systemd-sysv-generator。系统手册页。 Freedesktop.org。

“产生的进程中的环境变量”。 systemd.exec。系统手册页。 Freedesktop.org。
https://unix.stackexchange.com/a/394191/5132
https://unix.stackexchange.com/a/204075/5132
https：// unix.stackexchange.com/a/196014/5132
https://unix.stackexchange.com/a/332797/5132


评论

在Debian中，system-generators目录不在/ usr / lib上，而是/libpackages.debian.org/sid/amd64/systemd/filelist

–脑袋
16年5月25日在13:55
这是一个惊人的答案。干得好先生。

– Peelman
17年1月13日在12:13
谢谢，谢谢，谢谢你！处理Debian 8和RH / CentOS 7的混合系统使SysVInit vs Systemd服务依赖关系管理的管理有些令人头疼，但是对systemd正在做什么的这种解释极大地帮助了我的理解。

–托比
17 Mar 29 '17 at 17:22
该生成器确实起作用。对于追随者，我还要提到的是，如果您使用的是较旧的systemd版本，并且未将/etc/init.d脚本设置为“启动时启动”，则该脚本仍会按预期运行，但不会在显示单位列表：unix.stackexchange.com/a/518894/8337

–rogerdpack
19年5月14日在15:15
该生成器确实起作用。对于追随者，我还要提到的是，如果您有一个较旧的systemd版本，并且/etc/init.d脚本未设置为“启动时启动”，它仍然可以使用systemctl按预期方式启动/停止，但是不会显示在show-units列表中：unix.stackexchange.com/questions/517872/…另外请注意，您基本上不再能通过直接运行/etc/init.d/xx来直接控制这些服务，或者systemd ...对于正在运行的内容和未运行的内容感到困惑：|

–rogerdpack
19年5月23日在16:40

#2 楼

Systemd与SysV初始化脚本向后兼容。根据LSB 3.1，初始化脚本必须具有信息注释约定，定义注释脚本何时必须启动/停止以及脚本启动/停止所需的条件。这是一个示例：

### BEGIN INIT INFO
# Provides: my-service
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start:  2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop service my-service
# Description: my-service blah blah ...
### END INIT INFO


这是SysV忽略的注释部分。另一方面，systemd读取该依赖项信息并根据该信息运行这些脚本。

但有一点，systemd和SysV在初始化脚本方面有所不同。 SysV基于文件名中的脚本顺序执行脚本。 Systemd没有。如果满足依赖关系，systemd将立即运行脚本，而无需遵守脚本名称的编号。其中一些很可能会因为订购而失败。还有许多其他不兼容问题应予以考虑。


如果同一服务具有初始化脚本和.service文件，则在满足依赖关系后，systemd会同时执行这两项（对于init脚本，是在LSB头中定义的脚本。）

评论

好的，但是我在/ lib / systemd / system /中也有一堆.service文件。 systemd实际执行什么操作？服务文件中（以依存顺序），init.d脚本或两者都指定了什么？

–马丁·德劳茨堡
2015年10月2日，13：46
@MartinDrautzburg我将其添加到答案中

–混乱
2015年10月2日，13：58
附带说明，Debian刚刚宣布放弃LSB兼容性：article.gmane.org/gmane.linux.debian.devel.lsb/1103

– Jan
2015年10月2日，14：22
systemd是与SysV脚本兼容的任何东西。该语句不仅不正确，而且引用的链接清楚地表明它仅是“大部分兼容的”，并且产生相同结果所需的工作量非常大。

–朱莉在奥斯丁
19年2月12日在19:08
我发现很难的方法是，如果/etc/init.d中的文件是符号链接，则扫描旧有init.d脚本的systemd生成器“ systemd-sysv-generator”将跳过它。我在init.d中的gerrit文件是/home/gerrit2/gerrit/bin/gerrit.sh的符号链接，我用以下命令修复了它：cd /etc/init.d; sudo unlink gerrit;须藤cp /home/gerrit2/gerrit/bin/gerrit.sh gerrit

–集成商
20年4月13日在5:58