web-dev-qa-db-fra.com

Comment savoir si un système utilise SysV, Upstart ou Systemd initsystem

Existe-t-il un moyen simple de savoir quel système est utilisé, par exemple par un système récent Debian wheezy Ou Fedora? Je sais que Fedora 21 Utilise systemd initsystem mais c'est parce que je l'ai lu et parce que tous les scripts/liens symboliques pertinents sont stockés dans /etc/systemd/. Cependant, je ne sais pas par exemple Debian squeeze Ou CentOS 6 or 7 Et ainsi de suite.

Quelles techniques existent pour vérifier un tel système?

linuxsystemdinitupstartsysvinit
94
Valentin Bajrami

Vous pouvez fouiller dans le système pour trouver des indicateurs. Une façon consiste à vérifier l'existence de trois répertoires:

  • /usr/lib/systemd vous indique que vous utilisez un système basé sur systemd.

  • /usr/share/upstart est un assez bon indicateur que vous êtes sur un système basé sur Upstart.

  • /etc/init.d vous indique que la boîte a SysV init dans son histoire

Le fait est que ce sont des heuristiques qui doivent être considérées ensemble, éventuellement avec d'autres données, et non certains indicateurs en eux-mêmes. La boîte Ubuntu 14.10 que je regarde en ce moment contient les trois répertoires. Pourquoi? Parce que Ubuntu vient de passer à systemd d'Upstart dans cette version, mais conserve Upstart et SysV init pour une compatibilité descendante.

En fin de compte, je pense que la meilleure réponse est "expérience". Vous verrez que vous vous êtes connecté à une boîte CentOS 7 et que vous savez que c'est systemd. Comment apprenez-vous cela? Jouer, RTFMing, etc. De la même manière que vous gagnez en expérience.

Je me rends compte que ce n'est pas une réponse très satisfaisante, mais c'est ce qui se produit lorsqu'il y a une fragmentation sur le marché, créant des conceptions non standard. C'est comme demander comment vous savez si ls accepte -C, ou --color, ou ne fait pas du tout de sortie couleur. Encore une fois, la réponse est "expérience".

63
Warren Young

Le processus init reçoit toujours le PID 1. Le /proc le système de fichiers fournit un moyen d'obtenir le chemin vers un exécutable avec un PID.

En d'autres termes:

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

Comme vous pouvez le voir, le processus d'initialisation sur ma boîte Ubuntu 14.10 est Upstart. Ubuntu 15.04 utilise systemd, donc exécuter cette commande à la place donne:

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

Si le système sur lequel vous vous trouvez donne /sbin/init en conséquence, alors vous voudrez essayer de mettre en forme ce fichier:

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’

Vous pouvez également l'exécuter pour en savoir plus:

[user@centos ~]$ /sbin/init --version
init (upstart 0.6.5)
Copyright (C) 2010 Canonical Ltd.
165
Nathan Osman

C'est en fait un problème assez difficile. L'une des principales difficultés est que les endroits où l'on veut le plus souvent le faire sont les endroits où il est fort probable que l'on soit en train d'installer ou de changer des choses. Un autre est qu'il existe une différence subtile mais très importante entre l'ensemble d'outils de gestion système installé , l'ensemble d'outils de gestion système qui s'exécute en ce moment et l'ensemble d'outils de gestion du système qui s'exécutera au prochain démarrage .

Bien sûr, déterminer ce qui est installé se fait avec un gestionnaire de paquets. Mais cela est compliqué par le fait que plusieurs systèmes peuvent être installés côte à côte.

Sur Debian Linux, par exemple, on peut installer le paquet systemd , mais c'est l'installation du paquet systemd-sysv séparé qui en fait le système actif. L'intention est que les packages systemd et sysvinit puissent être installés simultanément. En effet, la foule Debian Linux a pris des mesures dans Debian 8 pour passer à chaque programme ayant un nom différent (/lib/sysvinit/init, /lib/systemd/systemd, /sbin/runit-init, /sbin/minit, /sbin/system-manager, etc.) pour cette même raison, que les packages "non activants" n'entrent pas en conflit avec le nom /sbin/init. /sbin/init est alors un lien symbolique vers celui qui a été configuré pour s'exécuter au prochain démarrage par un "package d'activation".

Déterminer ce qui est en cours d'exécution et prêt à être exécuté ne peut se faire qu'avec une série de tests spécifiques à l'ensemble d'outils, avec différents degrés de risque de faux positifs et divers degrés de documentation. Pour vérifier quel gestionnaire système fonctionne actuellement, en particulier, il faut vraiment regarder la liste des processus ou les différentes API que les gestionnaires système publient. Mais ce n'est pas sans écueils.

Non-partants généraux

Commençons par des choses qui ne fonctionneront certainement pas .

  • /proc/1/exe pointera vers le même /sbin/init lorsque upstart ou System 5 init sont en cours d'exécution. Et sur certains systèmes, c'est aussi /sbin/init lorsque systemd est en cours d'exécution.

    La foule Debian Linux voulait se tourner vers chaque programme ayant un nom différent, comme mentionné précédemment. Mais ceci est spécifique à Debian, loin d'universel, et n'aide pas vraiment quand le programme est appelé comme /sbin/init (par la phase initramfs du bootstrap) de toute façon. Seul le minit de Felix von Leitner est réellement empaqueté par Debian 8 pour être invoqué avec son propre nom.

  • L'existence du fichier API de contrôle /dev/initctl n'est pas spécifique au système 5 init. systemd a un (non processus # 1) systemd-initctl serveur qui sert cela. finit de Joachim Nilsson le sert aussi. (Juste pour rendre les choses encore plus amusantes, sur Debian, il est maintenant situé à /run/initctl. Voir https://superuser.com/a/888936/38062 pour plus de détails.)
  • systemd, upstart, System 5 rc et OpenRC tous les processus /etc/init.d/, pour une compatibilité descendante dans le cas des deux premiers. Son existence n'indique pas la présence d'un système donné.

Système de détection 5 init

Ironiquement, comme expliqué sur https://unix.stackexchange.com/a/196197/5132 , dans un sens sur Debian Linux au moins pour détecter l'absence du système 5 init est l'absence de /etc/inittab. Toutefois:

  • Ceci est un effet secondaire de la manière de Debian d'empaqueter des choses comme /etc/inittab.
  • Une partie du problème global est que /etc/inittab reste si System 5 init a été utilisé à tout moment dans le passé , car la désinstallation du package ne supprime pas son fichier de configuration . (Cela a été un problème important pour le travail Debian 8, car il y a plusieurs paquets dans Debian 7 qui s'installent eux-mêmes en ajoutant des entrées à /etc/inittab.)
  • C'est un test inversé.

Détection de systemd

Pour vérifier systemd en tant que gestionnaire de système en cours d'exécution de la manière "officielle", on vérifie l'existence de /run/systemd/system. Il s'agit d'un répertoire, dans /run, que systemd crée lui-même au démarrage et qu'il est peu probable que d'autres gestionnaires de système créent.

Mais c'est simplement peu probable . Cette vérification est déjà rompue , car selessd crée également ce répertoire.

D'autres chèques non officiels ne fonctionneront pas:

  • systemd publie une API RPC complète sur D-Bus, qui contient même un nom et un numéro de version; mais:
  • L'existence de /run/systemd/private n'est pas non plus garanti et dupliqué de la même manière par uselessd.

Détection de nosh

Le system-manager in nosh crée un /run/system-manager répertoire. Mais cela partage les faiblesses du contrôle systemd équivalent.

Autres non-partants:

  • Le nosh system-manager par sa conception ne crée pas de canaux ou de sockets dans le système de fichiers, et ne dispose pas d'une API RPC en premier lieu.
  • Le nosh service-manager a classiquement un socket API à /run/service-manager/control, mais on peut exécuter le gestionnaire de service nosh sous un autre gestionnaire de système; donc cela ne dit pas ce que le gestionnaire système exécute en tant que processus # 1. Dans tous les cas, il ne définit pas ce nom lui-même; quoi que ce soit invoqué.
  • L'existence d'une chaîne de version nosh, émise par system-control version, systemctl version (si l'on a installé des shims de compatibilité systemd) et initctl version (si l'on a installé les shims de compatibilité upstart) indique uniquement la présence du jeu d'outils, car ces outils ne font aucune requête sur le système en cours d'exécution.

Détection des arrivées

Le propre initctl d'Upstart effectue un appel d'API via D-Bus, et la vérification officielle consiste à vérifier que l'on peut exécuter initctl et que sa sortie contient la chaîne "upstart" quelque part.

Mais, comme l'API systemd:

  • Il n'y a aucune garantie que l'API sera disponible demain ou ne sera pas modifiée à volonté.
  • Il n'y a aucune garantie que certaines cales de compatibilité n'existent pas ou n'existeront pas à l'avenir.

    En effet, il existe déjà un module de compatibilité. nosh a un package de compatibilité upstart qui fournit des shims pour les commandes upstart initctl, start, stop et status. Heureusement (bien que ce soit intentionnel), la cale initctl n'émet pas le mot "parvenu".

    root ~ #initctl version 
 nosh version 1.14 
 root ~ #
28
JdeBP

Sur les systèmes basés sur RPM, vous pouvez interroger la base de données RPM pour voir quel package fournit /sbin/init. Par exemple:

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

Si vous voulez juste le nom du package et non la version, vous pouvez ajouter le --qf option pour RPM ("queryformat", à ne pas confondre avec autre-qf avec un tiret, ce qui signifie "requête: fichier"), comme ceci: rpm --qf '%{name}\n' -qf /sbin/init.

Sur les systèmes basés sur Debian, vous pouvez faire la même chose avec dpkg:

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

Et, la plupart des gestionnaires de packages auront une commande similaire. Bien sûr, vous devez alors savoir quel gestionnaire de paquets votre distribution utilise, ce qui pourrait simplement échanger un problème contre un autre.

De plus, sur certaines distributions, il est possible que /sbin/init n'est pas le bon fichier à regarder, probablement parce que init=/something/else est donné sur la ligne de commande du noyau. Une autre possibilité serait que /sbin/init est un lien symbolique appartenant à un paquet d'assistance chargé de basculer entre les systèmes init et n'appartenant à aucun d'entre eux directement. L'un ou les deux peuvent être le cas sur Arch (bien que je n'ai pas de boîte Arch à portée de main pour vérifier en ce moment).

24
mattdm

À partir d'un programme, vous pouvez également utiliser les API définies pour cela. Systemd est livré avec libsystemd, qui peut vérifier s'il peut se connecter avec succès à l'instance systemd en cours d'exécution.

0
Simon Richter