Cómo configurar un servicio de Linux para que se inicie automáticamente después de un reinicio o una caída del sistema: Parte 2 (Explicaciones teóricas)

En esta segunda entrega del tutorial de dos partes sobre la configuración de servicios de Linux para que se inicien automáticamente después de un reinicio o una caída del sistema, discutiremos el sistema init en detalle. Puede consultar la Parte 1 de la serie: Cómo configurar un servicio de Linux para que se inicie automáticamente después de un reinicio o una caída del sistema: Ejemplos prácticos aquí.

El presente tutorial será muy teórico. Por lo tanto, debe usarlo como referencia para comprender mejor cómo funciona el sistema init en Linux. En la primera entrega de este tutorial, compartimos algunos fragmentos de código y scripts de inicio que el sistema init lee al arrancar. También utilizamos MySQL como ejemplo para aprender cómo habilitar y deshabilitar un servicio de Linux para que se inicie automáticamente después de una caída o un reinicio. Como aprendió en la primera entrega de este tutorial de dos partes, existen tres sistemas init utilizados en diferentes distribuciones de Linux: System V, Upstart y Systemd. Puede consultar la primera parte de este tutorial para comprender la distribución y versión configuradas para usar un sistema init en particular.

En este tutorial, explicaremos el código que utilizamos en la primera parte del tutorial. Detallaremos los comandos y los archivos de configuración que utiliza el sistema init. ¡Comencemos!

Requisitos previos

En la conclusión de la primera parte de este tutorial de dos partes, mencionamos que debe mantener en funcionamiento los tres servidores de prueba. Si los había eliminado, puede volver atrás y recrearlos. Esto le ayudará a seguir el tutorial. Los tres servidores de prueba que debe tener son:

• Ubuntu 9.04 y versiones anteriores, o Debian 6 x64 (lo usaremos para demostrar el sistema init System V)
• Ubuntu 14.04 x64 (lo usaremos para demostrar Upstart). Aquí tiene un tutorial sobre cómo configurar fácilmente su servidor Ubuntu.
• CentOS 7 x64 (lo usaremos para demostrar Systemd).

Debe tener un usuario con privilegios sudo en cada uno de los servidores que utilizará para ejecutar los comandos. Este tutorial sobre cómo configurar el archivo sudoers de Linux puede guiarle.

Nota:  Los comandos del tutorial interferirán con los servicios del sistema. Por lo tanto, no debe aplicarlos en un servidor de producción en vivo.

Niveles de ejecución

Un nivel de ejecución es un nivel operativo que describe el estado actual de un sistema Linux en relación con los servicios que están disponibles. El concepto se origina en el init de System V. Cuando el sistema Linux arranca, inicializa el núcleo (kernel), entra en un nivel de ejecución y ejecuta el script de inicio asociado con ese nivel de ejecución. Solo puede ejecutar un nivel de ejecución al arrancar.

Otros ejemplos de niveles de ejecución incluyen el estado de apagado, el modo de reinicio, un modo de usuario único, etc. Cada nivel determina qué servicios ejecutar en ese estado. Algunos servicios pueden ejecutarse en más de un nivel, mientras que otros no.

Hay siete niveles de ejecución: del 0 al 6. A continuación se presenta una definición de los siete niveles de ejecución:

• Nivel de ejecución 0: Apagado del sistema
• Nivel de ejecución 1: Modo de usuario único y de rescate
• Niveles de ejecución 2, 3, 4: Modo multiusuario y de texto con red habilitada
• Nivel de ejecución 5: Modo multiusuario, con red habilitada y gráfico
• Nivel de ejecución 6: Reinicio del sistema

Los niveles de ejecución no se ejecutan necesariamente de forma secuencial. Los niveles de ejecución 2, 3 y 4 varían según la distribución de Linux que esté ejecutando. Puede implementar el nivel de ejecución 4 en algunas distribuciones y en otras no. Cuando habilitó un servicio para que se iniciara automáticamente, como se explicó en la primera parte, en realidad lo agregó a un nivel de ejecución. En System V, el sistema operativo se inicia con un nivel de ejecución particular y, durante el arranque, intenta iniciar todos los servicios asociados con ese nivel de ejecución. Los niveles de ejecución son objetivos (targets) en Systemd, los cuales discutiremos en la sección de Systemd.

Init y PID 1

El sistema init es el primerísimo proceso que se ejecuta cuando un sistema Linux arranca y el Kernel se carga en la memoria. Realiza varias tareas, incluyendo determinar cómo se cargará un proceso de usuario o un servicio del sistema, en qué orden y si debe iniciarse automáticamente. En cada distribución de Linux, cada proceso se identifica mediante un ID de proceso (PID) e init tiene un PID de 1. Es el padre de todos los demás procesos que se inician sucesivamente a medida que el sistema arranca.

Historia de init

El sistema init que se encuentra en las distribuciones de Linux recientes es una mejora del original. Las primeras versiones de las distribuciones de Linux utilizaban System V init, que se usaba de manera similar en sistemas Unix. A medida que Linux evolucionó, se implementó el demonio de init Upstart, el cual fue creado por Ubuntu. Ahora, (en el momento de escribir este tutorial, 2021) tenemos el demonio de init Systemd, que fue implementado por primera vez por Fedora. A medida que los sistemas Linux continúan evolucionando, es posible que surja un sistema init más nuevo. Para este tutorial, analizaremos estos tres: System V, Upstart y Systemd.

Las versiones recientes de Linux vienen con el sistema init Systemd por defecto. Sin embargo, han mantenido los otros sistemas init más antiguos para compatibilidad con versiones anteriores. Existen diferentes implementaciones de System V que se pueden utilizar en otras variantes de Linux. Por ejemplo, FreeBSD, una variante de UNIX, utiliza BSD init. Las versiones anteriores de Debian utilizan SysVinit. Ambos provienen de System V.

La forma en que cada versión del demonio init gestiona los servicios es diferente. Las mejoras añadidas en cada versión se orientaron hacia una herramienta robusta de gestión de servicios que pudiera manejar todo lo que un sistema Linux necesita, desde servicios, dispositivos, puertos y otros recursos. Había necesidad de un sistema potente que pudiera cargar recursos en paralelo y que pudiera recuperarse elegantemente de una caída del sistema.

Secuencia de init de System V

System V utiliza un archivo inittab para contener las instrucciones de inicialización. Upstart conserva el archivo inittab para compatibilidad con versiones anteriores. Aquí está el flujo de inicio de System V:

• El sistema init proviene del archivo binario /sbin/init.
• Una vez que el sistema init se carga en la memoria, lee su primer archivo en /etc/inittab.
• Una de las entradas de este archivo determina el nivel de ejecución (runlevel) en el que debe arrancar la máquina. Por ejemplo, si el valor del nivel de ejecución se especifica como 5, Linux arrancará en modo multiusuario y gráfico con la red habilitada (común en distribuciones diseñadas para uso de escritorio). El nivel de ejecución especificado aquí se conoce como el nivel de ejecución por defecto porque es el que siempre se utilizará.
• Luego, el sistema init busca más a fondo en el /etc/inittab y lee qué scripts de init necesita ejecutar para ese nivel de ejecución.

Al encontrar qué scripts ejecutar para un nivel de ejecución determinado, el sistema init encontrará qué servicios necesita iniciar. En estos scripts de init es donde normalmente se configura el comportamiento de inicio para servicios individuales, de la misma manera que configuramos el servicio MySQL en la primera parte de este tutorial.

Estructura de los scripts de init de System V

En esta sección, veremos los scripts de init en detalle. Los archivos de configuración o scripts de init de System V son los que controlan los servicios. Los scripts de init inicializan un servicio, de ahí el nombre de script de init.

Cada servicio tiene su propio script de init. Por ejemplo, el script de init de MySQL controla el servidor MySQL. Los proveedores de aplicaciones proporcionan los scripts de init para su aplicación particular, mientras que los servicios nativos de Linux vienen con la instalación del sistema operativo. Cuando crea una aplicación personalizada, también puede crear sus propios scripts de init personalizados para ella.

Para iniciar un servicio como el servidor MySQL, su programa binario se carga primero en la memoria. Dependiendo de su configuración, el programa puede seguir ejecutándose en segundo plano para continuar aceptando conexiones de clientes. El script de init del servicio se encarga de iniciar, detener o recargar la aplicación binaria. Los scripts de init en System V son scripts de shell. Otro nombre para ellos es scripts rc (run command).

Estructura de directorios de System V

El directorio padre para los scripts de init es el directorio /etc. El directorio /etc/init.d es el directorio real para los scripts de shell de init. Los scripts están enlazados simbólicamente a los directorios rc.

Hay varios directorios rc dentro del directorio /etc, cada uno con un número en su nombre. Los números representan diferentes niveles de ejecución. Si enumera el contenido del directorio, verá nombres como /etc/rc0.d, /etc/rc1.d, /etc/rc2.d, etc.

Si ve el contenido de cada uno de los directorios rc, verá archivos que comienzan con K o S en su nombre de archivo, seguidos de dos dígitos. Estos archivos contienen enlaces simbólicos que apuntan de nuevo a los scripts de shell de inicio reales del programa real. Las letras K y S son abreviaturas: K significa Kill o Stop, mientras que S significa Start. Los dos dígitos en los nombres de archivo representan el orden de ejecución. Si ve un archivo llamado K05script_name, se ejecutará antes que un archivo llamado K09script_name.

Inicio

Avanzando con la secuencia de inicio, veamos cómo se llaman los scripts de inicio.

Los scripts S y K no son llamados directamente por el sistema init. Más bien, son llamados por otro script: el /etc/init.d/rc script. El archivo /etc/inittab indica al demonio init en qué nivel de ejecución (runlevel) debe arrancar el sistema por defecto. Dependiendo del nivel de ejecución especificado, una línea en el archivo /etc/inittab llama al script /etc/init.d/rc, pasando el nivel de ejecución por defecto como parámetro. Usando este parámetro, el script llamará a los archivos bajo el correspondiente /etc/rcN.d, donde N denota el nivel de ejecución. Por ejemplo, si el servidor arranca con el nivel de ejecución 5, se llamará a los archivos correspondientes bajo el directorio /etc/rc5.d.

Dentro del directorio rc, todos los scripts K se ejecutan numéricamente con un argumento de stop, mientras que todos los scripts S se ejecutan de manera similar con un argumento de start. Se llamará a los scripts de shell de inicio reales correspondientes para el programa al que apuntan los enlaces simbólicos bajo /etc/rcN.d con los parámetros stop y start respectivamente.

En pocas palabras, lo que sucede cada vez que un sistema Linux entra o cambia a un determinado nivel de ejecución es que se ejecutarán ciertos scripts para detener algunos servicios, mientras que otros se ejecutarán para iniciar otros servicios. Este proceso garantiza que cualquier proceso que no deba ejecutarse en un estado de Linux determinado se detenga, y cualquier proceso que deba ejecutarse se inicie automáticamente.

Inicio automático de System V

Cuando habilita un servicio para que se inicie automáticamente al arrancar, está modificando directamente el comportamiento de init. Por ejemplo, si configura un servicio para que se inicie automáticamente en el nivel de ejecución 2, el proceso init crea los enlaces simbólicos apropiados en el directorio /etc/rc2.d. Para ayudarle a entenderlo, lo explicaremos con un ejemplo.

Ejemplo de System V

Para darle un ejemplo práctico, utilizaremos la configuración del servicio MySQL de la parte 1. Por lo tanto, inicie sesión en el VPS Debian 6 con su usuario sudo/root usando ssh (o putty si está en Windows), y continúe con los siguientes pasos.

Paso 1: Abrir y examinar el archivo inittab

Primero, introduzca el siguiente comando para ver el contenido del archivo inittab en la terminal:

El contenido del archivo debería ser algo como esto:

El número 2 denota el nivel de ejecución con el que se inicia el sistema. En este caso, el nivel de ejecución 2 es el predeterminado, por lo tanto, este sistema Debian se iniciará en el nivel de ejecución 2 como multiusuario, modo texto. Puede ejecutar el siguiente comando para confirmarlo:

Mostrará una salida similar a:

Paso 2: Examinar los directorios rc

A continuación, para listar los directorios rc, ejecute el siguiente comando:

Aquí hay una captura de pantalla de la salida:

Como vimos anteriormente en el archivo inittab, el sistema está configurado para arrancar en el nivel de ejecución 2, por lo tanto, los scripts bajo /etc/rc2.d se ejecutarán al iniciar el sistema. Puede listar el contenido de este directorio usando el comando:

Como puede ver en la salida, los archivos son solo enlaces simbólicos que apuntan a los archivos de script reales bajo /etc/init.d. Aquí hay un fragmento de la salida:

No hay scripts K en este directorio, solo scripts S (start). Los scripts iniciarán los servicios enlazados aquí, como rsync. También puede notar el servicio mysql listado, el cual discutiremos en el siguiente subtema.

Paso 3: Examinar el script de inicio

Cuando se instala un servicio que es compatible con System V, este crea un script de shell en el directorio /etc/init.d. Puede comprobar la disponibilidad del script de shell de MySQL introduciendo el siguiente comando:

Muestra la siguiente salida:

El archivo es bastante grande. Puede introducir el siguiente comando para ver su contenido:

Paso 4: Uso de chkconfig o sysv-rc-conf

Chkconfig es un comando que puede utilizar en distribuciones basadas en RHEL como CentOS para habilitar o deshabilitar servicios compatibles con System V. También puede usarlo para listar los servicios instalados y sus respectivos niveles de ejecución. Aquí está el comando para ello (funciona en CentOS):

En las distribuciones de Debian, tal utilidad no existe de forma nativa. El update-rc.d en los sistemas Debian solo instala y elimina servicios de los niveles de ejecución. Hay disponible una herramienta personalizada que puede utilizar para llevar la funcionalidad de chkconfig a los sistemas Debian. Introduzca el siguiente comando para instalarla:

Una vez instalada, puede ejecutar el siguiente comando para ver los comportamientos de los niveles de ejecución para varios servicios:

La salida de este comando tiene el formato de una tabla que muestra el nombre del servicio a la izquierda y el nivel de ejecución bajo el cual se ejecuta el servicio:

La X indica el nivel de ejecución bajo el cual se ejecutará el servicio. Esta herramienta le permite deshabilitar o habilitar un servicio para un nivel de ejecución utilizando las teclas de flecha y la barra espaciadora. Para salir de la herramienta, presione Q.

Paso 5: Probar el comportamiento de inicio de MySQL durante el arranque del sistema

En la captura de pantalla anterior, puede ver que el servicio mysql está habilitado en los niveles de ejecución 2,3,4,5. Puede deshabilitar MySQL utilizando el siguiente comando:

La salida se ve así. Observe que el servicio se ha detenido para todos los niveles de ejecución:

Ejecute el comando a continuación para ver el contenido del directorio:

Vea la línea de mysql en la salida a continuación:

La salida muestra que el enlace simbólico ha cambiado a K, lo que significa Kill (detener). Por lo tanto, MySQL no se iniciará automáticamente de forma predeterminada en el nivel de ejecución 2. Siempre que habilite o deshabilite un servicio en System V, esto es lo que sucede. Mientras haya un script S (inicio) en el directorio del nivel de ejecución predeterminado para un servicio, el demonio init iniciará ese servicio durante el arranque del sistema.

Para habilitar el servicio nuevamente, introduzca el siguiente comando:

Paso 6: Probar el comportamiento de inicio de MySQL después de una caída del sistema

En esta sección, analizaremos cómo maneja System V las caídas de servicios. Puede utilizar este conocimiento para configurar el comportamiento de sus servicios personalizados después de una caída.

En la primera parte de este tutorial, realizamos un cambio en el archivo /etc/inittab para permitir que MySQL se iniciara automáticamente después de una caída. Añadimos la siguiente línea para habilitar este comportamiento:

Podemos comprobar este comportamiento realizando algunas pruebas. Primero, reinicie su VPS introduciendo el siguiente comando:

Después del reinicio, compruebe con qué ID de proceso se están ejecutando mysql_safe y mysqld, introduzca el siguiente comando para obtener los ID de proceso:

La salida que obtuvimos fue:

Tome nota de los ID de proceso. En nuestro caso, fueron 1836 y 186338. Ahora, simule una caída matando el proceso con la opción -9 ingresando el siguiente comando. Recuerde sustituirlos con sus ID de proceso:

Después de unos minutos, verifique el estado de MySQL ejecutando el siguiente comando:

La salida indica que MySQL se está ejecutando, lo que significa que se volvió a generar después de la caída simulada. Si ejecuta el comando ps -ef | grep mysql de nuevo, encontrará que tanto los procesos mysqld_safe como mysqld se están ejecutando, aunque con nuevos ID.

Puede intentar matar los procesos varias veces y se volverán a generar después de unos minutos. Este comportamiento es posible gracias a la línea que agregamos al archivo /etc/inittab. Así es como se configuran los servicios para que se reinicien automáticamente después de una caída en System V. Para ver la sintaxis de nuevo, eche un vistazo a la Parte 1 de este tutorial.

Algunos servicios personalizados pueden tener errores y no volver a generarse después de múltiples intentos. El demonio init intentará volver a generar un servicio, pero si falla más de diez veces en dos minutos, el sistema Linux deshabilita el servicio por hasta 5 minutos. Esto ayuda a mantener el sistema estable y garantiza que no se desperdicien recursos del sistema en servicios que fallan. Es una buena idea revisar los registros del sistema para identificar problemas con sus aplicaciones personalizadas que deban corregirse.

Introducción a Upstart

El sistema de inicio System V ha sido crucial para las distribuciones de Linux durante mucho tiempo. Sin embargo, como ocurre con la tecnología, sigue avanzando. El ecosistema de Linux creció enormemente gracias al apoyo de la comunidad de código abierto. System V carga trabajos y servicios de manera serializada, lo que aporta complejidad y consume tiempo. Además, la introducción de medios de almacenamiento extraíbles modernos para los cuales System V no había sido diseñado impulsó la necesidad de un sistema de inicio diferente.

Los desarrolladores de Ubuntu comenzaron a trabajar en otro sistema de inicialización. Este sistema de inicio fue diseñado para manejar una carga más rápida del sistema operativo, garantizar una limpieza ordenada de los servicios caídos, mantener predecible la dependencia entre los servicios del sistema y tener en cuenta los medios de almacenamiento extraíbles. Así nació el demonio Upstart.

El inicio de Upstart tiene varias ventajas sobre el inicio de System V de las siguientes maneras:

• Upstart no carga los servicios de forma serializada como System V, lo que reduce el tiempo de arranque del sistema.
• Está diseñado para manejar mejor los servicios caídos con una limpieza ordenada y la regeneración del servicio.
• Upstart utiliza un sistema de eventos flexible para personalizar el manejo de servicios en varios estados.
• El inicio evita los complejos scripts de shell para cargar y administrar servicios como en System V. Upstart utiliza archivos de configuración simples que son fáciles de entender y modificar.
• Upstart se creó teniendo en cuenta la compatibilidad con versiones anteriores. El script /etc/init.d/rc todavía se ejecuta para administrar los servicios nativos de System V.
• Evita mantener enlaces simbólicos redundantes, todos apuntando al mismo script.

Eventos de Upstart

Upstart se basa en eventos, lo que permite asociar múltiples eventos con el mismo servicio. Esta arquitectura basada en eventos garantiza una gestión de servicios flexible. Cada evento puede llamar a un script de shell específico para el evento.

Los eventos de Upstart incluyen:

• Starting
• Started
• Stopping
• Stopped

Entre un evento y otro, un servicio puede estar en varios estados, incluidos, entre otros:

• Waiting
• Pre-start
• Starting
• Post-start
• Running
• Pre-stop
• Stopping
• Post-stop

El inicio de Upstart se puede configurar para tomar acciones en cada uno de estos estados, de ahí su diseño flexible.

Secuencia de inicio de Upstart Init

El inicio de Upstart ejecuta el script /etc/init.d/rc al arrancar, al igual que System V. Este script ejecuta cualquier script de inicio de System V normalmente para garantizar la compatibilidad con versiones anteriores.

Los archivos de configuración de Upstart se encuentran en el directorio /etc/init por lo que busca allí de forma predeterminada y ejecuta los comandos de shell que se encuentran en los archivos de configuración de este directorio.

Archivos de configuración de Upstart

El init de Upstart utiliza archivos de configuración de servicios para controlar los servicios, a diferencia de los scripts de bash utilizados en System V. El estándar de nomenclatura para estos archivos de configuración de servicios es nombre_servicio.conf.

Los archivos contienen contenido de texto plano dividido en varias secciones llamadas stanzas. Cada stanza describe un estado diferente de un servicio y su comportamiento. Diferentes stanzas controlan diferentes eventos de un servicio. Por ejemplo, waiting, pre-start, start, pre-stop, stopping, etc.

Una stanza contiene comandos de shell, lo que hace posible iniciar varias acciones para cada evento de cada servicio. Además, cada archivo de configuración de servicio especifica las siguientes dos cosas:

• En qué niveles de ejecución (runlevels) debe iniciarse y detenerse el servicio.
• Si el servicio debe reiniciarse (respawn) si se cae.

Estructura de directorios de Upstart

Los archivos de configuración de servicios de Upstart se encuentran bajo el directorio /etc/init . No confunda esto con /etc/init.d.

Ejemplo de Upstart

En este ejemplo, veremos cómo maneja Upstart un servicio durante el arranque del sistema y en caso de una caída. Entraremos en más detalles explicando los ejemplos prácticos mostrados en la primera parte de este tutorial.

Paso 1: Iniciar sesión en el servidor Ubuntu 14.0.4

Primero, para probar Upstart, utilizaremos el segundo VPS, el que ejecuta Ubuntu 14.0.4. Esto se debe a que esta distribución de Linux implementa Upstart de forma nativa. Utilice ssh o putty si está en Windows. Debe iniciar sesión con un usuario con privilegios de root o sudo. Tengo un usuario llamado hackins, así que así es como iniciaría sesión:

Reemplace con su usuario root/sudo y la dirección IP pública del servidor. Luego, presione enter y proporcione una contraseña o frase de contraseña.

Paso 2: Examinar los directorios init y rc

Los archivos de configuración de Upstart se almacenan en el directorio /etc/init. Es el directorio que utilizará al crear nuevos archivos de configuración de servicios.

Para listar los nombres de los archivos de configuración en el directorio /etc/init, ejecute el siguiente comando:

Como verá en la salida del comando anterior, muchos servicios se están ejecutando bajo Upstart. Presione Q para salir de less.

Si ejecuta lo siguiente para listar los archivos de configuración de servicios para System V en el directorio rc, solo verá unos pocos:

Paso 3: Examinar un archivo de Upstart

En la primera entrega de este tutorial, habíamos utilizado un archivo mysql.conf para aprender sobre la configuración del servidor. Para ampliar nuestros conocimientos, utilicemos una configuración diferente. El archivo de configuración de cron es un buen candidato. Ingrese el siguiente comando para abrir el archivo:

Debería obtener una salida similar a la captura de pantalla de abajo:

El script es bastante sencillo. Tome nota de los siguientes campos importantes: start on, stop on, fork, y respawn. Definamos qué hacen estas directivas:

• start on indica a Ubuntu que inicie el cron demonio cuando el sistema entra en los niveles de ejecución 2, 3, 4 o 5. No se ejecutará en los otros niveles de ejecución no especificados aquí, es decir, 0, 1 o 6.
• stop on indica a Ubuntu que detenga un demonio en ejecución. Sin embargo, en este caso, hay un signo de exclamación (!) que es un signo de negación. El script no debe detenerse en los niveles de ejecución después del signo de exclamación: 2,3,4,5.
• fork directiva indica a Upstart que desvincule el proceso de la consola y lo mantenga ejecutándose en segundo plano.
• respawn directiva indica al sistema que inicie cron automáticamente si se cae por cualquier motivo.

Presione Ctrl X para salir del editor sin escribir nada.

Otros archivos de configuración de Upstart siguen la misma estructura, con stanzas para start, stop y respawn. Algunos archivos de configuración pueden tener bloques de script adicionales para pre-start, pre-stop, post-start y más. Estos bloques de código le dicen al sistema qué ejecutar cuando un proceso se encuentra en cualquiera de los estados definidos.

Paso 4: Probar el comportamiento de inicio del servicio MySQL después de que el sistema arranque

De forma predeterminada, MySQL está configurado para iniciarse automáticamente después de que el sistema se inicie. Intentaremos desactivarlo y ver el comportamiento. En Upstart, un servicio se puede desactivar creando un archivo llamado service_name.override bajo el directorio /etc/init/. El contenido del archivo es solo una palabra: manual.

Veamos cómo podemos usar este comando para desactivar el servicio MySQL. Introduce el siguiente comando para abrir el archivo con el editor nano:

En el archivo abierto añade la siguiente línea:

Guarda los cambios presionando Ctrl + O, luego enter. Sal del editor presionando Ctrl + X. Ejecuta el siguiente comando para reiniciar el servidor:

Espera unos minutos y luego vuelve a iniciar sesión. Una vez que hayas iniciado sesión de nuevo, prueba el estado del servicio MySQL introduciendo el siguiente comando:

La salida indicará que el servicio no se está ejecutando:

Esto indica que MySQL no se inició automáticamente después del arranque del sistema. A continuación, abre el archivo de configuración de MySQL y comprueba si la directiva start ha cambiado:

La salida indicará que no se cambió nada:

Esto significa que si tu servicio no se inicia automáticamente y solo compruebas el archivo de configuración del servicio (service_name.conf), es posible que no encuentres el error. También deberías comprobar la existencia del archivo service_name.override en el directorio.

Introduce el siguiente comando para eliminar el archivo override y volver a habilitar el servicio MySQL. Luego, reinicia el servidor:

Una vez que el servidor se haya iniciado, prueba el estado del servicio MySQL de nuevo:

Debería mostrar que el servicio MySQL se inició automáticamente.

Paso 5: Probar el comportamiento de inicio del servicio MySQL después de una caída del sistema

De forma predeterminada, el servicio MySQL se reinicia automáticamente si se cae. Para detener este comportamiento, editaremos el archivo mysql.conf. Introduce el siguiente comando para abrir el archivo con el editor nano:

Busca las líneas de la directiva respawn y coméntalas como se muestra a continuación con #:

Ejecuta los siguientes comandos para reiniciar el servicio:

Usamos los comandos anteriores para detener e iniciar el servicio porque usar initctl restart o initctl reload no funcionaría aquí. Cuando ejecutes el comando para iniciar el servicio MySQL, la salida mostrará un PID para MySQL como:

Nuestro PID fue 1439. A continuación, anota lo que obtuviste cuando ejecutaste el comando, lo usaremos en el siguiente paso. Para simular una caída, mata el proceso de MySQL usando el siguiente comando, recuerda reemplazar tu PID como se explicó anteriormente:

Para comprobar si MySQL se reinició después de la caída, espera unos minutos y luego introduce el siguiente comando:

La salida indicará que MySQL está detenido:

Intenta comprobar el estado unas cuantas veces más para ver si hay algún cambio. Notarás que MySQL permanece detenido. Esto se debe a que el archivo de configuración del servicio no tiene las directivas respawn (las que comentamos). Consulta la parte 1 de este tutorial para obtener más explicaciones sobre la directiva respawn.

¿Por qué le mostramos cómo deshabilitar el reinicio automático de los servicios después del arranque o fallo del sistema? Esto es principalmente para fines de resolución de problemas. Si, por ejemplo, su servicio se inicia y sigue fallando, es posible que desee deshabilitarlo para poder solucionar el problema y también mantener su sistema estable. También puede evitar que algunas configuraciones de servicios antiguos se reinicien automáticamente si actualiza a una nueva distribución de Linux que viene de forma nativa con systemd analizado en la siguiente sección.

Introducción a Systemd

Systemd es el sistema de inicio más reciente, que se encuentra en las distribuciones de Linux más recientes. Incluye muchos componentes que componen un sistema Linux moderno.

Systemd no solo administra los servicios sino también todo el sistema Linux. En esta sección, nos centraremos en cómo systemd controla el comportamiento de los servicios después de un arranque o fallo del sistema.

Systemd es compatible con versiones anteriores de los scripts y comandos de inicio de System V. Por lo tanto, si tiene algún servicio configurado con System V, también se ejecutará bajo Systemd. La mayoría de los comandos administrativos de Upstart y System V se han modificado para funcionar con Systemd. Systemd se renombra a sí mismo como init en el momento del arranque. Existe un archivo /sbin/init que enlaza simbólicamente a /bin/systemd.

Archivos de configuración de Systemd: Archivos de unidad

La configuración de Systemd consta de archivos de unidad. Cada archivo de unidad representa un recurso del sistema. Mientras que los otros dos sistemas de inicio (es decir, System V y Upstart) eran responsables de administrar los servicios de un sistema Linux, Systemd no solo administra los demonios de servicio, sino también otros tipos de recursos del sistema, como rutas del sistema operativo de dispositivos, sockets, puntos de montaje, etc. Los archivos de unidad almacenan información sobre el recurso.

Cada archivo de unidad representa un recurso del sistema en particular con un estilo de nomenclatura de service_name.unit_type. Esto significa que encontrará archivos como home.mount, dbus.service, sshd.socket, etc. Los archivos de unidad son archivos de texto simples con una sintaxis declarativa que es fácil de entender y modificar.

Estructura de directorios

La ubicación principal de los archivos de unidad nativos es el directorio /lib/systemd/system/. Los archivos de unidad que cree o los creados de forma personalizada por los administradores del sistema, y otros archivos de unidad nativos modificados se almacenan en el directorio /etc/systemd/system.

Si existe un archivo de unidad con el mismo nombre tanto en el directorio /lib/systemd/system/ como en /etc/systemd/system, systemd utilizará el que se encuentra bajo el directorio /etc.

Cuando habilita un servicio para que se inicie en el momento del arranque o en cualquier otro target/runlevel, se crea un enlace simbólico para ese archivo de unidad de servicio bajo los directorios correspondientes en /etc/systemd/system. Los archivos de unidad en el directorio /etc/systemd/system son solo enlaces simbólicos a los archivos con un nombre similar en el directorio /lib/systemd/system.

Secuencia de inicio de Systemd: Unidades Target

Las unidades target son tipos únicos de archivos de unidad que generalmente tienen el sufijo .target. Las unidades target difieren de otros tipos de archivos de unidad porque no representan un recurso en particular. En su lugar, representan el estado de todo el sistema en un momento dado.

Para lograr esto, las unidades target agrupan e inician múltiples archivos de unidad que forman parte de un estado particular. Aunque los targets de Systemd y los runlevels de System V se pueden comparar vagamente, no son lo mismo. Un archivo de unidad target tiene un nombre en lugar de un número. Por ejemplo, encontrará algo como multi-user.target en lugar de runlevel 3 o reboot.target en lugar de runlevel 6. Un sistema Linux puede arrancar con multi-user.target. En este caso, básicamente está llevando al servidor al runlevel 2, 3 o 4, lo que inicia el sistema en modo de texto multiusuario con la red habilitada.

La diferencia radica en cómo lleva al servidor a ese nivel. System V inicia los servicios de forma secuencial. Por otro lado, a medida que el sistema se arranca, systemd comprueba si existen otros servicios o recursos y determina su orden de carga.

Otra diferencia entre las unidades target de systemd y los niveles de ejecución de System V es que una distribución de Linux que utiliza System V existirá en un solo nivel de ejecución. Si modifica el nivel de ejecución, simplemente cambiará y existirá en ese nuevo nivel de ejecución. Por otro lado, los archivos de unidad target pueden ser inclusivos.  Además, la activación de una unidad target garantiza que otras unidades target se carguen como parte de ella. Por ejemplo, si inicia un sistema Linux con una interfaz gráfica de usuario, tendrá el graphical.target activado. Esto, a su vez, garantiza automáticamente que multi-user.target también se cargue y se active.

Aquí hay una tabla que compara los niveles de ejecución y los targets.

Nivel de ejecución (System V)	Unidades Target (systemd)
nivel de ejecución 0	poweroff.target
nivel de ejecución 1	rescue.target
nivel de ejecución 2,3,4	multi-user.target
nivel de ejecución 5	graphical.target
nivel de ejecución 6	reboot.target

default.target de Systemd

En systemd, default.target es el equivalente al nivel de ejecución predeterminado en System V. Vimos que el nivel de ejecución predeterminado en System V se definía en el archivo inittab. En systemd, tenemos el archivo default.target. El archivo target predeterminado se almacena en el directorio /etc/systemd/system. Este crea un enlace simbólico a uno de los archivos de unidad target en /lib/systemd/system. Cambiar el target predeterminado simplemente significa recrear un enlace simbólico y modificar el nivel de ejecución del sistema.

En System V, el inittab especificaba en qué directorio encontraría Linux los scripts de init. Este podría ser cualquiera de los directorios rc como se explicó anteriormente. Por otro lado, el target predeterminado de systemd determina las unidades de recursos que se cargarán en el momento del arranque. Se cargan todas las unidades definidas. Sin embargo, no todas se cargan en paralelo, y no todas se cargan secuencialmente. La carga de la unidad de recurso depende de los otros recursos que esta quiere o requiere.

Dependencias de Systemd: Wants y Requires

En esta sección, analizaremos cómo Systemd maneja las dependencias. Vimos que con Upstart, la carga paralela de servicios es posible cuando se utilizan archivos de configuración. También analizamos cómo System V utiliza los niveles de ejecución para determinar qué servicio iniciar automáticamente o esperar hasta que se inicie otro servicio o recurso. De manera similar, los servicios de Systemd se pueden configurar para cargarse en uno o más targets, o esperar hasta que se inicie otro servicio o recurso.

En Systemd, un archivo de unidad que requiere otra unidad no se iniciará hasta que la unidad requerida se cargue y se active. Si la unidad requerida no se carga mientras la primera unidad está activa, la primera unidad se detendrá.

Este comportamiento garantiza la estabilidad del sistema. Un servicio que requiere que un recurso en particular (por ejemplo, un puerto) esté disponible y activo puede, por lo tanto, hacerse esperar hasta que el recurso esté disponible (es decir, que se abra el puerto).

Por el contrario, una unidad que quiere otra unidad no impone tales restricciones. No se detendrá si la unidad querida se detiene mientras la unidad que realiza la llamada sigue activa. Por ejemplo, algunos servicios no esenciales en el modo graphical-target.

Ejemplo de Systemd

Veamos cómo podemos configurar el comportamiento de un servicio bajo systemd.

Paso 1: Inicie sesión en su instancia de VPS

Utilizaremos MySQL como un servicio de la vida real y CentOS 7 como servidor. Para seguir los pasos de manera práctica y comprender los conceptos, inicie sesión en su VPS CentOS 7 o cree uno en CloudSigma.  Un VPS que ejecute la distribución CentOS 7, Debian 7 u 8, o Ubuntu 15 o posterior es adecuado para esta sección, ya que todos vienen con systemd. Inicie sesión con el comando ssh o, si está en Windows, use PuTTY:

Paso 2: Examine el archivo default.target y las dependencias

La secuencia de inicio de Systemd sigue una larga cadena de dependencias que analizaremos en detalle en esta sección.

• default.target

El archivo default.target controla los servicios que se inician durante un arranque normal. Puede listar el archivo de unidad target predeterminado utilizando el siguiente comando:

La salida muestra algo como la siguiente captura de pantalla:

La captura de pantalla muestra que el target predeterminado apunta mediante un enlace simbólico al archivo multi-user.target en el directorio /lib/systemd/system/ directorio. Esto significa que, por defecto, el sistema se iniciará bajo multi-user.target, equivalente a runlevel 3.

• multi-user.target.wants

Para ver todos los servicios que requiere el archivo multi-user.target, introduzca el siguiente comando:

La salida contiene muchas líneas, aquí hay un fragmento:

Como muestra la salida, son enlaces simbólicos que apuntan a los archivos de unidad reales en el /lib/systemd/system/ directorio. Hemos destacado mysqld.service para señalarle que también forma parte de multi-user.target. Si desea confirmar si un determinado servicio está configurado para el inicio, puede modificar el comando para ese archivo. Por ejemplo, podemos filtrar las salidas para buscar el demonio mysql o cron usando los siguientes comandos:

La salida mostrará:

Para filtrar el resultado para el demonio cron, introduzca el siguiente comando:

La salida mostrará:

Aparte de multi-user.target, existen otros tipos diferentes de targets, es decir, system-update.target o basic.target.

Introduzca el siguiente comando para ver de qué targets depende el target multi-user:

La salida muestra:

Esto significa que basic-target debe cargarse primero para que el sistema se inicie en modo multi-user.target.

• basic-target

Introduzca el siguiente comando para ver qué otros targets requiere basic.target:

El resultado mostrará:

• sysinit.target

Puede ejecutar el siguiente comando para ver si hay algún target requerido para sysinit.target. La sintaxis del comando es la misma. Puede seguir modificándolo para ver qué unidades de target son requeridas por otra unidad de target a medida que avanza. Aquí está el comando:

El resultado mostrará que no hay unidades requeridas para sysinit.target. Podemos comprobar si hay otros servicios y targets solicitados por sysinit.target usando el siguiente comando:

El resultado muestra una larga lista de servicios y targets solicitados por sysinit.target. A continuación puede ver parte del resultado:

Durante la inicialización del sistema con system4, el sistema no se queda en un solo target. En su lugar, carga los servicios de manera dependiente a medida que pasa de un target a otro.

Paso 3: Examinar un archivo de unidad

Veamos cómo es un archivo de unidad. Habíamos utilizado el archivo de unidad del servicio MySQL en la primera parte de este tutorial, y lo volveremos a utilizar. Sin embargo, también podemos mirar otro archivo de unidad de servicio: el archivo de unidad sshd. Introduzca el siguiente comando para abrir el archivo de configuración de sshd:

A continuación se muestra una captura de pantalla con las líneas del archivo:

Como puede ver, los bloques de código delineados en el archivo facilitan su comprensión y modificación cuando sea necesario. A continuación se presentan algunas directivas importantes que debe comprender:

• After – la cláusula After indica al sistema que solo cargue el servicio después de que se hayan cargado los targets y servicios especificados. En este caso, el servicio SSHD se cargará después de que se hayan cargado el target de red y el servicio keygen.
• Wants – la cláusula Wants muestra qué targets solicitan este servicio. En este caso, el ssh-keygen.service solicita el sshd.service. Sin embargo, si sshd falla o se cae, no detendrá el ssh-keygen.service.

Presione Ctrl + X para cerrar el editor.

Paso 4: Probar el comportamiento de inicio del servicio MySQL en el arranque del sistema

En esta sección, le mostraremos cómo puede cambiar y probar el comportamiento del servicio MySQL en el momento del arranque del sistema. En la sección anterior, vimos que el mysqld.service es solicitado por multi-user.target. Por lo tanto, se iniciará automáticamente al arrancar.

Puede deshabilitar el servicio ejecutando el siguiente comando:

Al ejecutar el comando se muestra que el enlace simbólico de mysql se elimina del directorio /etc/systemd/system/multi-user.target.wants/. Para probar esto, ejecute el siguiente comando para comprobar si MySQL sigue siendo solicitado por multi-user.target:

El comando no devuelve nada. Si intenta reiniciar el servidor y verificar el estado de MySQL, no se estará ejecutando, lo que significa que no se inició automáticamente al arrancar.

Ahora vuelva a habilitar el servicio usando el comando:

La salida mostrará un enlace simbólico. Si reinicia su servidor, MySQL debería iniciarse automáticamente. Habilitar un servicio de Systemd crea un enlace simbólico en el directorio wants del target predeterminado. Deshabilitar un servicio de Systemd elimina el enlace simbólico del directorio wants.

Paso 5: Probar el comportamiento de inicio del servicio MySQL después de una caída del servicio

Por defecto, el servicio MySQL se iniciará automáticamente en caso de que se caiga. Podemos deshabilitar este comportamiento en el archivo de configuración de Systemd para MySQL. Primero, echemos un vistazo al archivo. Ingrese el siguiente comando para abrir el archivo:

La siguiente captura de pantalla muestra la salida:

El valor de la directiva Restart está establecido en on-failure. Esto significa que el servicio MySQL se reiniciará después de códigos de salida no limpios, tiempos de espera agotados o señales no limpias. A continuación se muestra una tabla con algunos de los parámetros de reinicio de la página de manual.

Configuración de reinicio/Causas de salida	no	always	on-success	on-failure	on-abnormal	on-abort	on-watchdog
código de salida limpio o señal		X	X
Código de salida no limpio		X		X
Señal no limpia		X		X	X	X
Tiempo de espera agotado		X		X	X
Watchdog		X		X	X		X

Las dos directivas importantes en un archivo de unidad de Systemd son Restart y RestartSec. Controlan el comportamiento del servicio ante una caída. Restart especifica cuándo debe reiniciarse el servicio, y RestartSec especifica cuánto tiempo debe esperar antes de reiniciarse después de una caída. Para deshabilitar el comportamiento de reinicio, comente la directiva Restart agregando un # al principio de la línea como se muestra:

Ahora, recargue el demonio del sistema, luego recargue el servicio mysqld utilizando los siguientes comandos:

A continuación, ejecute el siguiente comando para encontrar el PID principal (Main PID) del servicio MySQL:

El PID principal para nuestra prueba fue 23809. Anote el suyo para usarlo en el siguiente comando. Usando el comando kill -9, simule una caída matando el proceso. Además, recuerde reemplazar con el número de proceso que obtuvo en su prueba:

Si ejecuta el comando que verifica el estado de MySQL, encontrará que no está activo y que no ha podido reiniciarse:

Permanecerá en estado fallido mientras la directiva Restart esté comentada en el archivo de configuración de mysqld.service. Esto emula una caída donde un servicio se detiene y no vuelve a levantarse.

Para volver a habilitar el servicio, puede editar el archivo de configuración de mysqld.service, descomentar la directiva Restart, luego guardar y cerrar. Como hizo anteriormente, recargue el demonio y reinicie el servicio. Esto devuelve el servicio a su configuración inicial, y ahora puede iniciarse automáticamente después de una caída. Finalmente, eso es todo para configurar un servicio para que se inicie automáticamente después de una caída. Si desea configurar servicios para que se inicien automáticamente después de una caída, simplemente necesita agregar la directiva Restart (y si lo desea, también puede agregar la directiva RestartSec), bajo la sección [Service] del archivo de unidad del servicio.

Conclusión

En este tutorial, hemos analizado cómo maneja Linux los servicios durante el inicio o después de una caída. Para comprender el proceso de inicialización del sistema Linux, analizamos los tres sistemas de inicio (init) que utiliza Linux: System V, Upstart y Systemd. Analizamos su evolución y cómo cada init proceso funciona en relación con el inicio automático de un servicio después de un reinicio del sistema o una caída.

Dado que tanto los demonios init como las distribuciones de Linux han ido evolucionando con el tiempo, recuerde comprobar la versión de la distribución de Linux que está ejecutando para saber qué demonio init admite su sistema de forma nativa.

Las aplicaciones nativas de Linux y la mayoría de las aplicaciones de terceros ya se inician automáticamente después de un arranque o caída del sistema, por lo que no tendrá que hacer nada. Los conocimientos de este tutorial son cruciales a la hora de configurar el comportamiento de inicio y reinicio (respawn) de sus propios servicios personalizados, o al solucionar problemas de servicios que fallan constantemente.

¡Feliz computación!