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

Le processus init est toujours affecté au PID 1. Le /proc Le système de fichiers fournit un moyen d'obtenir le chemin d'accès à un exécutable en fonction d'un PID.

En d'autres termes :

[email protected]:~$ 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 :

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

Si le système sur lequel vous êtes donne /sbin/init par conséquent, vous voudrez alors essayer de déclarer ce fichier :

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

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

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

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 êtes sur 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 machine a SysV init dans son historique

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 qu'Ubuntu vient de passer à systemd depuis 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 "l'expérience". Vous verrez que 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 toute l'expérience.

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

C'est en fait un problème assez difficile. L'une des difficultés majeures est que les endroits où l'on veut le plus souvent faire cela sont les endroits où il est fort probable que l'on soit en train d'installer ou de changer des choses. Une 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 en cours d'exécution , et l'ensemble d'outils de gestion du système qui s'exécutera au prochain démarrage .

Pour déterminer ce qui est installé, on le fait avec un gestionnaire de paquets, bien sûr. 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 de Debian Linux a pris des mesures dans Debian 8 pour évoluer vers chaque programme ayant un nom différent (/lib/sysvinit/init , /lib/systemd/systemd , /sbin/runit-init , /sbin/minit , /sbin/system-manager , et ainsi de suite) pour cette raison précise, que les packages "non activables" n'entrent pas en conflit sur 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 maintenant et prêt à être exécuté ensuite ne peut être fait qu'avec une série de tests spécifiques à un ensemble d'outils, avec divers degrés de risque de faux positifs et avec divers degrés de documentation. Pour vérifier quel gestionnaire de système est en cours d'exécution en ce moment, en particulier, il faut vraiment regarder la liste des processus ou les différentes API publiées par les gestionnaires de système. Mais ce n'est pas totalement sans embûches.

Non partants généraux

Commençons par des choses qui ne le seront certainement pas travail.

/proc/1/exe pointera vers le même /sbin/init lors du démarrage ou du système 5 init courent en ce moment. Et sur certains systèmes, c'est aussi /sbin/init lorsque systemd est en cours d'exécution.

La foule de Debian Linux voulait s'orienter vers chaque programme ayant un nom différent, comme mentionné précédemment. Mais c'est spécifique à Debian, loin d'universel, et n'aide pas vraiment lorsque le programme est appelé en tant que /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 appelé avec son propre nom.
L'existence du fichier API de contrôle /dev/initctl n'est pas spécifique au System 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, parvenu, Système 5 rc , et OpenRC traitent tous /etc/init.d/ , pour une rétrocompatibilité 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 System 5 init est l'absence de /etc/inittab . Cependant :

C'est un effet secondaire de la façon dont Debian empaquete des choses comme /etc/inittab .
Une partie du problème global est que /etc/inittab reste dans les parages si System 5 init a été utilisé à n'importe quel 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 de Debian 8, car il existe plusieurs paquets dans Debian 7 qui s'installent 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 manière "officielle", on vérifie l'existence de /run/systemd/system . Ceci est un répertoire, en /run , que systemd lui-même crée au démarrage et que d'autres gestionnaires de système ne sont pas susceptibles de créer.

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

Les autres vérifications non officielles 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 :
- Ceci n'est pas couvert par la tristement célèbre "garantie de stabilité de l'interface" et pourrait changer demain ou à volonté.
- Il en va de même pour le serveur D-Bus similaire dans systemd-shim.
- Il en va de même pour inutile.
L'existence de /run/systemd/private n'est pas non plus garanti et dupliqué de la même manière par uselessd.

Détecter le nez

Le system-manager dans nosh crée un /run/system-manager annuaire. Mais cela partage les faiblesses de la vérification systemd équivalente.

Autres non partants :

La bouffe system-manager par conception, ne crée pas de canaux ou de sockets dans le système de fichiers et n'a pas d'API RPC en premier lieu.
La bouffe service-manager a classiquement un socket API à /run/service-manager/control , mais on peut lancer le nosh service gestionnaire sous un autre gestionnaire de système ; donc cela ne dit pas quel système le gestionnaire s'exécute en tant que processus n° 1. Dans tous les cas, il ne définit pas lui-même ce nom ; tout ce qui est invoqué fait.
L'existence d'une chaîne de version nosh, émise par system-control version , systemctl version (si les cales de compatibilité systemd sont installées) et initctl version (si les cales de compatibilité de démarrage sont installées) indique uniquement la présence de l'ensemble d'outils, car ces outils n'interrogent pas le système en cours d'exécution.

Détecter le parvenu

initctl d'Upstart fait un appel API sur D-Bus, et la vérification officielle est à la fois de 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 :