如何确定系统是使用SysV，Upstart还是Systemd initsystem [重复]

#1 楼

您可以在系统中四处查找指示器。一种方法是检查三个目录是否存在：


/usr/lib/systemd告诉您您使用的是基于systemd的系统。
/usr/share/upstart很好地表明您正在在基于Upstart的系统上。
/etc/init.d告诉您包装盒在其历史记录中具有SysV初始化

问题是，这些启发式必须与其他数据一起考虑，不确定指标本身。我现在正在查看的Ubuntu 14.10盒具有所有三个目录。为什么？因为Ubuntu刚从该版本的Upstart切换到systemd，但是保持了Upstart和SysV的初始性以实现向后兼容性。您会看到您已经登录到CentOS 7盒子，并且知道它是systemd。您如何学习？玩转，RTFMing等。以同样的方式获得所有经验。

我意识到这不是一个令人满意的答案，但这就是在市场分散，创建非标准设计时发生的情况。这就像问您如何知道ls是否接受-C或--color或根本不进行颜色输出一样。同样，答案是“经验”。

#2 楼

始终为init进程分配PID1。/proc文件系统提供了一种获取给定PID的可执行文件的路径的方法。换句话说：
>
如您所见，我的Ubuntu 14.10机器上的初始化过程是Upstart。 Ubuntu 15.04使用systemd，因此运行该命令将产生以下结果：该文件：

nathan@nathan-desktop:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/sbin/upstart'

您还可以执行该文件以了解更多信息：

nathan@nathan-gnome:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/lib/systemd/systemd'

#3 楼

这实际上是一个相当困难的问题。主要困难之一是，人们最想这样做的地方很可能是人们正在安装或更换东西的地方。另一个问题是，已安装的系统管理工具集，当前正在运行的系统管理工具集与将在下次启动时运行的系统管理工具集之间存在细微但非常重要的区别。

确定当然，安装的是软件包管理器。但是，由于可以并排安装多个系统这一事实使情况变得复杂。

例如，在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。但这并不是完全没有陷阱。

普通的入门者

让我们从绝对无法解决的事情开始。 >
当新贵或系统5 /proc/1/exe正在运行时，/sbin/init将指向相同的init。在某些系统上，systemd运行时也为/sbin/init。如前所述，Debian Linux人群希望转向每个具有不同名称的程序。但这是Debian特定的，远非通用的，并且无论如何以/sbin/init（由引导程序的initramfs阶段）调用程序时，并没有真正的帮助。实际上，只有Felix von Leitner的minit由Debian 8打包后才能用其自己的名称调用。

控件API文件/dev/initctl的存在并不特定于System 5 init。 systemd具有一个（非进程＃1）systemd-initctl服务器来为此提供服务。 Joachim Nilsson的finit也可以使用。 （只是为了使事情变得更加有趣，在Debian上，它现在位于/run/initctl。有关详细信息，请参见https://superuser.com/a/888936/38062。） rc，对于前两个情况是为了向后兼容。它的存在并不表示存在任何给定的系统。

检测系统5 /etc/init.d/



具有讽刺意味的是，如https://unix.stackexchange.com上所述。 / a / 196197/5132，在Debian Linux上至少用于检测系统5 init缺失的一种方法是init的缺失。但是：


这是Debian打包/etc/inittab之类的东西的副作用。
总体问题的一部分是，如果使用System 5 /etc/inittab，则/etc/inittab会卡住在过去的任何时候，因为卸载软件包不会删除其配置文件。 （这对于Debian 8来说是一个很大的问题，因为Debian 7中有几个软件包是通过将条目添加到init来安装自身的。）
这是一个反向测试。 br />
为了以“官方”方式将systemd作为正在运行的系统管理器进行检查，请检查/etc/inittab的存在。这是一个目录，位于/run/systemd/system中，systemd本身在引导时创建，而其他系统管理员则不太可能创建。

但这不太可能。此检查已被破坏，因为uselessed也会创建此目录。

其他非官方的检查将不起作用：


systemd通过以下方式发布了整个RPC API： D-Bus，甚至包含版本名称和编号；但是：


臭名昭著的“接口稳定性保证”未涵盖此问题，明天或一时可能会改变。 shim。
uselessed也是如此。


/run的存在同样无法得到保证，并且也被uselessed重复。

检测nosh

nosh中的/run/systemd/private创建一个system-manager目录。但这也具有等效的systemd检查的缺点。文件系统，并且首先没有RPC API。
nosh /run/system-manager通常在system-manager处具有一个API套接字，但是可以在其他系统管理器下运行nosh服务管理器；因此，这不能告诉一个进程＃1正在运行哪个系统管理器。无论如何，它不会自行设置名称。无论调用了什么。
service-manager，/run/service-manager/control（如果已安装systemd兼容垫片）和system-control version（如果已安装新贵兼容垫片）发出的nosh版本字符串的存在仅表明该工具集的存在，因为这些工具不查询正在运行的系统。

检测新贵

Upstart自己的systemctl version通过D-Bus进行API调用，并且官方检查是要检查一个人是否可以运行initctl version，并且其输出在某处包含字符串“ upstart”。

但是，就像systemd API一样：


不能保证API会在明天出现或一时兴起。
不能保证某些兼容垫片不存在或将来将不存在。的确，已经有一个兼容垫片。 nosh有一个新贵兼容包，为新贵initctl，initctl，initctl和start命令提供垫片。幸运的是（尽管这是故意的），stop填充程序不会发出“ upstart”一词。

root ~ #initctl version
nosh version 1.14
root ~ #

#4 楼

在基于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。 />

ubuntu:~$ dpkg -S /sbin/init
upstart: /sbin/init

而且，大多数程序包管理器将具有类似的命令。当然，那您需要知道您的发行版使用的软件包管理器，这可能只是将一个问题换成另一个。

此外，在某些发行版中，dpkg可能不是正确的文件at，最有可能是因为在内核命令行上给出了/sbin/init。另一种可能是，init=/something/else是一个符号链接，该符号链接由负责在init系统之间切换的某些帮助程序包拥有，而不是直接由其中任何一个系统拥有。在Arch上可能是其中一种或两种情况（尽管我现在没有方便检查的Arch框）。

#5 楼

您也可以从程序中使用已定义的API。 Systemd随附libsystemd，可以检查它是否可以成功连接到正在运行的systemd实例。