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 récent système Debian wheezy ou Fedora ? Je suis conscient que Fedora 21 utilise systemd initsystem mais c'est parce que j'ai lu cela et parce que tous les scripts / liens symboliques sont stockés dans /etc/systemd/ . Cependant, je ne suis pas sûr de par exemple Debian squeeze ou CentOS 6 or 7 et ainsi de suite.

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

Vous pouvez explorer le système pour find des indicateurs. Une façon consiste à vérifier l'existence de trois directorys:

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

  • /usr/share/upstart est un très bon indicateur que vous utilisez un système basé sur Upstart.

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

La chose est, ce sont des heuristiques qui doivent être considérées set, éventuellement avec d'autres données, pas certains indicateurs par eux-mêmes. La boîte Ubuntu 14.10 que je regarde en ce moment a tous les trois directorys. Pourquoi? Parce qu'Ubuntu vient juste de passer à systemd depuis Upstart dans cette version, mais garde Upstart et SysV init pour une rétrocompatibilité.

En fin de count, je pense que la meilleure réponse est «l'expérience». Vous verrez que vous vous êtes connecté à une boîte CentOS 7 et que vous savez que c'est systemd. Comment apprends-tu cela? Jouer, RTFMing, etc. De la même façon que vous gagnez de l'expérience.

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

Le process d'initialisation est toujours affecté au PID 1. Le système de files /proc fournit un moyen d'get le path d'access à un exécutable à l'aide d'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 process d'initialisation sur ma boîte Ubuntu 14.10 est Upstart. Ubuntu 15.04 utilise systemd, donc exécuter cette command donne:

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

Si le système que vous utilisez donne /sbin/init en conséquence, vous voudrez essayer de mettre en place ce file:

 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. 

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 faire cela sont les endroits où il est fort probable que l'on sera en train d'installer ou de changer des choses. Une autre différence est qu'il existe une différence subtile mais très importante entre le jeu d'outils de gestion du système installé , le jeu d'outils de gestion du système en cours d'exécution et le jeu d'outils de gestion du système qui s'exécutera au démarrage suivant .

Déterminer ce qui est installé fait avec un gestionnaire de packages, 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 package systemd , mais c'est l'installation du package 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 à tous les programmes ayant un nom différent ( /lib/sysvinit/init , /lib/systemd/systemd , /sbin/runit-init , /sbin/minit , /sbin/system-manager , etc.) pour cette raison que les packages "non-activants" ne sont 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 et être prêt à être exécuté ensuite ne peut se faire qu'avec une série de tests spécifiques à un jeu d'outils, avec des degrés variables de risque à partir de faux positifs et avec divers degrés de documentation. Pour vérifier ce que le gestionnaire de système est en train d'exécuter en ce moment, en particulier, il faut vraiment regarder la list des process ou les différentes API que les gestionnaires de système publient. Mais ce n'est pas tout à fait sans pièges.

Général non-partants

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

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

    La foule de Debian Linux voulait se tourner vers tous les programmes ayant un nom différent, comme mentionné précédemment. Mais ceci est spécifique à Debian, loin d'être universel, et n'aide pas vraiment lorsque le programme est invoqué comme /sbin/init (par la phase initramfs du bootstrap). Seule la minit de Felix von Leitner est en réalité empackageée par Debian 8 pour être invoquée avec son propre nom.

  • L'existence du file API de contrôle /dev/initctl n'est pas spécifique à init système 5. systemd a un server systemd-initctl (non process n ° 1) qui le sert. Le finit Joachim Nilsson le sert aussi. (Pour rendre les choses encore plus amusantes, sur Debian, il est maintenant situé dans /run/initctl . Pour plus de détails, consultez la page https://superuser.com/a/888936/38062 ).
  • systemd, upstart, System 5 rc et OpenRC tous les process /etc/init.d/ , pour la rétrocompatibilité dans le cas des deux premiers. Son existence n'indique pas la présence d'un système donné.

Détection du système 5 init

Ironiquement, comme expliqué à https://unix.stackexchange.com/a/196197/5132 , une façon sur Debian Linux au less pour détecter l'absence de System 5 init est l'absence de /etc/inittab . Toutefois:

  • Ceci est un effet secondaire de la façon dont Debian a pu empackageer des choses comme /etc/inittab .
  • Une partie du problème global est que /etc/inittab persiste si System 5 init était utilisé par le passé , car la désinstallation du package ne supprime pas son file de configuration. (Cela a été un problème important pour Debian 8 car il y a plusieurs packages dans Debian 7 qui s'installent en ajoutant des inputs à /etc/inittab ).
  • C'est un test inversé.

Détection de systemd

Pour vérifier systemd en tant que gestionnaire du 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 directory, in /run , que systemd lui-même crée au démarrage, et que d'autres gestionnaires de système sont peu susceptibles de créer.

Mais c'est simplement improbable . Ce contrôle est déjà cassé , car uselessd crée aussi ce directory.

D'autres controls non officiels ne fonctionneront pas:

  • systemd publie toute une API RPC sur D-Bus, qui contient même un nom et un numéro de version; mais:
    • Ce n'est pas couvert par la sortingstement célèbre "Garantie de stabilité d'interface" et pourrait changer demain ou au gré du client.
    • Il en va de même pour le server D-Bus de Systemd-shim .
    • Il en est de même inutile.
  • L'existence de /run/systemd/private n'est de même pas garantie et dupliquée de la même façon par uselessd.

Détecter nosh

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

Autres non-partants:

  • Le system-manager nosh ne crée pas de tuyaux ou de sockets dans le système de files, et ne possède pas d'API RPC.
  • Le service-manager nosh a classiquement un socket API à /run/service-manager/control , mais on peut exécuter le gestionnaire de service de nosh sous un autre gestionnaire de système; donc cela ne dit pas à quel gestionnaire système s'exécute en tant que process # 1. En tout cas, il ne définit pas ce nom lui-même; quel que soit l'invoqué.
  • L'existence d'une string de version nosh, émise par la system-control version systemctl version (si on a les shims de compatibilité systemd installés) et la initctl version (si on a les shims de compatibilité upstart installés) n'indique que la présence du toolet les outils ne font aucune requête sur le système en cours d'exécution.

Détection de l'upstart

Le propre initctl Upstart fait un appel d'API sur D-Bus, et le contrôle officiel vérifie à la fois que l'on peut lancer initctl et que sa sortie contient la string "upstart" quelque part.

Mais, comme l'API systemd:

  • Il n'y a aucune garantie que l'API sera autour de demain ou pas changée au coup de coeur.
  • Il n'y a aucune garantie qu'une compatibilité shim n'existe pas ou n'existera pas dans le futur.

    En effet, il existe déjà une compatibilité shim. nosh a un package de compatibilité upstart qui fournit des shims pour les commands initctl , start , stop et status . Heureusement (bien que cela ait été intentionnel), la cale initctl n'émet pas le mot "upstart".

      root ~ #initctl version
     version nosh 1.14
     root ~ # 

Sur les systèmes basés sur RPM, vous pouvez interroger la database 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 append l'option --qf à RPM ("queryformat", à ne pas confondre avec l' autre -qf avec un tiret, ce qui signifie "query: file" ceci: rpm --qf '%{name}\n' -qf /sbin/init .

Sur les systèmes Debian, vous pouvez faire une chose similaire avec dpkg :

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

Et, la plupart des gestionnaires de packages auront une command similaire. Bien sûr, vous devez savoir quel gestionnaire de packageages votre distro utilise, ce qui pourrait être le fait d'échanger un problème pour un autre.

En outre, sur certaines dissortingbutions, il est possible que /sbin/init ne soit pas le bon file à examiner, probablement car init=/something/else est donné sur la command line du kernel. Une autre possibilité serait que /sbin/init soit un lien symbolique appartenant à un package d'assistance chargé de basculer entre les systèmes d'initialisation, et qui ne soit possédé par aucun d'eux directement. Un ou les deux peuvent être le cas sur Arch (même si je n'ai pas de boîte Arch à scope de main pour le moment).

Depuis 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 correctement à l'instance systemd en cours d'exécution.