Entender y administrar systemd
Aprender los principios básicos del sistema de inicio systemd: como configurarlo y usarlo para administrar el sistema.
Comprender systemd
Systemd es un administrador del sistema y los servicios para Linux, compatible con scripts de inicio SysV y LSB. Systemd proporciona:
-
Capacidades agresivas de paralelización
-
Usa socket y activación D-Bus para el inicio de los servicios
-
Ofrece arranque de demonios a demanda, mantiene rastreo de los procesos usando Linux cgroups
-
Admite la creación de instantáneas y restauración del estado del sistema
-
Mantiene puntos de montaje y automontaje
-
Implementa un elaborado servicio de control lógico transaccional basado en la dependencia.
El comando systemctl
en la principal herramienta para administrar systemd. Combina la funcionalidad de los comandos service
y chkconfig
de SysVinit en una herramienta que usted puede usar para habilitar o deshabilitar servicios permanentemente o solo para la sesión actual.
Systemd gestiona las llamadas unidades, que son representaciones de los recursos y servicios del sistema. La siguiente lista muestra los tipos de unidades que systemd puede gestionar:
- service (servicio)
-
Un servicio en el sistema, incluyendo las instrucciones para arrancar, reiniciar y parar el servicio.
- socket
-
Un socket de red asociado con un servicio.
- device (dispositivo)
-
Un dispositivo gestionado específicamente con systemd.
- mount
-
Un punto de montaje gestionado con systemd.
- automount
-
Un punto de montaje montado automáticamente en el arranque.
- swap
-
Espacio swap (de intercambio) en el sistema.
- target
-
Un punto de sincronización para otras unidades. Utilizado usualmente para iniciar servicios habilitados en el arranque.
- path (ruta)
-
Una ruta para activación basada en ruta. Por ejemplo, usted puede iniciar servicios en base al estado de una ruta, como si existe o no.
- timer (temporizador)
-
Un temporizador para planificar la activación de otra unidad.
- snapshot (instantánea)
-
Una instantánea del estado actual de systemd. Usado normalmente para revertir después de realizar cambios temporales en systemd.
- slice
-
Restricción de recursos a través de nodos Grupo de Control Linux (cgroups).
- scope (alcance)
-
Información desde las interfaces bus systemd. Normalmente usado para gestionar procesos externos al sistema.
Iniciar, detener y consultar servicios systemd
Usted puede llevar a cabo diversas tareas de administración para controlar los servicios systemd utilizando el comando systemctl
. Lo siguiente es un conjunto de los comandos ejemplo para demostrar como usar systemctl
para administrar servicios systemd.
Requisitos previos
Usted tiene que acceder con un usuario con permisos a nivel de administrador.
Procedimiento
Los siguientes comando controlan el servicio foo
:
-
Activar un servicio inmediatamente:
# systemctl start foo
-
Desactivar un servicio inmediatamente:
# systemctl stop foo
-
Reiniciar un servicio:
# systemctl restart httpd
-
Mostrar el estado de un servicio, incluyendo si está corriendo o no:
# systemctl status foo
-
Habilitar un servicio para ser iniciado en el arranque:
# systemctl enable foo
-
Deshabilitar un servicio para que no se inicie durante el arranque:
# systemctl disable foo
-
Evitar que un servicio se inicie dinámicamente o incluso manualmente a no ser que esté desenmascarado:
# systemctl mask foo
-
Verificar si un servicio está habilitado o no:
# systemctl is-enabled foo
Información Relacionada
-
Ejecute
man systemctl
para más detalles.
Modificar servicios systemd existentes
Este ejemplo muestra como modificar un servicio existente. La modificación del servicio se almacena dentro de /etc/systemd/system
, es un solo archivo o en un subdirectorio que lleva el nombre del servicio. Por ejemplo, este procedimiento modifica el servicio httpd
.
Requisitos previos
-
Usted tiene que acceder con un usuario con permisos a nivel de administrador.
-
Usted ha configurado un servidor
httpd
corriendo a través de systemd.
Procedimiento
-
Los servicios Systemd pueden ser modificador usando el comando
systemctl edit
.# systemctl edit httpd.service
Esto crea un archivo de anulación
/etc/systemd/system/httpd.service.d/override.conf
y lo abre en su editor de texto. Todo lo que ponga en este archivo será añadido al archivo de servicio existente. -
Añada su configuración personal. Por ejemplo:
[Service] Restart=always RestartSec=30
Para reemplazar una opción que pueda ser ajustada múltiples veces, debe limpiarla primero, de otro modo el archivo de anulación añadirá la opción una segunda vez.
[Service] ExecStart= ExecStart=<nuevo comando>
-
Guarde el archivo. Systemd cargará automáticamente la nueva configuración del servicio.
-
Reiniciar el servicio
httpd
:# systemctl restart httpd
Para reemplazar completamente (en lugar de solo añadir/modificar) un archivo de servicio existente, use systemctl edit --full
, por ejemplo systemctl edit --full httpd.service
. Esto creará /etc/systemctl/system/httpd.service
, que será usado en lugar del archivo de servicio existente.
Información Relacionada
-
Vea Parámetros comunes de servicio para más información sobre los parámetros de este procedimiento.
Crear nuevos servicios systemd
Este ejemplo muestra como crear un archivo de unidad para un servicio personalizado. Los archivos personalizados de unidad se ubican en`/etc/systemd/system/` y tienen una extensión .service
. Por ejemplo, un servicio personalizado foo utiliza el archivo de unidad /etc/systemd/system/foo.service
.
Requisitos previos
-
Usted tiene que acceder con un usuario con permisos a nivel de administrador.
Procedimiento
Este procedimiento crea un archivo de configuración básico para controlar el servicio foo
.
-
Cree y edite el nuevo archivo de configuración:
# nano /etc/systemd/system/foo.service
-
Los siguientes pasos describen cada sección y sus parámetros para añadir al archivo:
-
La sección
[Unit]
proporciona información básica sobre el servicio. El serviciofoo
usa los siguientes parámetros:Description
-
Una cadena que describe la unidad. Systemd muestra esta descripción cerca del nombre de la unidad en la interfaz de usuario.
After
-
Define una relación con una segunda unidad. Si usted activa la unidad, systemd la activa solo después de la segunda. Por ejemplo, el servicio
foo
podría requerir conectividad de red, lo que significa que el serviciofoo
especificanetwork.target
como una condiciónAfter=
.La sección
[Unit]
resultante se ve como esto:[Unit] Description=My custom service After=network.target
-
La sección
[Service]
proporciona instrucciones sobre como controlar el servicio. El servicio`foo` utiliza los siguientes parámetros:Type
-
Define el tipo de servicio systemd. En este ejemplo, el servicio
foo
es un serviciosimple
, el cual inicia el servicio sin ninguna consideración especial. ExecStart
-
El comando para ejecutar el inicio del servicio. Esto incluye la ruta completa al comando y los argumentos que modifican el servicio.
La sección
[Service]
resultante se parece a esto:[Service] Type=simple ExecStart=/usr/bin/sleep infinity
-
La sección
[Install]
proporciona instrucciones sobre como systemd instala el servicio.. El serviciofoo
usa los siguientes parámetros:WantedBy
-
Define que servicio dispara el servicio personalizado si está habilitado con
systemctl enable
. Esto se utiliza mayormente para iniciar el servicio personalizado en el arranque. En este ejemplo,foo.service
usamulti-user.target
, el cual inicia`foo.service` cuando systemd cargamulti-user.target
en el arranque.
-
-
El archivo completo`foo.service` tiene los siguientes contenidos:
[Unit] Description=My custom service After=network.target [Service] Type=simple ExecStart=/usr/bin/sleep infinity [Install] WantedBy=multi-user.target
Guarde el archivo.
-
Para hacer que systemd esté atento al nuevo servicio, recargue sus archivos de servicio
# systemctl daemon-reload
-
Inicie el servicio personalizado
foo
:# systemctl start foo
-
Verifique el estado del servicio para asegurar que el servicio está corriendo:
$ systemctl status foo ● foo.service - My custom service Loaded: loaded (/etc/systemd/system/foo.service; static; vendor preset: disabled) Active: active (running) since Thu 2017-12-14 14:09:12 AEST; 6s ago Main PID: 31837 (sleep) Tasks: 1 (limit: 4915) CGroup: /system.slice/foo.service └─31837 /usr/bin/sleep infinity Dec 14 14:09:12 dansmachine systemd[1]: Started My custom service.
Información Relacionada
-
Vea Parámetros comunes de servicio para más información sobre los parámetros de este procedimiento.
Convirtiendo los servicios SysVinit a systemd
Los versiones más antiguas de Fedora usan scripts SysVinit para administrar los servicios. Esta sección proporciona algunas directrices sobre como convertir un script SysVinit a un systemd equivalente.
Requisitos previos
-
Usted tiene que acceder con un usuario con permisos a nivel de administrador.
-
Usted tiene un script SysVinit personalizado para convertir a una configuración systemd.
Procedimiento
-
Identifique los niveles de ejecución en su script SysVinit. Esto está definido normalmente con la directiva
chkconfig
en la sección comentada al principio del script. Por ejemplo, lo siguiente indica que el servicio está usando los niveles de ejecución 3, 4 y 5:# chkconfig: 235 20 80
systemd utiliza objetivos en lugar de niveles de ejecución. Use la tabla en [converting-sysvinit-services] para mapear los niveles de ejecución a objetivos. En este ejemplo, los niveles de ejecución 2, 3 y 5 son niveles de ejecución multiusuario, de modo que el servicio systemd puede usar lo siguiente:
[Install] WantedBy=multi-user.target
Si usted habilita el servicio systemd para que inicie al arranque (
systemctl enable foo.service
), systemd carga el servicio cuando carga elmulti-user.target
en el momento del arranque. -
Identifique los servicios dependientes y los objetivos. Por ejemplo, si el servicio personalizado requiere conectividad de red, especifique
network.target
como dependencia:[Unit] Description=My custom service After=network.target
-
Identifique el comando usado para iniciar el servicio en el script SysVinit y convertir esto al systemd equivalente. Por ejemplo, el script podría contener una función
start
en el siguiente formato:start() { echo "Starting My Custom Service..." /usr/bin/myservice -D }
En este ejemplo, el comando
/usr/bin/myservice
es el comando de servicio personalizado configurado para demonizar con la opción-D
. Establezca el parámetroExecStart
para usar este comando:[Service] ExecStart=/usr/bin/myservice -D
-
Verifique el script SysVinit para ver si el servicio usa un comando especial para reiniciar el servicio. Por ejemplo, el script podría contener una función
reboot
que recarga el servicio:reboot() { echo "Reloading My Custom Service..." /usr/bin/myservice reload }
En este ejemplo, el comando
/usr/bin/myservice
es el comando del servicio personalizado y recarga el servicio usando el subcomandoreload
. Establezca el parámetroExecReload
para usar este comando:[Service] ExecReload=/usr/bin/myservice reload
Alternativamente, puede omitir
ExecReload
y usar el comportamiento predeterminado, que mata el servicio y lo inicia otra vez. -
Verifique el script SysVinit para ver si el servicio usa un comando especial para parar el servicio. Por ejemplo, el script podría contener una función
stop
que recarga el servicio:reboot() { echo "Stopping My Custom Service..." /usr/bin/myservice shutdown }
En este ejemplo, el comando
/usr/bin/myservice
es el comando del servicio personalizado y detiene el servicio correctamente usando el subcomandoshutdown
. Establezca el parámetroExecStop
para usar este comando:[Service] ExecStop=/usr/bin/myservice shutdown
Alternativamente, puede omitir
ExecStop
y usar el comportamiento predeterminado, que mata el servicio. -
Revise el script SysVinit e identifique cualquier parámetro adicional o funciones. Use parámetros systemd para replicar cualquier función SysVinit identificada que podría ser relevante para su servicio.
Información Relacionada
-
Vea Parámetros comunes de servicio para más información sobre los parámetros de este procedimiento.
Parámetros de servicio común
Parámetros Unitarios
Esta sección contiene parámetros que puede usar en la sección [Unit]
de un servicio. Estos parámetros son comunes a otras unidades de systemd.
Esta lista es una versión sumaria. Para un listado completo de estos parámetros y sus descripciones, ejecute man systemd.unit
.
- Descripción
-
Una cadena de forma libre describiendo el servicio.
- Documentation (Documentación)
-
Una lista separada por espacios de URIs referenciando documentación para este servicio o su configuración. Lo aceptado son solo URIs de los siguientes tipos:
http://
,https://
,file:
,info:
:,man:
:. - Requires (Requiere)
-
Configura las dependencias requeridas sobre los otros servicios. Si este servicio se activa, las unidades listadas aquí se activan también. Si uno de los servicios dependientes falla al activar, systemd no inicia el servicio. Esta sección puede ser especificada más de una vez o usted puede especificar múltiples unidades separadas por espacios.
- Wants (Desea)
-
Similar a
Requires
, excepto que las unidades que fallan no tienen ningún efecto sobre el servicio. - BindsTo (Se une a)
-
Similar a
Requires
, excepto que las unidades en dependientes también paran el servicio. - PartOf (Parte de)
-
Similar a
Requires
, excepto que la parada y el reinicio de las unidades dependientes también paran y reinician el servicio. - Conflicts (Conflictos)
-
Una lista separada por espacios de nombres de unidad que, si corren, causan que el servicio no corra.
- Before, After (Antes, Después)
-
Una lista separada por espacios de nombres de unidad que configura el orden de las dependencias entre servicios.
- OnFailure (En Fallo)
-
Una lista separada por espacios de nombres de unidad que se activan cuando el servicio entra en estado de fallo.
Parámetros de Install
Este sección contiene los parámetros que usted puede usar en la sección [Install]
de un servicio. Estos parámetros son comunes a otras unidades de systemd.
Esta lista es una versión sumaria. Para un listado completo de estos parámetros y sus descripciones, ejecute man systemd.unit
.
- Alias
-
Una lista separada por espacios de nombres adicionales bajo los que este servicio será instalado. Los nombres listados aquí deben tener el mismo sufijo (esto es, tipo) que el nombre de archivo del servicio.
- RequiredBy, WantedBy
-
Define el servicio como dependiente de otro servicio. Esto generalmente define el objetivo para activar la ejecución de un servicio habilitado. Estas opciones son análogas a
Requires
yWants
en la sección[Units]
. - Also (También)
-
Unidades adicionales a instalar o desinstalar cuando este servicio se instala o desinstala.
Parámetros de Service
Esta sección contiene los parámetros que usted puede usar en la sección [Service]
de una unidad de servicio. Estos parámetros son específicos solo para las unidades de servicio systemd.
Esta lista es una versión sumaria. Para un listado completo de estos parámetros y sus descripciones, ejecute man systemd.unit
.
- Type (Tipo)
-
Configura el tipo de inicio del proceso para este servicio:
-
simple
– El servicio se inicia como el proceso principal. Esto es lo predeterminado. -
forking
– El servicio llama a procesos bifurcados y se ejecuta como parte del demonio principal. -
oneshot
- Similar asimple
, excepto que el proceso debe existir antes de que systemd inicie los procesos de seguimiento. -
dbus
- Similar asimple
, excepto que el demonio adquiere el nombre del bus D-Bus. -
notify
- Similar asimple
, excepto que el demonio envía un mensaje de notificación usandosd_notify
o una llamada equivalente después del arranque. -
idle
- Similar asimple
, excepto que la ejecución del servicio se retrasa hasta que se envíen todos los trabajos activos.
-
- RemainAfterExit
-
Un valor booleano que especifica si el servicio será considerado activo incluso si todos los procesos terminaron. Predeterminado a no.
- GuessMainPID
-
Un valor booleano que especifica si systemd debería adivinar el PID principal de un servicio si no se puede determinar de modo confiable. Esta opción se ignora a menos que se establezca
Type=forking
y no se establezcaPIDFile
. Predeterminado a yes. - PIDFile
-
Un nombre de archivo absoluto apuntando al PID de archivo de este demonio. El uso de esta opción está recomendado para servicios donde
Type=forking
. Systemd lee el PID del proceso principal del demonio después del arranque del servicio. Systemd no escribe al archivo configurado aquí, aunque elimina el archivo después de que se cierra el servicio. - BusName
-
Un nombre de bus D-Bus para alcanzar este servicio. Esta opción es obligatoria para servicios donde
Type=dbus
. ExecStart
-
Los comandos y argumentos ejecutados cuando se inicia el servicio.
- ExecStartPre, ExecStartPost
-
Comandos adicionales que se ejecutan antes o después del comando en
ExecStart
. - ExecReload
-
Los comandos y argumentos a ejecutar cuando se recarga el servicio.
- ExecStop
-
Los comandos y argumentos a ejecutar cuando se para el servicio.
- ExecStopPost
-
Comandos adicionales a ejecutar después de parar el servicio.
- RestartSec
-
El tiempo en segundos a esperar antes de reiniciar el servicio.
- TimeoutStartSec
-
El tiempo en segundos a esperar para el inicio del servicio.
- TimeoutStopSec
-
El tiempo en segundos a esperar para parar el servicio.
- TimeoutSec
-
Una abreviatura para configurar
TimeoutStartSec
yTimeoutStopSec
simultáneamente. - RuntimeMaxSec
-
Un tiempo máximo en segundos para la ejecución del servicio. Pase`infinity` (predeterminado) para configurar un límite infinito de tiempo de ejecución.
- Reiniciar
-
Configura si reiniciar el servicio cuando el proceso del servicio sale, es matado o alcanza el tiempo de salida:
-
no
– El servicio no será reiniciado. Esto es lo predeterminado. -
on-success
– Reinicia solo cuando el proceso del servicio sale limpiamente (código de salida 0). -
on-failure
– Reinicia solo cuando el proceso del servicio no sale limpiamente (código de salida distinto de cero). -
on-abnormal
– Reinicia si el proceso termina con una señal o se termina el tiempo. -
on-abort
– Reinicia si el proceso sale debido a una señal no detectada no especificada como estado de salida limpia. -
always
– Reinicia siempre.
-
Mapeo de niveles de ejecución a objetivos
Los objetivos Systemd sirven a un propósito similar que los niveles de ejecución SysVinit pero actúan un poco diferente. Cada objetivo tiene un nombre en lugar de un número y cada uno sirve a un propósito específico. Systemd implementa algunos objetivos heredando todos los servicios de otro objetivo y añadiéndole servicios adicionales. Algunos objetivos systemd imitan los niveles de ejecución comunes de sysvinit, lo que significa que puede cambiar de objetivo con el familiar comando telinit RUNLEVEL
. Los niveles de ejecución que asignaron un propósito específico en las instalaciones básicas de Fedora (0, 1, 3, 5 y 6) tienen un mapeo 1:1 con un objetivo específico systemd.
Sin embargo, este no es el caso de los niveles de ejecución definidos por el usuario 2 y 4. Para hacer uso de estos niveles de ejecución, cree un nuevo objetivo systemd con un nombre como /etc/systemd/system/$YOURTARGET`que toma uno de los niveles de ejecución existentes como base haga un directorio `/etc/systemd/system/$YOURTARGET.wants
y después un enlace simbólico a los servicios adicionales para habilitar este directorio.
Los siguiente es un mapeo de los niveles de ejecución SysVinit a los objetivos systemd.
Nivel de ejecución Sysvinit | Objetivo systemd | Notas |
---|---|---|
0 |
runlevel0.target, poweroff.target |
Para el sistema. |
1, s, single |
runlevel1.target, rescue.target |
Modo usuarios único. |
2, 4 |
runlevel2.target, runlevel4.target, multi-user.target |
Definido por el usuario/Niveles de ejecución específicos del sitio. Predeterminado, idéntico a 3. |
3 |
runlevel3.target, multi-user.target |
Multi-user, non-graphical. Los usuarios pueden acceder normalmente por medio de múltiples consolas o por red. |
5 |
runlevel5.target, graphical.target |
Multiusuario, gráfico. Normalmente tiene todos los servicios del nivel de ejecución 3 más acceso gráfico. |
6 |
runlevel6.target, reboot.target |
Reinicio |
emergency |
emergency.target |
Shell de emergencia |
Distribuir instrucciones del servicio
El tablero siguiente demuestra el equivalente systemd de las instrucciones de SysVinit.
Todas las versiones de systemctl asumen el sufijo .service si dejan fuera el nombre de servicio. Por ejemplo, systemctl start frobozz.service es lo mismo que systemctl start frobozz .
|
Instrucción Sysvinit | Instrucción systemd | Notas |
---|---|---|
|
|
Utilizada para arrancar un servicio (no reiniciar persistente) |
|
|
Utilizado para detener un servicio (no reiniciar persistente) |
|
|
Utilizado para detener y después arrancar un servicio) |
|
|
Cuando admitido, recarga el archivo config, sin interrumpir operaciones pendientes. |
|
|
Reiniciar si el servicio ya está ejecutándose. |
|
|
Dice si un servicio está ejecutándose actualmente. |
|
|
Utilizado para listar los servicios que pueden ser iniciados o detenidos |
|
|
Encender el servicio, para iniciar en el siguiente arranque, u otro disparador. |
|
|
Apagar el servicio para el siguiente reinicio, o cualquier otro disparador. |
|
|
Utilizado para comprobar si un servicio está configurado para iniciar o no dentro del entorno actual. |
|
|
Declara una tabla de servicios que listan cuales niveles de ejecución cada está configurado para encendido o apagado |
|
|
Declara una tabla de servicios que serán iniciados cuando arranquen en modo gráfico |
|
|
Se emplea para listar que niveles de este servicio está configurado encendido o apagado |
|
|
Utilizado cuando crea un archivo de servicio nuevo o modifica cualquier configuración |
Todos los comandos /sbin/service y //sbin/chkconfig listados en la tabla continúan trabajando en sistemas basados en systemd y se traducen a equivalentes nativos cuando es necesario. La única excepción es chkconfig --list .
|
Recursos adicionales
-
Lennart Poettering’s blog with lots of information about systemd. Lennart is the primary systemd developer
Want to help? Learn how to contribute to Fedora Docs ›