Cómo usar systemd como herramienta de solución de problemas

Si bien systemd no es realmente una herramienta de solución de problemas, la información en su salida señala el camino hacia la resolución de problemas.

Nadie realmente consideraría systemd como una herramienta de solución de problemas. No obstante, cuando encontré un problema en mi servidor web, mi creciente conocimiento de systemd y algunas de sus características me ayudaron a localizar y sortear el problema.

El problema era en mi servidor. El servidor que proporciona servicios de nombres, DHCP, NTP, HTTPD y servicios de correo electrónico SendMail para la red de mi oficina en casa. Este no pudo iniciar el demonio Apache HTTPD durante el inicio normal.

Tuve que iniciarlo manualmente después de darme cuenta de que no se estaba ejecutando. El problema había estado sucediendo por algún tiempo, y recientemente tuve la oportunidad de tratar de solucionarlo.

Algunos de ustedes dirán que systemd es la causa de este problema y, en base a lo que sé ahora, estoy de acuerdo con ustedes. Sin embargo, tuve problemas similares con SystemV. Anteriormente, analicé la controversia en torno a systemd como un reemplazo para el antiguo programa de inicio de SystemV y los scripts de inicio.

Ningún software es perfecto, y ni systemd ni SystemV son una excepción. No obstante, systemd proporciona mucha más información para la resolución de problemas que la que ofrece SystemV.

Determinando el problema

El primer paso para encontrar el origen de este problema es determinar el estado del servicio httpd:

Esta información de estado es una de las características de systemd que encuentro mucho más útil que cualquier cosa que ofrece SystemV. La cantidad de información útil aquí me lleva fácilmente a una conclusión lógica que me lleva en la dirección correcta.

Todo lo que obtuve del antiguo comando chkconfig es si el servicio se está ejecutando y el ID de proceso (PID) si es así. Eso no es muy útil.

La entrada clave en este informe de estado muestra que HTTPD no puede vincularse a la dirección IP. Esto significa que no puede aceptar solicitudes entrantes. Indica que la red no se inicia lo suficientemente rápido como para estar lista para que el servicio HTTPD se una a la dirección IP. Esto porque la dirección IP aún no se ha configurado.

No se supone que esto suceda, así que exploré mis archivos de configuración de inicio de systemd de servicio de red. Todo parecía ser correcto con las declaraciones correctas “after” y “requires”. Aquí está el archivo /lib/systemd/system/httpd.service de mi servidor:

El archivo de unidad httpd.service especifica explícitamente que debe cargarse después de network.target y httpd-init.service  (entre otros).

Traté de encontrar todos estos servicios usando el comando systemctl list-units y buscándolos en el flujo de datos resultante. Todos estaban presentes y deberían haberse asegurado de que el servicio httpd no se cargara antes de configurar la dirección IP de la red.

Primera solución

Un poco de búsqueda en Internet confirmó que otros habían encontrado problemas similares con httpd y otros servicios. Esto parece suceder porque uno de los servicios requeridos le indica a systemd que ha finalizado su inicio. Sin embargo, en realidad deriva un proceso secundario que no ha finalizado. Después de un poco más de búsqueda, se me ocurrió una elusión.

No pude entender por qué la dirección IP tardaba tanto en asignarse a la tarjeta de interfaz de red. Entonces, pensé que, si podía retrasar el inicio del servicio HTTPD por un período de tiempo razonable, la dirección IP se asignaría en ese momento.

Afortunadamente, el archivo /lib/systemd/system/httpd.service anterior proporciona alguna dirección. Aunque dice no alterarlo, indica cómo proceder: debes usar el comando systemctl edit httpd, que crea automáticamente un nuevo archivo (/etc/systemd/system/httpd.service.d/override.conf) y abre el editor nano. (Si no estás familiarizado con Nano, asegúrate de observar las sugerencias en la parte inferior de la interfaz de Nano).

Debes agregar el siguiente texto al nuevo archivo y guárdalo:

La sección [Service] de este archivo de anulación contiene una sola línea que retrasa el inicio del servicio HTTPD en 30 segundos. El siguiente comando de estado muestra el estado del servicio durante el tiempo de espera:

Y este comando muestra el estado del servicio HTTPD después de que expire el retraso de 30 segundos. El servicio está funcionando correctamente:

Podría haber experimentado para ver si un retraso más corto también funcionaría, pero mi sistema no es tan crítico, así que decidí no hacerlo. Funciona de manera confiable como es, así que estoy feliz.

Como reuní toda esta información, lo informé a Red Hat Bugzilla como Bug. Creo que es mucho más productivo reportar errores que quejarse de ellos.

La mejor solución

Un par de días después de informar esto como un error, recibí una respuesta indicando que systemd es solo el administrador. Si httpd necesita ser ordenado después de cumplir algunos requisitos, debe expresarse en el archivo de la unidad.

La respuesta me indicó la página de manual httpd.service. Desearía haber encontrado esto antes porque es una solución mejor que la que se me ocurrió. Esta solución está dirigida explícitamente a la unidad objetivo de prerrequisito en lugar de un retraso algo aleatorio.

Desde la página de manual httpd.service :

Inicio del servicio en el momento del arranque

Las unidades httpd.service y httpd.socket están deshabilitadas de forma predeterminada. Para iniciar el servicio httpd en el momento del arranque debes ejecutar: systemctl enable httpd.service.

En la configuración predeterminada, el demonio httpd aceptará conexiones en el puerto 80 (y, si está instalado mod_ssl, conexiones TLS en el puerto 443). Esto para cualquier dirección IPv4 o IPv6 configurada.

Si httpd está configurado para depender de una dirección IP específica (por ejemplo, con una directiva “Listen”) que solo puede estar disponible durante el inicio. O también si httpd depende de otros servicios (como un demonio de base de datos), el servicio debe configurarse para garantizar el correcto inicio del pedido.

Por ejemplo, puedes garantizar que httpd solo se ejecute después de configurar todas las interfaces de red configuradas. Para esto debes crear un archivo desplegable (como se describe anteriormente) con la siguiente sección:

[Unit]
After=network-online.target
Wants=network-online.target

Todavía esto es un error porque es bastante común, al menos en mi experiencia, usar una directiva Listen en el archivo de configuración httpd.conf . Siempre he usado directivas Listen, incluso en hosts con una sola dirección IP. Es claramente necesario en hosts con múltiples tarjetas de interfaz de red (NIC) y direcciones de protocolo de Internet (IP).

Agregar las líneas anteriores al archivo predeterminado /usr/lib/systemd/system/httpd.service no causaría problemas para las configuraciones que no usan una directiva Listen. Esto evitaría el problema para aquellos que sí lo hacen.

Mientras tanto, usaré la solución sugerida.

Próximos pasos

Este artículo describe un problema que tuve al iniciar el servicio Apache HTTPD en mi servidor. Te guía a través de los pasos de determinación de problemas que tomé y muestra cómo usé systemd para ayudar. También cubrí la elusión que implementé usando systemd y la mejor solución que surgió de mi informe de error.

Como mencioné al principio, es muy probable que esto sea el resultado de un problema con systemd, específicamente la configuración para el inicio de httpd. Sin embargo, systemd me proporcionó las herramientas para localizar la fuente probable del problema y formular e implementar una elusión.

Ninguna de las soluciones realmente resuelve el problema a mi entera satisfacción. Por ahora, la causa raíz del problema aún existe y debe corregirse. Si eso es simplemente agregar las líneas recomendadas al archivo /usr/lib/systemd/system/httpd.service, eso funcionaría para mí.

Una de las cosas que descubrí durante este proceso es que necesito aprender más sobre cómo definir las secuencias en las que comienzan las cosas.

Recursos

Hay una gran cantidad de información sobre systemd disponible en Internet, pero mucha es breve, obtusa o incluso engañosa. Además de los recursos mencionados en este artículo, las siguientes páginas web ofrecen información más detallada y confiable sobre el inicio de systemd.

  • El Proyecto Fedora tiene una buena guía práctica para systemd. Tiene casi todo lo que necesitas saber para configurar, administrar y mantener una computadora Fedora usando systemd.
  • El Proyecto Fedora también tiene una buena hoja de trucos que hace referencias cruzadas de los viejos comandos de SystemV con otros sistemas comparables.
  • Para obtener información técnica detallada sobre systemd y las razones para crearlo, debes consultar la descripción de systemd en Freedesktop.org.

También hay una serie de artículos profundamente técnicos para administradores de sistemas de Linux de Lennart Poettering, el diseñador y desarrollador principal de systemd. Estos artículos fueron escritos entre abril de 2010 y septiembre de 2011, pero ahora son tan relevantes como lo fueron entonces.