Val*_*ami 97 linux systemd init upstart sysvinit
是否有一种简单的方法可以找出正在使用的 initsystem，例如最近的系统Debian wheezy或Fedora系统正在使用哪个 initsystem ？我知道Fedora 21使用systemdinitsystem 但那是因为我读过它并且因为所有相关的脚本/符号链接都存储在/etc/systemd/. 但是，我不确定例如Debian squeeze或CentOS 6 or 7等等。
有哪些技术可以验证这种初始化系统？
Nat*_*man 178
init 进程总是被分配 PID 1。/proc文件系统提供了一种方法来获取给定 PID 的可执行文件的路径。
换句话说：
nathan@nathan-desktop:~$ sudo stat /proc/1/exe
File: '/proc/1/exe' -> '/sbin/upstart'
如您所见，我的 Ubuntu 14.10 机器上的 init 进程是 Upstart。Ubuntu 15.04 使用 systemd，因此运行该命令会产生：
nathan@nathan-gnome:~$ sudo stat /proc/1/exe
File: '/proc/1/exe' -> '/lib/systemd/systemd'
如果您所在的系统给出/sbin/init了结果，那么您将要尝试统计该文件：
nathan@nathan-gnome:~$ sudo stat /proc/1/exe
File: '/proc/1/exe' -> '/sbin/init'
nathan@nathan-gnome:~$ stat /sbin/init
File: ‘/sbin/init’ -> ‘/lib/systemd/systemd’
您还可以执行它以了解更多信息：
[user@centos ~]$ /sbin/init --version
init (upstart 0.6.5)
Copyright (C) 2010 Canonical Ltd.
War*_*ung 65
您可以浏览系统以查找指标。一种方法是检查三个目录是否存在：
/usr/lib/systemd 告诉你你在一个基于 systemd 的系统上。
/usr/share/upstart 是一个很好的指标，表明您使用的是基于 Upstart 的系统。
/etc/init.d 告诉您该框的历史记录中有 SysV init
问题是，这些启发式方法必须一起考虑，可能与其他数据一起考虑，而不是单独考虑某些指标。我现在正在查看的 Ubuntu 14.10 框包含所有三个目录。为什么？因为 Ubuntu 在那个版本中刚刚从 Upstart 切换到 systemd，但为了向后兼容而保留了 Upstart 和 SysV init。
最后，我认为最好的答案是“体验”。您将看到您已登录 CentOS 7 框并知道它是 systemd。你怎么学这个？玩转，RTFMing 等。与您获得所有经验的方式相同。
我意识到这不是一个非常令人满意的答案，但这就是当市场存在碎片化、创建非标准设计时会发生的情况。这就像问你如何知道是ls接受-C、还是--color、或根本不进行颜色输出。同样，答案是“经验”。
Jde*_*eBP 29
这实际上是一个相当困难的问题。主要困难之一是，人们最常想要这样做的地方是人们很可能正在安装或更改东西的地方。另一个原因是，有之间的微妙但很重要的区别已安装的系统管理工具集，即现在正在运行的系统管理工具集，以及系统管理工具集，将在下次启动时运行。
当然，确定安装的内容与包管理器有关。但由于多个系统可以并排安装，这很复杂。
例如，在 Debian Linux 上，您可以安装systemd软件包，但安装单独的systemd-sysv软件包才能使其成为活动系统。目的是可以同时安装systemd 和sysvinit软件包。事实上，Debian Linux 人群已经在 Debian 8 中采取措施转向每个具有不同名称（/lib/sysvinit/init、/lib/systemd/systemd、/sbin/runit-init、/sbin/minit、/sbin/system-manager、 等等）的程序，正是出于这个原因，“非激活”软件包不会在名字/sbin/init。 /sbin/init然后是一个符号链接，指向被“激活包”配置为在下次启动时运行的任何一个。
确定现在正在运行的内容和准备运行的内容只能通过一系列特定于工具集的测试来完成，具有不同程度的误报风险和不同程度的文档。要检查当前正在运行的系统管理器，具体来说，确实需要查看进程列表或系统管理器发布的各种 API。但这并非完全没有陷阱。
让我们开始的事情，绝对不会不工作。
/proc/1/exe/sbin/init当 upstart 或 System 5init现在正在运行时，将指向相同的内容。在某些系统上，它也是/sbin/init在 systemd 运行时。如前所述，Debian Linux 人群希望转向具有不同名称的每个程序。但这是特定于Debian 的，远非通用，并且当程序被调用为/sbin/init（通过引导程序的 initramfs 阶段）时并没有真正的帮助。实际上只有 Felix von Leitner 的 minit 被 Debian 8 打包，以自己的名字调用。
/dev/initctl并非特定于 System 5 init。systemd 有一个（非进程 #1）systemd-initctl服务器来提供服务。约阿希姆·尼尔森 (Joachim Nilsson) 也finit供应它。（只是为了让事情变得更有趣，在 Debian 上，它现在位于/run/initctl。有关详细信息，请参阅https://superuser.com/a/888936/38062。）rc和 OpenRC 都经过处理/etc/init.d/，以便在前两者的情况下向后兼容。它的存在并不表示任何给定系统的存在。init具有讽刺意味的是，如https://unix.stackexchange.com/a/196197/5132 所述，Debian Linux 上至少用于检测系统 5 缺失的一种方法init是/etc/inittab. 然而：
/etc/inittab./etc/inittab支左右，如果系统5init使用在过去的任何一点，因为卸载程序包不删除其配置文件。（这对于 Debian 8 工作来说是一个相当大的问题，因为 Debian 7 中有几个软件包通过向/etc/inittab.要以“官方”方式检查 systemd 作为正在运行的系统管理器，需要检查/run/systemd/system. 这是/runsystemd 自己在启动时创建的目录 in ，其他系统管理器不太可能创建。
但这只是不太可能。这个检查已经被破坏了，因为 uselessd 也创建了这个目录。
其他非官方的检查将不起作用：
/run/systemd/private同样不被uselessd保证和同样复制。将system-manager在NOSH创建一个/run/system-manager目录。但这共享了等效的 systemd 检查的弱点。
其他非首发：
system-manager设计上的 nosh不会在文件系统中创建管道或套接字，并且首先没有 RPC API。service-manager通常在 处有一个 API 套接字/run/service-manager/control，但可以在其他系统管理器下运行 nosh服务管理器；所以这并没有告诉人们哪个系统管理器作为进程#1 运行。在任何情况下，它都不会自行设置该名称；无论调用它做什么。system-control version, systemctl version（如果安装了 systemd 兼容性垫片）和initctl version（如果安装了新贵兼容性垫片）发出的 nosh 版本字符串的存在仅表明工具集的存在，因为这些工具不会查询正在运行的系统.Upstart 自己initctl通过 D-Bus 进行 API 调用，官方检查是检查一个人可以运行initctl，并且它的输出在某处包含字符串“upstart”。
但是，就像 systemd API：
事实上，已经有一个兼容性垫片。NOSH具有暴发户兼容性包，提供了垫片的暴发户initctl，start，stop，和status命令。幸运的是（虽然这是故意的），initctl垫片没有发出“暴发户”这个词。
root ~ #initctl 版本 1.14 版 根~#
mat*_*tdm 26
在基于 RPM 的系统上，您可以查询 RPM 数据库以查看哪些包提供了/sbin/init. 例如：
fedora:~$ rpm -qf /sbin/init
systemd-216-24.fc21.x86_64
centos:~$ rpm -qf /sbin/init
upstart-0.6.5-12.el6_4.1.x86_64
opensuse:~$ rpm -qf /sbin/init
systemd-sysvinit-44-10.1.1.i586
如果您只想要包名称，而不是版本，您可以将--qf选项添加到 RPM（“queryformat”，不要与带有一个连字符的另一个 混淆-qf，这意味着“查询：文件”），如下所示：rpm --qf '%{name}\n' -qf /sbin/init。
在基于 Debian 的系统上，您可以执行类似的操作dpkg：
ubuntu:~$ dpkg -S /sbin/init
upstart: /sbin/init
而且，大多数包管理器都会有类似的命令。当然，那么您需要知道您的发行版使用的是什么包管理器，这可能只是将一个问题换为另一个问题。
此外，在某些发行版上，这可能/sbin/init不是要查看的正确文件，很可能init=/something/else是因为在内核命令行中给出。另一种可能性是，它/sbin/init是由某个助手包拥有的符号链接，其任务是在 init 系统之间进行切换，而不是由它们中的任何一个直接拥有。Arch 上可能存在其中一种或两种情况（尽管我现在手边没有 Arch 框可以检查）。