Cómo saber si un sistema usa SysV, Upstart o Systemd initsystem

Al proceso init siempre se le asigna el PID 1. El /proc El sistema de archivos proporciona una forma de obtener la ruta a un ejecutable dado un PID.

En otras palabras:

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

Como puede ver, el proceso de inicio en mi caja de Ubuntu 14.10 es Upstart. Ubuntu 15.04 usa systemd, por lo que ejecutar ese comando produce:

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

Si el sistema en el que estás da /sbin/init como resultado, querrás intentar crear ese archivo:

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

También puede ejecutarlo para obtener más información:

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

Puede hurgar en el sistema para encontrar indicadores. Una forma es verificar la existencia de tres directorios:

• /usr/lib/systemd te dice que estás en un sistema basado en systemd.

• /usr/share/upstart es un buen indicador de que estás en un sistema basado en Upstart.

• /etc/init.d te dice que la caja tiene SysV init en su historial

La cuestión es que estas son heurísticas que deben considerarse juntas, posiblemente con otros datos, no ciertos indicadores por sí mismos. El cuadro de Ubuntu 14.10 que estoy viendo ahora tiene los tres directorios. ¿Por qué? Porque Ubuntu acaba de cambiar a systemd desde Upstart en esa versión, pero mantiene Upstart y SysV init para compatibilidad con versiones anteriores.

Al final, creo que la mejor respuesta es "experiencia". Verá que ha iniciado sesión en un cuadro de CentOS 7 y sabe que es systemd. ¿Cómo aprendes esto? Jugando, RTFMing, etc. De la misma manera que ganas toda la experiencia.

Me doy cuenta de que esta no es una respuesta muy satisfactoria, pero eso es lo que sucede cuando hay fragmentación en el mercado, creando diseños no estándar. Es como preguntar cómo sabes si ls acepta -C o --color , o no realiza ninguna salida de color. De nuevo, la respuesta es "experiencia".

Esto es en realidad un problema bastante difícil. Una de las mayores dificultades es que los lugares donde uno quiere hacer esto con mayor frecuencia son los lugares donde es bastante probable que uno esté en medio de la instalación o el cambio de cosas. Otra es que hay una diferencia sutil pero muy importante entre el conjunto de herramientas de administración del sistema que está instalado , el conjunto de herramientas de administración del sistema que se está ejecutando en este momento y el conjunto de herramientas de administración del sistema que se ejecutará en el próximo arranque .

La determinación de lo que está instalado se hace con un administrador de paquetes, por supuesto. Pero esto se complica por el hecho de que se pueden instalar varios sistemas uno al lado del otro.

En Debian Linux, por ejemplo, se puede instalar el paquete systemd, pero es la instalación del paquete systemd-sysv separado lo que lo convierte en el sistema activo. La intención es que los paquetes systemd y sysvinit se puedan instalar simultáneamente. De hecho, la multitud de Debian Linux ha tomado medidas en Debian 8 para cambiar a que cada programa tenga un nombre diferente (/lib/sysvinit/init , /lib/systemd/systemd , /sbin/runit-init , /sbin/minit , /sbin/system-manager , y así sucesivamente) por esta misma razón, que los paquetes "no activados" no entran en conflicto en el nombre /sbin/init . /sbin/init es entonces un enlace simbólico a lo que se configuró para ejecutarse en el siguiente arranque mediante un "paquete de activación".

Determinar lo que se está ejecutando ahora y lo que está listo para ejecutarse a continuación solo se puede hacer con una serie de pruebas específicas del conjunto de herramientas, con diversos grados de riesgo de falsos positivos y con diversos grados de documentación. Para verificar qué administrador del sistema se está ejecutando en este momento, específicamente, uno realmente tiene que mirar la lista de procesos o las diversas API que publican los administradores del sistema. Pero esto no está totalmente libre de trampas.

No iniciados generales

Comencemos con cosas que definitivamente no trabajo.

• /proc/1/exe apuntará al mismo /sbin/init cuando sea upstart o System 5 init están corriendo ahora mismo. Y en algunos sistemas, también es /sbin/init cuando systemd se está ejecutando.

  La gente de Debian Linux quería cambiar a que cada programa tuviera un nombre diferente, como se mencionó anteriormente. Pero esto es específico de Debian, lejos de universal, y realmente no ayuda cuando el programa se invoca como /sbin/init (por la fase initramfs del bootstrap) de todos modos. Solo el minit de Felix von Leitner está realmente empaquetado por Debian 8 para ser invocado con su propio nombre.

• La existencia del archivo API de control /dev/initctl no es específico del Sistema 5 init . systemd tiene un (no proceso #1) systemd-initctl servidor que sirve esto. finit de Joachim Nilsson también lo sirve. (Solo para hacer las cosas más divertidas, en Debian ahora se encuentra en /run/initctl . Consulte https://superuser.com/a/888936/38062 para obtener más detalles).
• systemd, advenedizo, Sistema 5 rc y OpenRC todos procesan /etc/init.d/ , por compatibilidad con versiones anteriores en el caso de los dos primeros. Su existencia no indica la presencia de ningún sistema dado.

Sistema de detección 5 init

Irónicamente, como se explica en https://unix.stackexchange.com/a/196197/5132, de una forma al menos en Debian Linux para detectar la ausencia del Sistema 5 init es la ausencia de /etc/inittab . Sin embargo:

• Este es un efecto secundario de la forma en que Debian empaqueta cosas como /etc/inittab .
• Una parte del problema general es que /etc/inittab se queda si el Sistema 5 init se usó en cualquier momento en el pasado , porque la desinstalación del paquete no elimina su archivo de configuración. (Este ha sido un problema considerable para el trabajo de Debian 8, ya que hay varios paquetes en Debian 7 que se instalan agregando entradas a /etc/inittab .)
• Es una prueba invertida.

Detectando systemd

Para verificar systemd como el administrador del sistema en ejecución de la manera "oficial", se verifica la existencia de /run/systemd/system . Este es un directorio, en /run , que systemd mismo crea en el arranque, y que es poco probable que otros administradores de sistemas creen.

Pero eso es meramente poco probable . Este cheque ya está roto , porque uselessd también crea este directorio.

Otros cheques no oficiales no funcionarán:

• systemd publica una API RPC completa sobre D-Bus, que incluso contiene un nombre y número de versión; pero:
  • Esto no está cubierto por la infame "Garantía de estabilidad de la interfaz" y podría cambiar mañana o cuando lo desee.
  • También lo hace el servidor D-Bus similar en systemd-shim.
  • También lo hace uselessd.
• La existencia de /run/systemd/private tampoco está garantizado y duplicado de manera similar por uselessd.

Detectando nosh

El system-manager en nosh crea un /run/system-manager directorio. Pero esto comparte las debilidades del systemd check equivalente.

Otros no principiantes:

• La comida system-manager por diseño, no crea conductos ni conectores en el sistema de archivos y, en primer lugar, no tiene una API RPC.
• La comida service-manager convencionalmente tiene un conector API en /run/service-manager/control , pero se puede ejecutar el servicio nosh administrador bajo algún otro administrador del sistema; así que esto no le dice a uno qué sistema el administrador se está ejecutando como proceso #1. En cualquier caso, no establece ese nombre por sí mismo; lo que sea que se invoque lo hace.
• La existencia de una cadena de versión nosh, emitida por system-control version , systemctl version (si uno tiene instaladas las correcciones de compatibilidad systemd) y initctl version (si uno tiene instaladas las correcciones de compatibilidad upstart) solo indica la presencia del conjunto de herramientas, ya que estas herramientas no consultan el sistema en ejecución.

Detectando advenedizo

El propio initctl de Upstart hace una llamada API a través de D-Bus, y la verificación oficial es verificar que uno pueda ejecutar initctl y que su salida contiene la cadena "advenedizo" en alguna parte.

Pero, como la API systemd:

• No hay garantía de que la API estará disponible mañana o no se cambiará a su antojo.
• No hay garantía de que alguna corrección de compatibilidad no exista o no existirá en el futuro.

  De hecho, ya existe una corrección de compatibilidad. nosh tiene un paquete de compatibilidad advenedizo que proporciona correcciones para el advenedizo initctl , start , stop y status comandos Afortunadamente (aunque esto fue intencional), el initctl shim no emite la palabra "upstart".

  root ~ #initctl version
  nosh version 1.14
  root ~ #