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

No busques más por todo internet ya que llegaste al lugar necesario, contamos con la solución que quieres y sin liarte.

Solución:

Al proceso de inicialización siempre se le asigna el PID 1. /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 en su lugar 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á intentar establecer 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 le dice que está en un sistema basado en systemd.

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

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

El caso es que estas son heurísticas que deben considerarse juntas, posiblemente con otros datos, no con 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 sabrá 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 produce salida en color en absoluto. Una vez más, la respuesta es “experiencia”.

En realidad, este es 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 muy probable que uno se encuentre en medio de la instalación o el cambio de cosas. Otro 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.

Determinando qué está instalado uno 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 hacia que cada programa tenga un nombre diferente (/lib/sysvinit/init, /lib/systemd/systemd, /sbin/runit-init, /sbin/minit, /sbin/system-manager, etc.) por esta misma razón, que los paquetes “no activables” no entran en conflicto con el nombre /sbin/init. /sbin/init es entonces un enlace simbólico a lo que se configuró para ejecutarse en el próximo arranque mediante un “paquete de activación”.

Determinar qué se está ejecutando ahora y qué 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 false 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á del todo exento de trampas.

No iniciadores generales

Comencemos con cosas que definitivamente lo harán no trabaja.

• /proc/1/exe apuntará a lo mismo /sbin/init cuando ya sea advenedizo o Sistema 5 init se están ejecutando ahora mismo. Y en algunos sistemas, también /sbin/init cuando systemd se está ejecutando.

  La multitud de Debian Linux quería cambiar hacia 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á 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. Joachim Nilsson finit 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, System 5 rcy OpenRC todo el proceso /etc/init.d/, para 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, one way en Debian Linux al menos 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 System 5 init se utilizó en cualquier momento del 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 comprobar si systemd es el administrador del sistema en ejecución de manera “oficial”, se comprueba 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 creen otros administradores de sistemas.

Pero eso es simplemente improbable. Este cheque es ya 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 por capricho.
  • También lo hace el servidor D-Bus similar en systemd-shim.
  • También lo hace inútild.
• La existencia de /run/systemd/private tampoco está garantizado y es igualmente duplicado por uselessd.

Detectando nosh

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

Más no entrantes:

• La comida system-manager por diseño no crea tuberías o sockets en el sistema de archivos, y no tiene una API RPC en primer lugar.
• La comida service-manager convencionalmente tiene un socket API en /run/service-manager/control, pero uno puede correr la comida Servicio administrador bajo algún otro administrador del sistema; así que esto no le dice a nadie qué sistema el administrador se está ejecutando como el proceso n. ° 1. En cualquier caso, no establece ese nombre en sí mismo; lo que sea invocado lo hace.
• La existencia de una versión nosh string, emitido por system-control version, systemctl version (si uno tiene las calzas de compatibilidad systemd instaladas) y initctl version (si uno tiene instaladas las cuñas de compatibilidad advenedizas) solo indica la presencia del conjunto de herramientas, ya que estas herramientas no consultan el sistema en ejecución.

Detectando advenedizo

El propio advenedizo initctl realiza una llamada a la API a través de D-Bus, y la verificación oficial es verificar que uno pueda ejecutar initctl y que su salida contiene el string “advenedizo” en alguna parte.

Pero, como la API systemd:

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

  De hecho, ya existe una calza de compatibilidad. nosh tiene un paquete de compatibilidad advenedizo que proporciona calzas para el advenedizo initctl, start, stop, y status comandos. Afortunadamente (aunque esto fue intencional), el initctl shim no emite la palabra “advenedizo”.

  root ~ #initctl version
  nosh version 1.14
  root ~ #

Calificaciones y reseñas

Si para ti ha resultado de utilidad nuestro post, nos gustaría que lo compartas con otros seniors y nos ayudes a difundir nuestra información.

---

---

Utiliza Nuestro Buscador