systemd (Español)

Esta traducción de Systemd fue revisada el 2018-12-09. Si existen cambios puede actualizarla o avisar al equipo de traducción.

Utilización básica de systemctl

La principal orden usada para conocer y controlar systemd es systemctl. Algunos de los posibles usos son el examen del estado del sistema y la gestión del sistema o de los servicios. Consulte para conocer más detalles.

Analizar el estado del sistema

Para mostrar el estado del sistema utilice:

$ systemctl status

Para listar unidades en ejecución:

$ systemctl

o:

$ systemctl list-units

Para listar unidades que han fallado:

$ systemctl --failed

Los archivos de las unidades disponibles se pueden ver en /usr/lib/systemd/system/ y /etc/systemd/system/ (este último tiene prioridad). Puede ver un listado de las unidades instaladas con:

$ systemctl list-unit-files

Utilizar las unidades

Las unidades pueden ser, por ejemplo, services (.service), mount points (.mount), devices (.device) o sockets (.socket).

Cuando se usa systemctl, por lo general, tiene que especificar el nombre completo de la unidad, incluyendo el sufijo, por ejemplo, . Sin embargo, hay unos pocos atajos cuando se especifica la unidad en las siguientes órdenes systemctl:

Si no se especifica el sufijo, systemctl asumirá que es .service. Por ejemplo, y se consideran equivalentes.
Los puntos de montaje se traducirán automáticamente en la correspondiente unidad .mount. Por ejemplo, si especifica será equivalente a .
Similar a los puntos de montaje, los dispositivos se traducen automáticamente en la correspondiente unidad .device, por lo tanto, la especificación es equivalente a .

Véase para más detalles.

Nota: Algunos nombres de unidades contienen un signo @ (por ejemplo, name@string.service): esto significa que son instancias de una unidad plantilla, cuyo nombre de archivo real no contiene la parte string (por ejemplo, name@.service ). string se denomina al identificador de instancia, y es similar a un argumento que se pasa a la unidad que sirve de plantilla cuando es llamada con el orden systemctl: en el archivo de unidad se sustituirá el especificador %i.

Para ser más precisos, antes de probar inicializar una instancia de unidad de plantilla name@.suffix, systemd buscará una unidad con el nombre del archivo name@string.suffix exacto, aunque por convención, tal «conflicto» ocurre raramente, es decir, la mayoría de los archivos de unidades que contienen un signo @ son plantillas. Además, si se llama a una unidad de plantilla sin un identificador de instancia, simplemente fallará, ya que el especificador %i no puede ser sustituido.

Sugerencia: La mayoría de las siguientes órdenes también funcionan si se especifican varias unidades, vea systemctl(1) para más información.

Activa una unidad de inmediato:

# systemctl start unidad

Detiene una unidad de inmediato:

# systemctl stop unidad

Reinicia la unidad:

# systemctl restart unidad

Hace que una unidad recargue su configuración:

# systemctl reload unidad

Muestra el estado de una unidad, incluso si se está ejecutando o no:

$ systemctl status unidad

Comprueba si la unidad ya está activada o no:

$ systemctl is-enabled unidad

Activa una unidad para inicarse en el arranque:

# systemctl enable unidad

Activa una unidad para inicarse en el arranque y lo inicia inmediatamente:

# systemctl enable --now unidad

Desactiva el inicio automático durante el arranque:

# systemctl disable unidad

Enmascara una unidad para que sea imposible iniciarla (tanto de forma manual como de dependencia, lo que hace que el enmascaramiento sea peligroso):

# systemctl mask unidad

Desenmascara una unidad:

# systemctl unmask unidad

Muestre la página del manual asociada a una unidad (esto debe ser compatible con el archivo de la unidad):

$ systemctl help unidad

Recarga la configuración de systemd, buscando unidades nuevas o modificadas:

# systemctl daemon-reload

Gestionar la energía

polkit es necesario para gestionar la energía. Si se encuentra en una sesión local de systemd-logind y ninguna otra sesión está activa, las órdenes siguientes funcionarán sin requerir privilegios de root. Si no es así (por ejemplo, debido a que otro usuario ha iniciado otra sesión tty), systemd automáticamente le requerirá la contraseña de root.

Apagado y reinicio del sistema:

$ systemctl reboot

Apagado del sistema:

$ systemctl poweroff

Suspensión del sistema:

$ systemctl suspend

Poner el sistema en hibernación:

$ systemctl hibernate

Poner el sistema en estado de reposo híbrido — «hybrid-sleep» — (o suspensión combinada — «suspend-to-both» —):

$ systemctl hybrid-sleep

Escribir archivos de unidad

La sintaxis de los archivos de unidad de systemd está inspirada en los archivos .desktop de la Especificación de Entrada del Escritorio XDG que a su vez están inspirados en los archivos .ini de Microsoft Windows. Los archivos de unidad se cargan desde varias ubicaciones (para ver la lista completa, ejecute ), pero los principales son (enumerados desde la prioridad más baja a la más alta):

/usr/lib/systemd/system/: unidades proporcionadas por los paquetes instalados.
/etc/systemd/system/: unidades instaladas por el administrador del sistema.

Mire las unidades instaladas por sus paquetes para obtener ejemplos, así como la [sección de ejemplo anotada de .

Manejar las dependencias

Con systemd las dependencias pueden ser resueltas diseñando la unidad correctamente. El caso más típico es que la unidad A requiere la unidad B para poder funcionar, por lo que esta última debe iniciarse antes que A. En ese caso, agregue y a la sección de A. Si la dependencia es opcional agregue, en su lugar, y . Tenga en cuenta que Wants= y no incluyen , lo que significa que si no esté especificado, las dos unidades se iniciarán en paralelo.

Las dependencias se colocan normalmente en los archivos .service y no en los #Targets. Por ejemplo, es llamado por cualquiera que sea el servicio que configure las interfaces de red, por lo tanto, la solicitud que hace después la propia unidad personalizada es suficiente, ya que se inicia de todos modos.

Tipos de servicios

Existen diferentes tipos de arranque a tener en cuenta cuando se escribe un archivo de servicio personalizado. Esto se configura mediante el parámetro en la sección .

(por defecto): systemd considera que el servicio debe iniciarse inmediatamente. El proceso no debe romperse. No utilice este tipo si otros servicios tienen que ser llamados por ese servicio, a menos que no sea activado por el socket.
: systemd considera que el servicio debe ser iniciado antes que el proceso se rompa y el antecesor se haya terminado. Para los demonios clásicos use este tipo a menos que sepa que no es necesario, ya que la mayoría de los demonios usan doble bifurcación para indicar que están listos. Debe especificar también para que systemd puede realizar un seguimiento del proceso principal.
Type=oneshot: esto es útil para los scripts que hacen un solo trabajo y luego concluyen. Es posible que desee también establecer de modo que systemd sigue considerando el servicio como activo después de que el proceso haya terminado.
: igual que , pero con la condición de que el demonio va a enviar una señal a systemd cuando esté listo. Esto requiere del código específico proporcionado por .
Type=dbus: el servicio se considera listo cuando el especificado aparece en el bus del sistema DBus.
: systemd retrasará la ejecución del binario del servicio hasta que se envíen todos los trabajos. Un comportamiento por cierto muy similar a .

Consulte la página del manual systemd.service(5) para obtener una explicación más detallada de los valores .

Modificar los archivos de unidad suministrados

Para evitar conflictos con pacman, los archivos de unidad proporcionados por los paquetes no deben editarse directamente. Hay dos formas seguras de modificar una unidad sin tocar el archivo original: crear un nuevo archivo de unidad que sobrescriba la unidad original o crear fragmentos para insertarlos que se aplican sobre la unidad original. Para ambos métodos, debe volver a cargar la unidad posteriormente para que los cambios surtan efectos. Esto se puede hacer editando la unidad con (que recarga la unidad automáticamente) o recargando todas las unidades con:

# systemctl daemon-reload

Reemplazar los archivos de unidad

Para reemplazar el archivo de unidad /usr/lib/systemd/system/unit, cree el archivo y reactive la unidad para actualizar los enlaces simbólicos:

# systemctl reenable unidad

Alternativamente, ejecute:

# systemctl edit --full unidad

Esto abre en su editor (copiando la versión instalada si aún no existe) y la vuelve a cargar automáticamente cuando termina de editar.

Archivos insertados

Para crear fragmentos de archivos para insertar en el archivo de unidad /usr/lib/systemd/system/unit, cree el directorio y coloque los archivos .conf allí para sobrescribir o agregar nuevas opciones. systemd analizará y aplicará estos archivos con preferencia a la unidad original.

La forma más fácil de hacer esto es ejecutar:

# systemctl edit unidad

Esto abre el archivo en su editor de texto (creándolo si es necesario) y vuelve a cargar automáticamente la unidad cuando haya terminado de editarla.

Volver a la versión del proveedor

Para revertir cualquier cambio en una unidad realizada utilizando , ejecute:

# systemctl revert unidad

Ejemplos

Por ejemplo, si simplemente desea agregar una dependencia adicional a una unidad, puede crear el siguiente archivo:

/etc/systemd/system/''unit''.d/customdependency.conf

[Unit]
Requires=''dependencia nueva''
After=''dependencia nueva''

Otro ejemplo, para reemplazar la directiva para una unidad que no sea del tipo , cree el siguiente archivo:

Observe como debe quedar límpio antes de volver a reasignarse . Lo mismo se aplica a cada elemento que se puede especificar varias veces, por ejemplo OnCalendar para los temporizadores.

Un ejemplo más para reiniciar automáticamente un servicio:

Targets

systemd utiliza targets («objetivos») que sirven a un propósito similar a los runlevels («niveles de ejecución»), pero que tienen un comportamiento un poco diferente. Cada target se nomina, en lugar de numerarse, y está destinado a servir a un propósito específico con la posibilidad de realizar más de una acción al mismo tiempo. Algunos targets son activados heredando todos los servicios de otro target e implementando servicios adicionales. Como hay targets de systemd que imitan los runlevels de SystemVinit, es, por tanto, posible pasar de un target a otro utilizando la orden .

Conocer los targets presentes

La siguiente orden debe ser utilizada bajo systemd, en lugar de :

$ systemctl list-units --type=target

Crear un target personalizado

Los niveles de ejecución («runlevels») que tenían un significado definido bajo sysvinit (es decir, 0, 1, 3, 5 y 6), tienen una correlación de 1:1 con un específico target de systemd. Desafortunadamente, no hay una buena manera de hacer lo mismo para los niveles de ejecución definidos por el usuario como son el 2 y el 4. Si se hace uso de estos últimos, se sugiere dar un nuevo nombre al target de systemd como que tome como base uno de los runlevels existentes (vea como ejemplo), cree un directorio /etc/systemd/system/su target.wants, y haga un enlace a los servicios adicionales de /usr/lib/systemd/system/ que desea activar.

Correlación entre los niveles de ejecución de SysV y los targets de systemd

Nivel de ejecución de SysV	Target de systemd	Notas
0	runlevel0.target, poweroff.target	Detiene el sistema.
1, s, single	runlevel1.target, rescue.target	Modalidad de usuario único.
2, 4	runlevel2.target, runlevel4.target, multi-user.target	Definidos por el usuario/específico del sistio. Preconfigurados a 3.
3	runlevel3.target, multi-user.target	Multiusuario, no gráfica. Los usuarios, por lo general, pueden acceder a través de múltiples consolas o a través de la red.
5	runlevel5.target, graphical.target	Multiusuario, gráfica. Por lo general, tiene todos los servicios del nivel de ejecución 3, además de un inicio de sesión gráfica.
6	runlevel6.target, reboot.target	Reinicia el sistema.
emergency	emergency.target	Consola de emergencia.

Cambiar el target vigente

En systemd los targets quedan expuestos a través de «target units». Se pueden cambiar de esta manera:

# systemctl isolate graphical.target

Esto solo cambiará el target actual, y no tendrá ningún efecto sobre el siguiente arranque. Esto es equivalente a las órdenes o en Sysvinit.

Cambiar el target predeterminado para arrancar

El target estándar es , que es un enlace simbólico para graphical.target. Este se corresponde con el antiguo nivel de ejecución 5.

Para verificar el target actual con systemctl, ejecute:

$ systemctl get-default

Para cambiar el target predeterminado para arrancar, cambie el enlace simbólico . Con systemctl:

Como alternativa, agregue uno de los siguientes parámetros del kernel a su cargador de arranque:

(que corresponde aproximadamente al anterior nivel de ejecución 3),
(que corresponde aproximadamente al anterior nivel de ejecución 1).

Orden de los target por defecto

Systemd elige el de acuerdo con el siguiente orden:

El parámetro del kernel se muestra arriba
Enlace simbólico de
Enlace simbólico de

Archivos temporales

«systemd-tmpfiles crea, elimina y limpia archivos y directorios volátiles y temporales.» Lee los archivos de configuración en /etc/tmpfiles.d/ y para descubrir qué acciones realizar. Los archivos de configuración del primer directorio tienen prioridad sobre los del último directorio.

Los archivos de configuración son proveídos normalmente junto con los archivos de servicio, y reciben su nombre en el estilo . Por ejemplo, el demonio Samba espera que el directorio exista para obtener los permisos adecuados. Por tanto, el paquete samba viene con esta configuración:

Los archivos de configuración también pueden ser usados para escribir en el arranque valores en ciertos archivos. Por ejemplo, si usa para dehabilitar la reactivación del sistema («wakeup») a través de dispositivos USB con la orden , se puede utilizar, en su lugar, el siguiente tmpfile:

Consulte las páginas de los manuales y para obtener más detalles.

Nota: Este método puede no funcionar ajustando las opciones en /sys desde el momento en que el servicio systemd-tmpfiles-setup puede ejecutarse antes de que los módulos de los dispositivos adecuados se carguen. En este caso, se puede comprobar si el módulo tiene un parámetro para la opción que desea ajustar con modinfo modulo y establecer esta opción con un archivo de configuración en /etc/modprobe.d. De lo contrario, tendrá que escribir una regla udev para establecer el atributo apropiado tan pronto como el dispositivo lo reclame.

Temporizadores

Un temporizador es un archivo de configuración de unidad cuyo nombre termina en .timer y codifica información sobre un temporizador controlado y supervisado por systemd, para la activación basada en plazos de tiempo. Consulte systemd/Timers.

Montaje

systemd se encarga de montar las particiones y los sistemas de archivos especificados en . El script traduce todas las entradas presentes en en unidades de systemd, esto se realiza en el momento del arranque y cada vez que se vuelve a cargar la configuración del gestor del sistema.

systemd extiende las habituales capacidades de fstab y ofrece opciones de montaje adicionales. Esto afecta a las dependencias de la unidad de montaje; por ejemplo, se puede garantizar que un montaje se realice solo una vez que la red esté activa o solo cuando se monte otra partición. La lista completa de las opciones de montaje específicas de systemd, que generalmente llevan el prefijo x-systemd., se detalla en .

En Montaje automático con systemd se proporciona un ejemplo de estas opciones de montaje en el contexto del automontaje, pensando en aquellos recursos que se deben montar tan solo cuando se les requiere en lugar de automáticamente en el momento del arranque.

Montaje automático de particiones GPT

En un disco particionado con GPT, el script montará particiones siguiendo la especificación de particiones detectables , por lo tanto, las mismas se pueden omitir de .

El montaje automático de una partición se puede desactivar cambiando el tipo GUID de la partición o configurando el atributo 63 "do not automount" para la partición en cuestión, véase gdisk#Prevent GPT partition automounting.

Consejos y trucos

Ejecutar servicios después de que la conexión de red esté activa

Para demorar la ejecución de un servicio hasta depués de que la red esté funcionando, incluya las siguientes dependencias en el archivo .service:

El servicio de espera de red de la particular aplicación que gestiona la conexión la red también debe activarse para que refleje adecuadamente el estado de la red.

Para los que usan NetworkManager, active .
Si se usa systemd-networkd, systemd-networkd-wait-online.service se activa automáticamente de forma predeterminada cada vez que está activado; compruebe que este es el caso con , lo cual hará que no se necesite ninguna otra acción.

Para obtener explicaciones más detalladas, consulte: Network configuration synchronization points.

Activar las unidades instaladas por defecto

Arch Linux se entrega con /usr/lib/systemd/system-preset/99-default.preset que contiene . Esto hace que systemctl preset desactive todas las unidades de forma predeterminada, de modo que cuando se instala un nuevo paquete, el usuario debe activar la unidad manualmente.

Si este comportamiento no es deseado, simplemente cree un enlace simbólico de a para anular el archivo de configuración . Esto hará que systemctl preset active todas las unidades que se instalan, independientemente del tipo de unidad, a menos que se especifique otra cosa en otro archivo ubicado en uno de los directorios de configuración de systemctl preset. Las unidades de usuario no se verán afectadas. Vea para más información.

Entornos seguros para probar aplicaciones

Un archivo de unidad se puede crear como un sandbox para aislar aplicaciones y sus procesos dentro de un entorno virtual reforzado. systemd aprovecha los espacio de nombres, las listas blancas/negras basadas en Capabilities y los grupos de control para contener procesos a través de una extensa configuración de entornos de ejecución.

El aprovisionamiento de un archivo de unidad systemd existente con la aplicación sandboxing, generalmente requiere de pruebas de ensayo y error acompañadas del uso generoso de , stderr, registro de errores de journalctl y de salida de recursos. Es posible que desee buscar primero en la documentación anterior los test ya realizados a partir de los cuales realizar la pruebas.

Algunos ejemplos sobre cómo se puede implementar el sandboxing con systemd:

CapabilityBoundingSet define un conjunto en lista blanca de capacidades permitidas, pero también se puede usar para incluir en una lista negra una capacidad específica para una unidad.
- La capacidad , por ejemplo, que debería ser uno de los objetivos de un sandbox seguro:

Solución de problemas

Investigar errores de systemd

Como ejemplo, vamos a investigar un error con el servicio :

1. Vamos a determinar los servicios de systemd que fallan al inicio:

$ systemctl --state=failed

systemd-modules-load.service   loaded '''failed failed'''  Load Kernel Modules

Otra forma es ver los mensajes en vivo del registro de systemd:

$ journalctl -fp err

2. Encontramos un problema con el servicio . Indaguemos un poco más:

Si el no está en la lista, simplemente reinicie el servicio fallido con

3. Ahora tenemos el identificador del proceso (PID) para investigar este error en profundidad. Escribimos la siguiente orden con el (en este caso: 15630):

4. Vemos que algunos de los ajustes del módulo del kernel tienen valores erróneos. Por lo tanto, echemos un vistazo a estos valores en :

5. El mensaje del error Failed to find module 'blacklist usblp' puede estar relacionado con un mal ajuste de . Podemos desactivarlo insertando un signo # delante de cada opción que hemos descubierto que falla por medio del paso 3:

6. Ahora, intente iniciar :

$ systemctl start systemd-modules-load.service

Si ha tenido éxito, no debe mostrarse ningún prompt. Si ve algún error, volveremos al paso 3 y utilizaremos el nuevo PID para solucionar los errores que aparecen en la izquierda.

Si todo está bien, se puede verificar que el servicio se ha iniciado satisfactoriamente con:

Diagnosticar problemas de arranque

systemd tiene varias opciones para diagnosticar problemas con el proceso de arranque. Véase depuración del arranque para obtener instrucciones y opciones más generales para capturar mensajes de inicio antes de que systemd se haga cargo del proceso de arranque. Véase también ña documentación de depuración de errores de systemd.

Diagnosticar un servicio

Si algún servicio systemd se comporta mal o si desea obtener más información sobre lo que está sucediendo, configure la variable de entorno SYSTEMD_LOG_LEVEL a . Por ejemplo, para ejecutar el demonio systemd-networkd en modo de depuración de errores:

Agregue un fragmento de archivo para el servicio agregando las dos líneas siguientes:

[Service] Environment=SYSTEMD_LOG_LEVEL=debug

O, de igual modo, establezca la variable de entorno manualmente:

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

luego reinicie systemd-networkd y observe jopurnal para el servicio con la opción /.

Apagar/reiniciar se hace terriblemente largo

Si el proceso de apagado tarda un tiempo muy largo (o parece congelarse), lo más probable es que un servicio no existente tenga la culpa. systemd espera un tiempo para iniciar cada servicio antes de tratar de acabar con él. Para averiguar si este es su caso, consulte este artículo.

Los procesos de corta duración parecen no registrar ninguna salida

Si no muestra ninguna salida para un servicio de breve duración, compruebe el PID. Por ejemplo, si falla, y systemctl status systemd-modules-load muestra que es seguido con PID 123, entonces es posible ver la salida de journal para dicho PID, por ejemplo . Los campos con metadatos para journal, como y , se recogen en modo asíncrono y se basan en la carpeta para el proceso existente. La reparación de este proceso requiere la reparación del kernel para proporcionar estos datos por medio de una conexión socket, de forma similar a SCM_CREDENTIALS. En resumen, es un bug. Tenga en cuenta que los servicios que fallan de inmediato pueden no imprimir nada en journal según el diseño de systemd.

El tiempo de arranque aumenta con el tiempo

Después de usar varios usuarios advirtieron que su tiempo de arranque había aumentado significativamente en comparación con lo que solía ser. Después de usar se informa que NetworkManager (Español) toma un tiempo inusualmente grande para comenzar.

El problema para algunos usuarios se debe a que es demasiado grande. Esto puede tener otros impactos en el rendimiento, como para o . Como tal, la solución es eliminar todos los archivos dentro de la carpeta (lo ideal sería hacer una copia de seguridad en algún lugar, al menos temporalmente) y luego establecer un límite de tamaño del archivo journal como se describe en Systemd (Español)/Journal (Español)#Límite del tamaño de journal.

systemd-tmpfiles-setup.service no se inicia en el arranque

A partir de systemd 219, especifica los atributos de ACL para los directorios en y, por lo tanto, requiere que el soporte de ACL sea activado para el sistema de archivos en el que reside journal.

Véase Access Control Lists#Enable ACL para obtener instrucciones sobre cómo activar la ACL en el sistema de archivos que aloja .

La versión de systemd impresa en el arranque no es la misma que la versión del paquete instalado

Debe regenerar initramfs y las versiones deberían coincidir.

Sugerencia: Se puede usar un hook de pacman para regenerar automáticamente initramfs cada vez que se actualice systemd. Vea este hilo del foro y Pacman (Español)#Hooks.

Desactivar el modo de emergencia en la máquina remota

Es posible que desee desactivar el modo de emergencia en una máquina remota, por ejemplo, una máquina virtual alojada en Azure o Google Cloud. Esto se debe a que, si se activa el modo de emergencia, la máquina no podrá conectarse a la red.

# systemctl mask emergency.service # systemctl mask emergency.target

Véase también

Wikipedia article
systemd Official web site
Manual pages
Otras distribuciones
Lennart's blog story, update 1, update 2, update 3, summary
systemd for Administrators (PDF)
How To Use Systemctl to Manage Systemd Services and Units
Session management with systemd-logind
Emacs Syntax highlighting for Systemd files
Two part introductory article in The H Open magazine.

This article is issued from Archlinux. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.