Come scoprire se un sistema utilizza SysV, Upstart o Systemd initsystem

Al processo init viene sempre assegnato il PID 1. Il /proc filesystem fornisce un modo per ottenere il percorso di un eseguibile dato un PID.

In altre parole:

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

Come puoi vedere, il processo init sulla mia casella Ubuntu 14.10 è Upstart. Ubuntu 15.04 usa systemd, quindi l'esecuzione di quel comando produce invece:

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

Se il sistema in cui ti trovi restituisce /sbin/init di conseguenza, allora vorrai provare a dichiarare quel file:

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

Puoi anche eseguirlo per saperne di più:

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

Puoi curiosare nel sistema per trovare gli indicatori. Un modo è verificare l'esistenza di tre directory:

• /usr/lib/systemd ti dice che sei su un sistema basato su systemd.

• /usr/share/upstart è un buon indicatore del fatto che sei su un sistema basato su Upstart.

• /etc/init.d ti dice che la scatola ha SysV init nella sua cronologia

Il fatto è che queste sono euristiche che devono essere considerate insieme, possibilmente con altri dati, non alcuni indicatori da soli. La scatola di Ubuntu 14.10 che sto guardando in questo momento ha tutte e tre le directory. Come mai? Perché Ubuntu è appena passato a systemd da Upstart in quella versione, ma mantiene Upstart e SysV init per compatibilità con le versioni precedenti.

Alla fine, penso che la risposta migliore sia "esperienza". Vedrai che hai effettuato l'accesso a una casella CentOS 7 e saprai che è systemd. Come lo impari? Giocare, RTFMing, ecc. Nello stesso modo in cui acquisisci tutta l'esperienza.

Mi rendo conto che questa non è una risposta molto soddisfacente, ma è quello che succede quando c'è frammentazione nel mercato, creando design non standard. È come chiedere come fai a sapere se ls accetta -C o --color o non esegue affatto l'output a colori. Ancora una volta, la risposta è "esperienza".

Questo è in realtà un problema abbastanza difficile. Una delle maggiori difficoltà è che i luoghi in cui si vuole fare più spesso sono i luoghi in cui è molto probabile che ci si trovi nel bel mezzo dell'installazione o della modifica delle cose. Un altro è che c'è una differenza sottile ma molto importante tra il set di strumenti di gestione del sistema installato , il set di strumenti di gestione del sistema attualmente in esecuzione e il set di strumenti di gestione del sistema che verrà eseguito al prossimo avvio .

Determinare cosa è installato si fa con un gestore di pacchetti, ovviamente. Ma questo è complicato dal fatto che diversi sistemi possono essere installati fianco a fianco.

Su Debian Linux, per esempio, si può installare il pacchetto systemd, ma è l'installazione del pacchetto separato systemd-sysv che lo rende il sistema attivo. L'intenzione è che i pacchetti systemd e sysvinit possano essere installati contemporaneamente. In effetti, il gruppo Debian Linux ha compiuto passi in Debian 8 per spostarsi verso ogni programma con un nome diverso (/lib/sysvinit/init , /lib/systemd/systemd , /sbin/runit-init , /sbin/minit , /sbin/system-manager , e così via) proprio per questo motivo, che i pacchetti "non attivanti" non entrano in conflitto sul nome /sbin/init . /sbin/init è quindi un collegamento simbolico a qualsiasi cosa sia stata configurata per essere eseguita all'avvio successivo da un "pacchetto di attivazione".

Determinare cosa è in esecuzione ora e pronto per essere eseguito dopo si può fare solo con una serie di test specifici del set di strumenti, con vari gradi di rischio da falsi positivi e con vari gradi di documentazione. Per verificare quale gestore di sistema è in esecuzione in questo momento, in particolare, è necessario guardare l'elenco dei processi o le varie API pubblicate dai gestori di sistema. Ma questo non è del tutto privo di insidie.

Non principianti generici

Cominciamo con cose che sicuramente non lavoro.

• /proc/1/exe punterà allo stesso /sbin/init quando upstart o System 5 init stanno correndo in questo momento. E su alcuni sistemi è anche /sbin/init quando systemd è in esecuzione.

  La folla di Debian Linux voleva spostarsi verso ogni programma con un nome diverso, come accennato in precedenza. Ma questo è specifico di Debian, far da universal, e non è di grande aiuto quando il programma viene invocato come /sbin/init (dalla fase initramfs del bootstrap) comunque. Solo il minit di Felix von Leitner è effettivamente impacchettato da Debian 8 per essere invocato con il proprio nome.

• L'esistenza del file API di controllo /dev/initctl non è specifico del sistema 5 init . systemd ha un (non processo n. 1) systemd-initctl server che serve questo. finit di Joachim Nilsson serve anche. (Giusto per rendere le cose ancora più divertenti, su Debian ora si trova in /run/initctl . Vedi https://superuser.com/a/888936/38062 per i dettagli.)
• systemd, parvenu, System 5 rc e OpenRC processano tutti /etc/init.d/ , per compatibilità con le versioni precedenti nel caso dei primi due. La sua esistenza non indica la presenza di un dato sistema.

Sistema di rilevamento 5 init

Ironia della sorte, come spiegato su https://unix.stackexchange.com/a/196197/5132 , in un modo almeno su Debian Linux per rilevare l'assenza del Sistema 5 init è l'assenza di /etc/inittab . Tuttavia:

• Questo è un effetto collaterale del modo in cui Debian impacchetta cose come /etc/inittab .
• Una parte del problema generale è che /etc/inittab rimane in giro se System 5 init è stato utilizzato in qualsiasi momento nel passato , perché la disinstallazione del pacchetto non ne elimina il file di configurazione. (Questo è stato un grosso problema per il lavoro di Debian 8, dal momento che ci sono diversi pacchetti in Debian 7 che si installano da soli aggiungendo voci a /etc/inittab .)
• È un test invertito.

Rilevamento del sistema

Per controllare systemd come gestore di sistema in esecuzione nel modo "ufficiale", si verifica l'esistenza di /run/systemd/system . Questa è una directory, in /run , che systemd stesso crea all'avvio e che è improbabile che altri gestori di sistema creino.

Ma è semplicemente improbabile . Questo assegno è già rotto , perché anche uselessd crea questa directory.

Altri controlli non ufficiali non funzioneranno:

• systemd pubblica un'intera API RPC su D-Bus, che contiene anche un nome e un numero di versione; ma:
  • Questo non è coperto dalla famigerata "Garanzia di stabilità dell'interfaccia" e potrebbe cambiare domani o per capriccio.
  • Così anche il server D-Bus simile in systemd-shim.
  • Anche inutilid.
• L'esistenza di /run/systemd/private allo stesso modo non è garantito e similmente duplicato da uselessd.

Rilevamento di nosh

Il system-manager in nosh crea un /run/system-manager directory. Ma questo condivide i punti deboli dell'equivalente controllo di sistema.

Ulteriori non partecipanti:

• Il nosh system-manager per progettazione non crea pipe o socket nel filesystem e non ha un'API RPC in primo luogo.
• Il nosh service-manager ha convenzionalmente un socket API in /run/service-manager/control , ma si può eseguire il servizio nosh manager sotto qualche altro gestore di sistema; quindi questo non dice quale sistema manager è in esecuzione come processo n. 1. In ogni caso, non imposta quel nome stesso; qualunque cosa sia invocata lo fa.
• L'esistenza di una stringa di versione nosh, emessa da system-control version , systemctl version (se uno ha gli shim di compatibilità systemd installati) e initctl version (se uno ha installato gli shim di compatibilità upstart) indica solo la presenza del set di strumenti, poiché questi strumenti non effettuano query sul sistema in esecuzione.

Rilevamento nuovo inizio

Il initctl di Upstart effettua una chiamata API su D-Bus e il controllo ufficiale consiste nel verificare che sia possibile eseguire initctl e che il suo output contenga la stringa "upstart" da qualche parte.

Ma, come l'API systemd:

• Non c'è alcuna garanzia che l'API sarà disponibile domani o non verrà modificata per capriccio.
• Non c'è alcuna garanzia che alcuni shim di compatibilità non esistano o non esisteranno in futuro.

  In effetti, esiste già uno shim di compatibilità. nosh ha un pacchetto di compatibilità upstart che fornisce shim per l'upstart initctl , start , stop e status comandi. Fortunatamente (anche se questo era intenzionale), il initctl shim non emette la parola "upstart".

  root ~ #initctl version
  nosh version 1.14
  root ~ #