THE LJ LINUX FOUNDATION Capitulo 4. init: SystemV, Upstart, Systemd Cuando un sistema Linux se inicia, muchas tareas deben llevarse a cabo de manera cooperativa. Los dispositivos tienen que ser reconocidos e inicializados, los servicios del sistema tienen que ser lanzados, los sistemas de archivos tienen que estar disponibles, procesos de gestién importantes tienen que iniciarse y el sistema debe estar disponible a los usuarios para iniciar sesién. Todo esto debe hacerse en la secuencia correcta y lo mas rapidamente posible Objetivos de Aprendizaje Al final de este capitulo usted deberia estar capacitado para: + Entender la importancia del proceso Explicar cémo funciona el método tradicional de SysVinit, cémo incorpora los niveles de ejecucién y qué sucede en cada uno. + Saber usar chkconfig y service (y utilidades alternativas) para iniciar y detener servicios o hacerlos persistentes luego del reinicio del sistema + Entender por qué surgieron los métodos altemativos Upstart ysystemd y cémo funcionan. ‘+ Usar systemetl para configurar y controlar systemd. LFS201: Fundamentos de Administracién de Sistemas Linux 58THE LJ LINUX FOUNDATION 4.1 Proceso init /sbin/init (normalmente llamado init) es el primer proceso (0 tarea) a nivel de usuario que se ejecuta en el sistema y continua funcionando hasta que el sistema se apaga. Tradicionalmente ha sido considerado el padre de todos los procesos del usuario, aunque técnicamente eso no es cierto ya que algunos procesos son iniciados directamente por el kernel. init coordina las etapas posteriores del proceso de arranque, configura todos los aspectos del ambiente e inicia los procesos necesarios para entrar/autenticarse en el sistema. init también trabaja estrechamente con el kernel para limpiar lo necesario a medida en que los procesos terminan. Tradicionalmente casi todas las distribuciones basan el proceso init en el venerable SysVinit de UNIX. Sin embargo, este esquema fue desarrollado décadas atras en circunstancias muy diferentes: * El objetivo eran sistemas multiusuario de tipo mainframe (y no ordenadores personales, portatiles y otros dispositivos). ‘+ El objetivo era un sistema de procesador tinico. * El tiempo de inicio (y apagado) no era un asunto importante; eta mucho mas importante hacer que las cosas funcionaran bien. El inicio fue visto como un proceso serial, dividido en una serie de etapas secuenciales. Cada etapa requeria ser finalizada antes de que la préxima pudiera iniciar. Por lo tanto, el arranque no aproveché el procesamiento en paralelo que podria hacerse en mtiltiples procesadores. En segundo lugar, el apagado/reinicio fue visto como un acontecimiento relativamente raro y exactamente cuanto demoraban no era considerado importante. LFS201: Fundamentos de Administracién de Sistemas Linux 59THE LJ LINUX FOUNDATION 4.2 Alternativas de arranque Para lidiar con estas limitaciones intrinsecas en SysVinit, se han desarrollado nuevos métodos para controlar el arranque del sistema. Si bien es cierto que existen otros, dos esquemas principales fueron adoptados por distribuidores Empresariales: 1, Upstart fue desarrollado por Ubuntu y fue incluido por primera vez en el lanzamiento de la versién 6.10 en el 2006 y pas6 a ser utilizado por defecto en el lanzamiento de Ia versi6n 9.10, el 2009. También fue adoptado en Fedora 9(en el 2008) y en RHEL 6 y sus clones, tales como CentOS, Scientific Linux y Oracle Linux. En openSUSE fue oftecido como una opcién desde la versién 11.3, También se ha utilizado en varios dispositivos embebidos y méviles. 2, systemd es mas reciente y Fedora fue la primera distribucién de las principales. en adoptarlo en el 2011 RHEL 7 se basa en systemd y cada distribucién principal de Linux lo ha adoptado y usado por defecto, o ha anunciado planes para hacerlo. Los desarrolladores principales de systemd estan estrechamente vinculados a la comunidad del kernel de Linux. Incluso Ubuntu ha programado el retiro de Upstart en su favor. La migracién a los nuevos esquemas puede ser complicada debido a que los errores de software y funciones faltantes pueden ser muy incapacitantes, de hecho han habido capas que requieren compatibilidad esencial. Por 10 tanto, los métodos y Utilidades SysVinit persistiran por mucho tiempo aunque bajo el caps, las cosas son muy diferentes. La historia de las controversias y todo esto es muy complicado, y personalidades interesantes han asegurado no que toda la discusién es de caracter técnico. En nuestro contexto no veremos a través de esta lente. En adelante vamos a concentrarnos en SysVinit y systemd con una breve seccién sobre Upstart (aunque RHEL 6y algunas otras distribuciones. han estado usando Upstart, éste ha sido completamente oculto detras de una capa de compatibilidad usando las utilidades SysVinit normales) 4.3 Niveles de ejecucién de SysVinit Un sistema SysVinit inicia a través de una secuencia de ‘runlevels’ (niveles de ejecucién) que definen diferentes estados del sistema; estin numerados del 0 al 6. El runlevel 0 esté reservado para el apagado del sistema, runlevel 1 para el modo monousuario y runlevel 6 para reiniciar el sistema. Los otros runlevels se usan para definir qué servicios estén ejecutandose en un sistema normal; segtin el caso, las distribuciones definen algo de forma diferente, Por ejemplo, en sistemas basados en Red Hat, runlevel 2 se define como un sistema en funcionamiento sin red o X, runlevel 3 incluye soporte de red, y runlevel 5 incluye red y X. LFS201: Fundamentos de Administracién de Sistemas Linux 60