So finden Sie heraus, ob ein System SysV, Upstart oder Systemd initsystem verwendet

Dem Init-Prozess wird immer die PID 1 zugewiesen. Der /proc Dateisystem bietet eine Möglichkeit, den Pfad zu einer ausführbaren Datei mit einer PID zu erhalten.

Mit anderen Worten:

[email protected]:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/sbin/upstart'

Wie Sie sehen können, ist der Init-Prozess auf meiner Ubuntu 14.10-Box Upstart. Ubuntu 15.04 verwendet systemd, daher ergibt die Ausführung dieses Befehls stattdessen:

[email protected]:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/lib/systemd/systemd'

Wenn das System, auf dem Sie sich befinden, /sbin/init gibt Als Ergebnis sollten Sie versuchen, diese Datei zu erstellen:

[email protected]:~$ sudo stat /proc/1/exe
  File: '/proc/1/exe' -> '/sbin/init'
[email protected]:~$ stat /sbin/init
  File: ‘/sbin/init’ -> ‘/lib/systemd/systemd’

Sie können es auch ausführen, um mehr zu erfahren:

[[email protected] ~]$ /sbin/init --version
init (upstart 0.6.5)
Copyright (C) 2010 Canonical Ltd.

Sie können im System herumstöbern, um Indikatoren zu finden. Eine Möglichkeit besteht darin, zu prüfen, ob drei Verzeichnisse vorhanden sind:

• /usr/lib/systemd sagt Ihnen, dass Sie sich auf einem systemd-basierten System befinden.

• /usr/share/upstart ist ein ziemlich guter Indikator dafür, dass Sie sich auf einem Upstart-basierten System befinden.

• /etc/init.d sagt Ihnen, dass die Box SysV-Init in ihrer Historie hat

Die Sache ist, dass dies Heuristiken sind, die zusammen betrachtet werden müssen, möglicherweise mit anderen Daten, nicht bestimmten Indikatoren für sich. Die Ubuntu 14.10-Box, die ich mir gerade ansehe, hat alle drei Verzeichnisse. Wieso den? Weil Ubuntu gerade in dieser Version von Upstart auf systemd umgestiegen ist, aber Upstart und SysV init für Abwärtskompatibilität behält.

Am Ende denke ich, dass die beste Antwort "Erfahrung" ist. Sie werden sehen, dass Sie sich bei einer CentOS 7-Box angemeldet haben und wissen, dass es systemd ist. Wie lernt man das? Herumspielen, RTFMing usw. Auf die gleiche Weise sammeln Sie alle Erfahrungen.

Mir ist klar, dass dies keine sehr zufriedenstellende Antwort ist, aber das passiert, wenn der Markt fragmentiert ist und nicht standardmäßige Designs entstehen. Es ist wie die Frage, woher Sie wissen, ob ls akzeptiert -C , oder --color , oder gibt überhaupt keine Farbausgabe aus. Auch hier lautet die Antwort "Erfahrung".

Das ist eigentlich ein ziemlich schwieriges Problem. Eine der größten Schwierigkeiten besteht darin, dass die Orte, an denen man dies am häufigsten tun möchte, die Orte sind, an denen man sehr wahrscheinlich gerade dabei ist, Dinge zu installieren oder zu ändern. Ein weiterer Grund ist, dass es einen kleinen, aber sehr wichtigen Unterschied zwischen dem installierten Systemverwaltungs-Toolset gibt , das derzeit ausgeführte Systemverwaltungs-Toolset , und das Systemverwaltungs-Toolset, das beim nächsten Start ausgeführt wird .

Feststellen, was installiert ist, macht man natürlich mit einem Paketmanager. Dies wird jedoch dadurch erschwert, dass mehrere Systeme nebeneinander installiert werden können.

Unter Debian Linux kann man beispielsweise das systemd-Paket installieren, aber erst die Installation des separaten systemd-sysv-Pakets macht es zum aktiven System. Die Absicht ist, dass die Pakete systemd und sysvinit gleichzeitig installiert werden können. Tatsächlich hat die Debian-Linux-Crowd in Debian 8 Schritte unternommen, um zu jedem Programm mit einem anderen Namen überzugehen (/lib/sysvinit/init , /lib/systemd/systemd , /sbin/runit-init , /sbin/minit , /sbin/system-manager , und so weiter) aus genau diesem Grund, dass die "nicht-aktivierenden" Pakete keinen Konflikt mit dem Namen /sbin/init haben . /sbin/init ist dann ein symbolischer Link zu dem, was durch ein "Aktivierungspaket" so konfiguriert wurde, dass es beim nächsten Start ausgeführt wird.

Um festzustellen, was jetzt läuft und bereit ist, als nächstes ausgeführt zu werden, kann man nur mit einer Reihe von Toolset-spezifischen Tests mit unterschiedlichem Risiko von Fehlalarmen und mit unterschiedlichem Dokumentationsgrad tun. Um zu überprüfen, welcher Systemmanager gerade gerade läuft, muss man sich wirklich die Prozessliste oder die verschiedenen APIs ansehen, die Systemmanager veröffentlichen. Aber das ist nicht ganz ohne Fallstricke.

Allgemeine Nichtstarter

Beginnen wir mit Dingen, die definitiv nicht werden Arbeit.

• /proc/1/exe zeigt auf dasselbe /sbin/init wenn entweder Emporkömmling oder System 5 init laufen gerade. Und auf einigen Systemen ist es auch /sbin/init wenn systemd läuft.

  Die Debian-Linux-Crowd wollte, wie bereits erwähnt, dazu übergehen, dass jedes Programm einen anderen Namen hat. Aber das ist Debian-spezifisch, weit von universal und hilft nicht wirklich, wenn das Programm als /sbin/init aufgerufen wird (durch die initramfs-Phase des Bootstrap) sowieso. Nur Felix von Leitners Minit wird tatsächlich von Debian 8 gepackt, um mit seinem eigenen Namen aufgerufen zu werden.

• Die Existenz der Steuerungs-API-Datei /dev/initctl ist nicht spezifisch für System 5 init . systemd hat (nicht Prozess #1) systemd-initctl Server, der dies dient. finit von Joachim Nilsson dient auch dazu. (Nur damit es noch mehr Spaß macht, befindet es sich unter Debian jetzt unter /run/initctl . Einzelheiten finden Sie unter https://superuser.com/a/888936/38062.)
• systemd, Emporkömmling, System 5 rc , und OpenRC verarbeiten alle /etc/init.d/ , für die Abwärtskompatibilität im Fall der ersten beiden. Seine Existenz weist nicht auf das Vorhandensein eines bestimmten Systems hin.

Erkennungssystem 5 init

Ironischerweise, wie unter https://unix.stackexchange.com/a/196197/5132 erklärt, eine Möglichkeit zumindest unter Debian Linux zum Erkennen der Abwesenheit von System 5 init ist das Fehlen von /etc/inittab . Allerdings:

• Dies ist ein Nebeneffekt von Debians Art Dinge wie /etc/inittab zu verpacken .
• Ein Teil des Gesamtproblems ist, dass /etc/inittab bleibt bestehen, wenn System 5 init zu irgendeinem Zeitpunkt in der Vergangenheit verwendet wurde , da die Deinstallation des Pakets seine Konfigurationsdatei nicht löscht. (Dies war ein beträchtliches Problem für die Arbeit mit Debian 8, da es mehrere Pakete in Debian 7 gibt, die sich selbst installieren, indem sie Einträge zu /etc/inittab hinzufügen .)
• Es ist ein invertierter Test.

Systemd wird erkannt

Um auf "offizielle" Weise nach systemd als laufendem Systemmanager zu suchen, prüft man auf die Existenz von /run/systemd/system . Dies ist ein Verzeichnis in /run , die systemd beim Booten selbst erstellt und die andere Systemmanager wahrscheinlich nicht erstellen werden.

Aber das ist nur unwahrscheinlich . Diese Überprüfung ist bereits gebrochen , weil uselessd auch dieses Verzeichnis erstellt.

Andere, inoffizielle Überprüfungen funktionieren nicht:

• systemd veröffentlicht eine ganze RPC-API über D-Bus, die sogar einen Versionsnamen und eine Versionsnummer enthält; aber:
  • Dies wird nicht von der berüchtigten "Schnittstellenstabilitätsgarantie" abgedeckt und könnte sich morgen oder nach Belieben ändern.
  • So auch der Lookalike-D-Bus-Server in systemd-shim.
  • Das gilt auch für uselessd.
• Die Existenz von /run/systemd/private ist ebenfalls nicht garantiert und wird ebenfalls von uselessd dupliziert.

Nosh erkennen

Der system-manager in nosh erstellt einen /run/system-manager Verzeichnis. Dies teilt jedoch die Schwächen des entsprechenden systemd-Checks.

Weitere Nichtstarter:

• Der nosh system-manager erstellt keine Pipes oder Sockets im Dateisystem und hat von vornherein keine RPC-API.
• Der nosh service-manager hat üblicherweise einen API-Socket bei /run/service-manager/control , aber man kann den nosh Dienst ausführen Manager unter einem anderen Systemmanager; das sagt einem also nicht, welches System Manager läuft als Prozess Nr. 1. In jedem Fall setzt es diesen Namen nicht selbst; was auch immer aufgerufen wird, es tut.
• Die Existenz einer Nosh-Versionszeichenfolge, die von system-control version ausgegeben wird , systemctl version (wenn man die systemd-Kompatibilitäts-Shims installiert hat) und initctl version (wenn man die Upstart-Kompatibilitäts-Shims installiert hat) zeigt nur das Vorhandensein des Toolsets an, da diese Tools das laufende System nicht abfragen.

Neuling erkennen

Upstarts eigener initctl macht einen API-Aufruf über D-Bus, und die offizielle Prüfung besteht darin, beide zu prüfen, ob man initctl ausführen kann und dass seine Ausgabe irgendwo die Zeichenfolge "upstart" enthält.

Aber wie bei der systemd-API:

• Es gibt keine Garantie dafür, dass die API morgen verfügbar ist oder nicht nach Lust und Laune geändert wird.
• Es gibt keine Garantie dafür, dass ein Kompatibilitäts-Shim nicht existiert oder in Zukunft nicht existieren wird.

  Tatsächlich gibt es bereits einen Kompatibilitäts-Shim. nosh hat ein Upstart-Kompatibilitätspaket, das Shims für den Upstart initctl bereitstellt , start , stop und status Befehle. Glücklicherweise (obwohl dies beabsichtigt war) der initctl shim gibt das Wort "Upstart" nicht aus.

  root ~ #initctl version
  nosh version 1.14
  root ~ #