systemctl envía solicitudes a un gestor systemd. Esta lección se centra en las unidades de servicio del sistema. Confirma el nombre exacto de la unidad, el ámbito del gestor, las dependencias y el impacto operativo antes de cambiar su estado.
Init · Lección 6
Objetivos de systemd
Aprende a inspeccionar, ajustar, validar, iniciar, habilitar y diagnosticar unidades de servicio de systemd.
Interpretar una unidad de servicio
Una unidad ilustrativa mínima puede tener este aspecto:
[Unit]
Description=Example worker
Wants=network-online.target
After=network-online.target
[Service]
Type=exec
ExecStart=/usr/local/bin/example-worker
Restart=on-failure
[Install]
WantedBy=multi-user.target
[Unit]contiene la descripción y las relaciones de dependencia.[Service]define el ciclo de vida del proceso y el comportamiento específico del servicio.[Install]indica a los comandos de habilitación qué alias o enlaces de dependencia deben crear; no constituye automáticamente una dependencia activa durante la ejecución.
De forma predeterminada, ExecStart= no se ejecuta mediante un shell. Las tuberías, redirecciones, variables y comillas del shell no se comportan como en una línea de comandos interactiva, salvo que se invoque deliberadamente un shell explícito.
¿Cuál es el propósito principal de las directivas de [Install], como WantedBy=?
Inspeccionar la configuración efectiva
Lista las unidades cargadas con:
$ systemctl list-units --type=service
Lista los archivos de unidad instalados y sus estados de habilitación con:
$ systemctl list-unit-files --type=service
Son perspectivas distintas: un archivo de unidad puede estar habilitado pero inactivo, activo pero deshabilitado, ser estático, generado, transitorio o estar enmascarado, y puede no aparecer en uno de los listados. Inspecciona el contenido combinado del proveedor y de los ajustes parciales con:
$ systemctl cat UNIT.service
$ systemctl show UNIT.service
¿Qué muestra list-unit-files que no constituye el propósito principal de list-units?
Crear un ajuste local
Usa un ajuste parcial en lugar de editar una unidad instalada por un paquete:
$ sudo systemctl edit UNIT.service
Después de guardar, en las implementaciones actuales systemctl normalmente pide al gestor que vuelva a cargar la configuración como parte de este flujo de edición. Sin embargo, cuando los archivos se modifican de otra forma, ejecuta:
$ sudo systemctl daemon-reload
daemon-reload vuelve a leer las definiciones de las unidades y reconstruye las dependencias. No recarga la configuración de las aplicaciones ni reinicia los servicios activos. Cuando corresponda, valida la sintaxis y las dependencias de la unidad con systemd-analyze verify y después revisa la unidad efectiva combinada.
¿Qué hace systemctl daemon-reload?
Estado del servicio durante la ejecución
Después de validar la configuración del servicio y conservar una vía de recuperación:
$ sudo systemctl start peanut.service
$ sudo systemctl stop peanut.service
$ sudo systemctl restart peanut.service
$ sudo systemctl reload peanut.service
reload solo funciona cuando la unidad define o admite una acción de recarga. restart interrumpe el proceso y puede no conseguir restaurar el servicio. Para el acceso remoto, la red, el almacenamiento o la autenticación, conserva una vía independiente mediante la consola y valida la configuración antes de actuar.
Consulta el estado y los registros con:
$ systemctl status peanut.service
$ systemctl is-active peanut.service
$ journalctl -u peanut.service -b
«Activo» es un estado del gestor, no una prueba de que todos los puntos de acceso de la aplicación funcionen correctamente.
¿Qué comando inicia ahora peanut.service sin cambiar por sí solo su habilitación futura?
Habilitar, deshabilitar y enmascarar
Gestiona los enlaces de dependencias futuros con:
$ sudo systemctl enable peanut.service
$ sudo systemctl disable peanut.service
Habilitar no inicia la unidad salvo que se añada --now. Deshabilitar no detiene una unidad en ejecución salvo que se añada --now. Una unidad estática puede carecer de metadatos de instalación y aun así activarse como dependencia de otra unidad.
Enmascarar enlaza la unidad con /dev/null y bloquea su activación normal, incluida la activación como dependencia, hasta que se quite la máscara. Es una medida más fuerte que deshabilitar y puede romper las unidades dependientes; inspecciona las dependencias inversas antes de usarla.
¿Qué ocurre con un servicio que ya está en ejecución después de ejecutar systemctl disable UNIT sin --now?
Comprobar el resultado del servicio
Después de un cambio, comprueba el estado del proceso, los registros recientes, los puntos de acceso a la escucha, las unidades dependientes, la salud de la aplicación y el comportamiento tras un reinicio controlado si cambió la habilitación al arrancar. Utiliza systemctl is-failed, systemctl list-dependencies y las comprobaciones propias de la aplicación según corresponda.
Lección completada
Has completado Objetivos de systemd
Ahora puedes gestionar un servicio de systemd sin confundir la configuración, la ejecución y la habilitación.
Interpreta
[Unit],[Service]y[Install]según sus funciones distintas.Compara el estado de las unidades cargadas con el estado de los archivos de unidad instalados.
Usa ajustes parciales y vuelve a cargar el gestor después de modificar archivos externamente.
Inicia, detén, recarga o reinicia solo después de revisar el impacto.
Trata la habilitación, la deshabilitación y el enmascaramiento como controles de persistencia distintos.
Guarda tu progreso
Crea una cuenta gratuita para guardar esta lección y continuar en cualquier dispositivo.
Crear una cuenta gratuita