En los sistemas operativos basados en Unix , init (abreviatura de initialization ) es el primer proceso que se inicia durante el arranque del sistema operativo. Init es un proceso demonio que continúa ejecutándose hasta que se apaga el sistema. Es el antecesor directo o indirecto de todos los demás procesos y adopta automáticamente todos los procesos huérfanos . Init es iniciado por el núcleo durante el proceso de arranque ; se producirá un pánico del núcleo si el núcleo no puede iniciarlo o si muere por alguna razón. A init se le asigna normalmente el identificador de proceso 1.
En sistemas Unix como System III y System V , el diseño de init ha divergido de la funcionalidad proporcionada por el init en Research Unix y sus derivados BSD . Hasta principios de la década de 2010, [1] [ verificación fallida ] la mayoría de las distribuciones de Linux empleaban un init tradicional que era algo compatible con System V, mientras que algunas distribuciones como Slackware usan scripts de inicio de estilo BSD, y otras como Gentoo tienen sus propias versiones personalizadas.
Desde entonces, se han creado varias implementaciones de init adicionales, que intentan abordar las limitaciones de diseño de las versiones tradicionales. Entre ellas, se incluyen launchd , Service Management Facility , systemd , Runit y OpenRC .
Research Unix init ejecuta el script de inicialización de shell ubicado en /etc/rc
, [2] luego lanza getty en terminales bajo el control de /etc/ttys
. [3] No hay niveles de ejecución; el /etc/rc
archivo determina qué programas ejecuta init. La ventaja de este sistema es que es simple y fácil de editar manualmente. Sin embargo, el nuevo software agregado al sistema puede requerir cambios en los archivos existentes que corren el riesgo de producir un sistema que no se pueda iniciar.
BSD init era, antes de 4.3BSD, el mismo que init de Research UNIX; [4] [5] en 4.3BSD , agregó soporte para ejecutar un sistema de ventanas como X en terminales gráficas bajo el control de /etc/ttys
. [6] [7] Para eliminar el requisito de editar /etc/rc
, las variantes de BSD han admitido durante mucho tiempo un /etc/rc.local
archivo específico del sitio que se ejecuta en un sub-shell cerca del final de la secuencia de arranque.
Con NetBSD 1.5 se introdujo un sistema completamente modular que se adaptó a FreeBSD 5.0 y sus sucesores. Este sistema ejecuta los scripts en el /etc/rc.d
directorio. A diferencia del orden de los scripts de System V, que se deriva del nombre de archivo de cada script, este sistema utiliza etiquetas de dependencia explícitas ubicadas dentro de cada script. [8] El orden en el que se ejecutan los scripts lo determina la utilidad rcorder en función de los requisitos establecidos en estas etiquetas.
En comparación con sus predecesores, el UNIX System III de AT&T introdujo un nuevo estilo de configuración de inicio del sistema, [9] que sobrevivió (con modificaciones) en el UNIX System V y por lo tanto se denomina "init estilo SysV".
En cualquier momento, un sistema V en ejecución se encuentra en uno de los estados predeterminados, llamados niveles de ejecución . Al menos un nivel de ejecución es el estado operativo normal del sistema; normalmente, otros niveles de ejecución representan el modo de usuario único (utilizado para reparar un sistema defectuoso), el apagado del sistema y varios otros estados. Al cambiar de un nivel de ejecución a otro, se ejecuta un conjunto de scripts por nivel de ejecución, que normalmente montan sistemas de archivos, inician o detienen daemons , inician o detienen el sistema X Window , apagan la máquina, etc.
Los niveles de ejecución de System V describen determinados estados de una máquina, caracterizados por los procesos y daemons que se ejecutan en cada uno de ellos. En general, hay siete niveles de ejecución, de los cuales tres se consideran "estándar", ya que son esenciales para el funcionamiento de un sistema:
Aparte de estos estándares, los sistemas Unix y similares tratan los niveles de ejecución de forma algo diferente. El denominador común, el /etc/inittab
archivo, define lo que hace cada nivel de ejecución configurado en un sistema determinado.
Sistema operativo | Nivel de ejecución predeterminado |
---|---|
AIX | 2 |
antiX | 5 |
Gentoo Linux | 3 [10] |
HP-UX | 3 (consola/servidor/multiusuario) o 4 (gráfico) |
Linux desde cero | 3 |
Software de Slackware Linux | 3 |
Solaris / illumos | 3 [11] |
Sistema UNIX V, versiones 3.x y 4.x | 2 |
UnixWare 7.x | 3 |
En las distribuciones Linux que tienen como valor predeterminado el nivel de ejecución 5 en la tabla de la derecha, el nivel de ejecución 5 invoca un entorno gráfico multiusuario que ejecuta el sistema X Window , normalmente con un administrador de pantalla como GDM o KDM . Sin embargo, los sistemas operativos Solaris e illumos suelen reservar el nivel de ejecución 5 para apagar automáticamente la máquina.
En la mayoría de los sistemas, todos los usuarios pueden comprobar el nivel de ejecución actual con el comando runlevel
o who -r
. [12] El usuario root normalmente cambia el nivel de ejecución actual ejecutando los comandos telinit
o init
. El /etc/inittab
archivo establece el nivel de ejecución predeterminado con la :initdefault:
entrada .
En los sistemas Unix, el cambio de nivel de ejecución se logra iniciando solo los servicios faltantes (ya que cada nivel define solo aquellos que se inician/detienen). [ cita requerida ] Por ejemplo, cambiar un sistema del nivel de ejecución 3 al 4 solo podría iniciar el servidor X local. Al regresar al nivel de ejecución 3, se detendría nuevamente.
Tradicionalmente, una de las principales desventajas de init es que inicia las tareas en serie, esperando a que cada una termine de cargarse antes de pasar a la siguiente. Cuando los procesos de inicio terminan con la entrada/salida (E/S) bloqueada, esto puede provocar demoras prolongadas durante el arranque. Acelerar la E/S, por ejemplo, mediante el uso de SSD, puede acortar las demoras, pero no soluciona la causa raíz.
Se han realizado varios esfuerzos para reemplazar los daemons init tradicionales para abordar este y otros problemas de diseño, incluidos:
A partir de febrero de 2019 [actualizar], systemd ha sido adoptado por la mayoría de las principales distribuciones de Linux. [23]