Détecter le système init à l'aide du shell

Cela a peut-être plus à voir avec la détection des systèmes d'exploitation, mais j'ai particulièrement besoin du système init actuellement utilisé sur le système.

Fedora 15 et Ubuntu utilisent maintenant systemd, Ubuntu utilisait Upstart (valeur par défaut jusqu'à 15.04), tandis que d'autres utilisent des variantes de System V.

J'ai une application que je suis en train d'écrire pour être un démon multi-plateforme. Les scripts d'initialisation sont générés dynamiquement en fonction de paramètres pouvant être transmis lors de la configuration.

Ce que j'aimerais faire, c'est générer uniquement le script pour le système d'init particulier qu'ils utilisent. De cette façon, le script d'installation peut être exécuté raisonnablement sans paramètre en tant que root et le démon peut être "installé" automatiquement.

C'est ce que je suis venu avec:

• Recherchez systemd, upstart, etc. dans / bin
• Comparez / proc / 1 / comm avec le systemd, upstart, etc
• Demander à l'utilisateur

Quel serait le meilleur moyen de procéder de la sorte?

Type de parenté, puis-je compter sur bash pour être sur la majorité de * nix ou est-ce que cela dépend de la distribution / du système d'exploitation?

Plateformes cibles:

• Mac OS
• Linux (toutes les distributions)
• BSD (toutes les versions)
• Solaris, Minix et autres * nix

Pour la deuxième question, la réponse est non et vous devriez jeter un coup d'œil à Ressources pour la programmation shell portable .

Pour ce qui est de la première partie, il faut d’abord faire attention. Je dirais de faire plusieurs tests pour être sûr - parce que le fait que quelqu'un ait installé systemd (par exemple) ne signifie pas qu'il est réellement utilisé par défaut init. En outre, regarder /proc/1/commpeut être trompeur, car certaines installations de différents programmes init peuvent automatiquement créer /sbin/initun lien symbolique ou même une version renommée de leur programme principal.

Le plus utile serait peut-être d’examiner le type de script init, car c’est ce que vous allez réellement créer, quel que soit son exécution.

En passant , vous pouvez également consulter OpenRC, qui vise à fournir une structure de scripts init compatible avec les systèmes Linux et BSD.

J'ai moi-même abordé ce problème et décidé de faire des tests. Je suis tout à fait d’accord avec la réponse selon laquelle il faut emballer séparément chaque distribution, mais il existe parfois des problèmes pratiques qui l’empêchent (notamment le manque de main-d’œuvre).

Donc, pour ceux qui veulent "détecter automatiquement", voici ce que j'ai découvert sur un nombre limité de distributions (voir ci-dessous):

• Vous pouvez identifier dès le départ:

  [[ `/sbin/init --version` =~ upstart ]] && echo yes || echo no

• Vous pouvez dire à systemd de:

  [[ `systemctl` =~ -\.mount ]] && echo yes || echo no

• Vous pouvez dire à sys-v init de:

  [[ -f /etc/init.d/cron && ! -h /etc/init.d/cron ]] && echo yes

Voici mes expériences avec la ligne de commande suivante:

if [[ `/sbin/init --version` =~ upstart ]]; then echo using upstart;
elif [[ `systemctl` =~ -\.mount ]]; then echo using systemd;
elif [[ -f /etc/init.d/cron && ! -h /etc/init.d/cron ]]; then echo using sysv-init;
else echo cannot tell; fi

sur les instances ec2 (j'inclus l'identifiant d'AMI us-east):

• ArchLinux: using systemd (depuis le 2012.10.06 )
• CentOS6.4 ami-52009e3b: utilisation de la version récente
• CentOS7 ami-96a818fe: utilisation de systemd
• Debian 6 ami-80e915e9: utiliser sysv-init
• Debian 7.5 ami-2c886c44: utiliser sysv-init
• Debian 7.6 GCE conteneur-vm: utiliser sysv-init
• RHEL 6.5 ami-8d756fe4: utilisation récente
• SLES 11 ami-e8084981: utilisation de sysv-init
• Ubuntu 10.04 ami-6b350a02: utiliser Upstart
• Ubuntu 12.04 ami-b08b6cd8: utiliser upstart
• Ubuntu 14.04 ami-a427efcc: utiliser upstart
• Ubuntu 14.10 et moins: utilisation de systemd
• AWS linux 2014.3.2 ami-7c807d14: utilisation de la version récente
• Fedora 19 ami-f525389c: utilisation de systemd
• Fedora 20 ami-21362b48: utilisation de systemd

Juste pour être clair: je ne prétends pas que c'est infaillible! ce n'est certainement pas le cas. Notez également que par commodité, j'utilise des correspondances bash regexp, qui ne sont pas disponibles partout. Ce qui précède me suffit pour le moment. Cependant, si vous trouvez une distribution où elle échoue, faites-le moi savoir et j'essaierai de la réparer s'il existe une AMI EC2 qui reproduit le problème ...

Utiliser des processus

En regardant le résultat de quelques pscommandes capables de détecter les différentes versions de systemd& upstart, qui pourraient être conçues comme suit:

parvenu

$ ps -eaf|grep '[u]pstart'
root       492     1  0 Jan02 ?        00:00:00 upstart-udev-bridge --daemon
root      1027     1  0 Jan02 ?        00:00:00 upstart-socket-bridge --daemon

systemd

$ ps -eaf|grep '[s]ystemd'
root         1     0  0 07:27 ?        00:00:03 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
root       343     1  0 07:28 ?        00:00:03 /usr/lib/systemd/systemd-journald
root       367     1  0 07:28 ?        00:00:00 /usr/lib/systemd/systemd-udevd
root       607     1  0 07:28 ?        00:00:00 /usr/lib/systemd/systemd-logind
dbus       615     1  0 07:28 ?        00:00:13 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation

Faire attention au nom du processus qui est le PID # 1 peut aussi potentiellement éclairer le système init utilisé. Sur Fedora 19 (qui utilise systemd, par exemple:

UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 07:27 ?        00:00:03 /usr/lib/systemd/systemd --switched-root --system --deserialize 20

Remarquez que non init. Sur Ubuntu avec Upstart c'est encore /sbin/init.

$ ps -efa|grep init
root         1     0  0 Jan02 ?        00:00:03 /sbin/init

NOTE: Mais utilisez ceci avec un peu de prudence. Rien dans la pierre ne dit qu'un système d'initialisation particulier utilisé sur une distribution donnée doit avoir systemdle PID # 1.

générique

$ (ps -eo "ppid,args" 2>/dev/null || echo "ps call error") \
    | awk 'NR==1 || $1==1' | less
 PPID   COMMAND
    1   /lib/systemd/systemd-journald
    1   /lib/systemd/systemd-udevd
    1   /lib/systemd/systemd-timesyncd

Regardez les processus avec ppid 1 (enfants du processus init). Certains noms de processus enfants peuvent pointer vers le système init utilisé.

Le système de fichiers

Si vous interrogez l' initexécutable, vous pouvez également obtenir des informations à ce sujet. Simplement analyser la --versionsortie. Par exemple:

parvenu

$ sudo /sbin/init --version
init (upstart 1.5)
Copyright (C) 2012 Scott James Remnant, Canonical Ltd.

This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY
or FITNESS FOR A PARTICULAR PURPOSE.

systemd

$ type init
init is /usr/sbin/init

REMARQUE: le fait de initne pas se trouver à son emplacement standard est un indice. Il est toujours situé /sbin/initsur les systèmes sysvinit.

sysvinit

$ type init
init is /sbin/init

Aussi ceci:

$ sudo init --version
init: invalid option -- -
Usage: init 0123456SsQqAaBbCcUu

Conclusions

Il ne semble donc pas exister de solution unique, mais vous pouvez formuler une série de vérifications permettant de déterminer le système d’initialisation que vous utilisez avec un degré de confiance assez élevé.

Pas si efficace que ça mais ça a l'air de marcher.

strings /sbin/init | grep -q "/lib/systemd" && echo SYSTEMD
strings /sbin/init | grep -q "sysvinit" && echo SYSVINIT
strings /sbin/init | grep -q "upstart" && echo UPSTART

Il imprimera plus de lignes si plus d'une chaîne correspond, ce qui pourrait être traduit par "Je ne peux pas deviner". Les chaînes utilisées dans grep peuvent être légèrement modifiées, mais lorsqu’elles ont été testées dans l’os suivant, j’ai toujours une ligne.

• RHEL 6.4 [UPSTART]
• RHEL ES 4 (Mise à jour 7 de Nahant) [SYSVINIT]
• Ubuntu 16.04.1 LTS [SYSTEMD]
• Ubuntu 14.04.2 LTS [UPSTART]
• Fedora version 23 (shell en ligne) [SYSTEMD]
• Debian GNU / Linux 7 (shell en ligne) [SYSTEMD]

Une approche plus simpliste de la même solution (mais cela s'arrête au premier match)

strings /sbin/init |
  awk 'match($0, /(upstart|systemd|sysvinit)/) { print toupper(substr($0, RSTART, RLENGTH));exit; }'

Parfois, c'est aussi simple que d'utiliser ls :

$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 juin  25 12:04 /sbin/init -> /lib/systemd/systemd

J'imagine que s'il /sbin/initne s'agit pas d'un lien symbolique, vous devrez vérifier les suggestions suivantes dans les autres réponses.

1. C’est ce à quoi servent les packages spécifiques à la distribution. Pour installer le logiciel correctement, il ne suffit pas de détecter le système init. Beaucoup de distributions utilisent SysVinit mais toutes n'écrivent pas leurs scripts init de la même manière. Pour résoudre ce problème, la meilleure solution consiste à inclure toutes les variantes et à les regrouper à l’aide de fichiers de spécification avec des noms de dépendances spécifiques à la distribution pour les distributions rpm, les fichiers deb pour les systèmes apt, etc. peut écrire avec des dépendances, des scripts, des scripts d'initialisation, etc. Ne réinventez pas la roue ici.

2. Ce qui nous ramène à 1. Si vous avez besoin de bash, cela devrait être une dépendance. Vous pouvez spécifier cette vérification dans vos scripts de configuration, mais elle devrait également figurer dans les descriptions de paquet.

Modifier: utilisez des indicateurs sur votre script de configuration, tels que --with upstartou --without sysvinit. Choisissez une valeur par défaut, les scripts qui conditionnent votre logiciel pour d’autres distributions peuvent choisir de l’exécuter avec d’autres options.

Sur Gentoo, regardez pid 1:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   4216   340 ?        Ss    2013   0:57 init [3]

Si c'est le cas init, le système init est OpenRC. Si c'est le cas systemd, le système init est systemd.

Vous pouvez détecter Gentoo avec [ -f /etc/gentoo-release ].

Une autre méthode sur Gentoo consiste à utiliser profile-config show, qui montrera quel profil par défaut est utilisé. Tous les profils, sauf les deux se terminant par / systemd, utilisent l'init OpenRC. N'oubliez pas que ces éléments ne sont représentatifs que d'un paramètre par défaut et qu'il est possible que l'utilisateur ait pris des mesures pour remplacer ce paramètre par défaut.

Sur debian / sbin / init est un lien symbolique vers votre init par défaut afin

ls -l /sbin/init

vous donnera l'information que vous cherchez.

$ ls -l /sbin/init 
lrwxrwxrwx 1 root root 20 nov 18 13:15 /sbin/init -> /lib/systemd/systemd

En entrant simplement dans le processus avec le PID 1, vous apprendrez:

strings /proc/1/exe |grep -q sysvinit
strings /proc/1/exe |grep -q systemd

L'inspection des descripteurs de fichiers peut également aider. Et c'est à partir de l'initialisation en cours (l'étirement de Debian permet actuellement d'installer plus de systèmes d'initialisation) :-)

$ ls -l /proc/1/fd |grep systemd
lrwx------ 1 root root 64 srp 14 13:56 25 -> /run/systemd/initctl/fifo
lr-x------ 1 root root 64 srp 14 13:56 6 -> /sys/fs/cgroup/systemd

$ ls -l /proc/1/fd |grep /run/initctl # sysvinit
lrwx------ 1 root root 64 srp 14 14:04 10 -> /run/initctl

$ ls -l /proc/1/fd |grep upstart
l-wx------ 1 root root 64 srp 13 16:09 13 -> /var/log/upstart/mysql.log.1 (delete
l-wx------ 1 root root 64 srp 13 16:09 9 -> /var/log/upstart/dbus.log.1 (deleted)

$ ls -l /proc/1/fd # busybox
total 0
lrwx------    1 root     root          64 Jan  1 00:00 0 -> /dev/console
lrwx------    1 root     root          64 Jan  1 00:00 1 -> /dev/console
lrwx------    1 root     root          64 Jan  1 00:00 2 -> /dev/console

Le moyen le plus sûr de rechercher une busybox serait de le faire check /proc/1/exe, puisque busybox utilise généralement des liens symboliques:

$ ls -l /proc/1/exe 
lrwxrwxrwx    1 root     root          0 Jan  1 00:00 /proc/1/exe -> /bin/busybox

Donc, vérifier pourrait être:

{ ls -l /proc/1/fd |grep -q systemd && echo "init: systemd"; } || \
{ ls -l /proc/1/fd |grep -q /run/initctl && echo "init: sysvinit"; } || \
{ ls -l /proc/1/fd |grep -q upstart && echo "init: upstart"; } || \
{ ls -l /proc/1/exe |grep -q busybox && echo "init: busybox"; } || \
echo "unknown init"

Je ne connais pas d’autres systèmes que Debian (Wheezy) / ou Ubuntu (14.10.), Mais j’ai testé de tels problèmes avec la filecommande plain old .

file /sbin/init

donne ça:

/sbin/init: symbolic link to 'upstart'

Les systèmes Debian avec systemd(par exemple, sid) montrent ceci:

# file /sbin/init 
/sbin/init: symbolic link to /lib/systemd/systemd

J'ai également eu le même problème et fait beaucoup de tests sur certaines machines RedHat / CentOS / Debian / Ubuntu / Mint. C'est ce que j'ai fini avec, avec de bons résultats.

1. Trouvez le nom de l'exécutable avec le PID 1:

   ps -p 1

   Si c'est systemd ou Upstart, le problème est résolu. Si c'est "init", il peut s'agir d'un lien symbolique ou de quelque chose d'autre qu'un nom initial. Aller de l'avant.

2. Trouvez le vrai chemin pour l'exécutable (ne travaillez que comme root):

   ls -l `which init`

   Si initest un lien symbolique vers Upstart ou systemd, le problème est résolu. Sinon, il est presque certain que vous avez initié SysV. Mais cela peut être un exécutable mal nommé. Aller de l'avant.

3. Trouvez le paquet qui fournit l'exécutable. Malheureusement, cela dépend de la distro:

   dpkg-query -S (executable real path) # Debian  
   rpm -qf (executable real path) # RedHat  

Ensuite, si vous voulez écrire un script (la partie la plus drôle, à mon humble avis), voici mes one-liners (exécutés en tant que root):

ls -l $(which $(ps -p 1 o comm)) | awk '{ system("dpkg-query -S "$NF) }' # Debian  

ls -l $(which $(ps -p 1 o comm)) | awk '{ system("rpm -qf "$NF) }' # RedHat  

C'est vraiment facile pour certains systèmes init. Pour systemd:

test -d /run/systemd/system

pour le débutant:

initctl --version | grep -q upstart

pour toute autre chose, vous pouvez simplement supposer basé sur la distribution (lancé sur OS X, sysvinit sur Debian, OpenRC sur Gentoo).

Voici un script bash pour effectuer la détection. Il ne vérifie que les versions récente et système du système, mais devrait être facile à étendre. J'ai pris cela dans le code que j'ai contribué au script d'installation du pilote DisplayLink .

detect_distro()
{
  # init process is pid 1
  INIT=`ls -l /proc/1/exe`
  if [[ $INIT == *"upstart"* ]]; then
    SYSTEMINITDAEMON=upstart
  elif [[ $INIT == *"systemd"* ]]; then
    SYSTEMINITDAEMON=systemd
  elif [[ $INIT == *"/sbin/init"* ]]; then
    INIT=`/sbin/init --version`
    if [[ $INIT == *"upstart"* ]]; then
      SYSTEMINITDAEMON=upstart
    elif [[ $INIT == *"systemd"* ]]; then
      SYSTEMINITDAEMON=systemd
    fi
  fi

  if [ -z "$SYSTEMINITDAEMON" ]; then
    echo "WARNING: Unknown distribution, assuming defaults - this may fail." >&2
  else
    echo "Init system discovered: $SYSTEMINITDAEMON"
  fi
}

Il y a de nombreux pièges de compatibilité lors du test de systemd vs initd. Cela fonctionne réellement sur OpenSuSE 42.1:ps --pid 1 | grep -q systemd && echo 'systemd' || echo 'init'

Pour systemd:

if [[ `systemctl is-system-running` =~ running ]]; then echo using systemd; fi

Ma solution: vérifiez la commande en cours d'exécution en tant que processus avec l'ID 1.

case `cat /proc/1/comm` in
    init)    echo Init ;;
    systemd) echo SystemD ;;
    # add here other patterns
    *)       echo "unknown: '`cat /proc/1/comm`'" ;;
esac

Pour le moment, je n'ai accès qu'aux machines Init et SystemD. Je ne peux donc pas dire comment Upstart ou macOS (OS X) seront détectés, mais je vais continuer à chercher.

check(){
    if hash systemctl 2>/dev/null;
    then
        echo "there is systemd"
    fi

    if hash initctl 2>/dev/null;
    then
        echo "there is upStart"
    fi

    if [ -f "/etc/inittab"];
    then
        echo "there is systemV"
    fi
}