systemd (Español)
zh-CN:Systemd zh-TW:Systemd Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end De la página web del proyecto:
«systemd es un gestor del sistema y de los servicios para Linux, compatible con los initscript SysV y LSB. systemd proporciona una notable capacidad de paralelización, utiliza la activación de socket y D-Bus para iniciar los servicios, permite el inicio de los demonios bajo demanda, realiza un seguimiento de los procesos con el uso de los grupos de control de Linux, apoya snapshotting y la restauración del estado del sistema, mantiene los puntos montaje y servicios de montaje automático e implementa un elaborado sistema de gestión de dependencias basado en un control lógico de los servicios. Puede funcionar como un reemplazo total de sysvinit.»
Consulte también el artículo de Wikipedia.
Contents
- 1 Consideraciones previas antes de pasarse a systemd
- 2 Instalación
- 3 Configuración nativa
- 4 Transición de initscripts a systemd
- 5 Uso básico de systemctl
- 6 Iniciar un entorno de escritorio con systemd
- 7 Escribir los archivos .service personalizados
- 8 Targets
- 9 Journal
- 10 Optimización
- 11 Solución de problemas
- 12 Véase también
Consideraciones previas antes de pasarse a systemd
- Para una aproximación al tema son recomendables algunas lecturas acerca de systemd.
- Tenga en cuenta el hecho de que systemd tiene un sistema journal que sustituye a syslog, aunque los dos pueden coexistir. Véase la sección sobre journal más abajo.
- Aunque systemd puede reemplazar algunas de las funcionalidades de cron, acpid, o xinetd, no hay necesidad de abandonar el uso de los demonios tradicionales a menos que así lo desee.
- La interacción con los initscripts no está funcionando con systemd. En particular, netcfg-menu no puede ser usado al inicio del sistema.
Instalación
El presente apartado está dirigido a las instalaciones de Arch Linux que siguen basándose en sysvinit e initscripts y que aún no han migrado a systemd.
- Instale systemd y añada a la línea de órdenes del kernel lo siguiente:
init=/usr/lib/systemd/systemd
- Una vez hecho, puede habilitar los servicios deseados mediente el uso de
systemctl enable <nombre_del_servicio>
(los cuales equivalen aproximadamente a los demonios incluidos en la matrizDAEMONS
con nombres diferentes). - Reinicie el sistema y compruebe que
systemd
está realmente activo mediante la orden siguiente:$ cat /proc/1/comm
. Esta debería devolver la salida:systemd
. - Asegúrese de que el nombre del equipo está configurado correctamente en systemd:
hostnamectl set-hostname elnombredemiequipo
. - Proceda a eliminar initscripts y sysvinit del sistema e instale systemd-sysvcompat.
- Opcionalmente, retire el parámetro
init=/usr/lib/systemd/systemd
en cuanto que ya no es necesario. systemd-sysvcompat proporciona init de forma predeterminada.
Información complementaria
- Se si utiliza
quiet
en los parámetros del kernel, es posible removerlo durante el primer incio de systemd para identificar eventuales problemas durante el arranque. - No es necesario añadir su usuario a los grupos (
optical
,audio
,scanner
, etc.) para la mayoría de los casos con systemd. Los grupos pueden, incluso, causar alguna disfuncionalidad. Por ejemplo, el grupo de audio impedirá el cambio rápido de usuarios y permitirá que las aplicaciones bloqueen el software de mezcla. Cada inicio de sesión PAM proporciona una sesión logind, que, durante una sesión local, le dará permisos a través de POSIX ACLs para dispositivos de audio/vídeo, y permitirá ciertas operaciones, como el montaje de discos extraíbles, a través de udisks. - La eliminación del paquete initscripts romperá la compatibilidad con
rc.conf
. Tenga cuidado si tiene configurada una red estática con ellos o usa algunos demonios, que no han migrado aún a systemd. Vea la sección emular los initscripts para conocer más detalles sobre cómo pueden coexistir los dos sitemas. - Si se montan dispositivos LVM en fstab el propio sistema se mantendrá en espera por ellos y arrojará time out («tiempo excedido»). Espere a que time out suceda e introduzca la contraseña de root en la consola de emergencia. A continuación, escriba
systemctl enable lvm
para habilitar lvm en systemd. Después de otro reinicio los dispositivos LVM deberían estar disponibles.
Configuración nativa
Nombre del equipo
El nombre del equipo («hostname») se configura en /etc/hostname
. El archivo no debe contener el dominio del sistema, si existe. Para configurar el nombre de equipo, escriba:
# hostnamectl set-hostname elnombredemiequipo
Consulte man 5 hostname
y man 1 hostnamectl
para más detalles.
He aquí un ejemplo del archivo:
/etc/hostname
elnombredemiequipo
Configurar el idioma
El ajuste del idioma («locale») predeterminado del sistema se configura en /etc/locale.conf
. Para definir el idioma predeterminado, escriba:
# localectl set-locale LANG="es_ES.UTF-8"
/etc/locale.gen
y, luego, ejecutar locale-gen
como root. La configuración regional del idioma establecida por localectl
será uno de los locales previamente descomentado en el archivo /etc/locale.gen
.Consulte man 1 localectl
y man 5 locale.conf
para más detalles.
- Para más información, consulte Locale.
He aquí un ejemplo del archivo:
/etc/locale.conf
LANG=es_ES.UTF-8
Consola virtual
La configuración de la consola virtual (es decir, la distribución del teclado, el tipo de letra y la asignación de la consola) está definida en el archivo /etc/vconsole.conf
.
/etc/vconsole.conf
KEYMAP=es FONT=Lat2-Terminus16 FONT_MAP=
KEYMAP=
y FONT=
están vacías o no se han establecido.Otra forma de establecer la distribución del teclado («keymap») es escribiendo:
# localectl set-keymap es
localectl
también se puede utilizar para establecer la distribución del teclado de X11:
# localectl set-x11-keymap es
Consulte man 1 localectl
y man 5 vconsole.conf
para más detalles.
- Para obtener más información, consulte console fonts y keymaps.
Zona horaria
La zona horaria («timezone») se configura mediante la creación de un enlace simbólico adecuado de /etc/localtime
, que apunte a un archivo de información de zonas en /usr/share/zoneinfo/
. Para hacer esto de forma automática:
# timedatectl set-timezone Europe/Madrid
Véase man 1 timedatectl
, man 5 localtime
y man 7 archlinux
para obtener más detalles.
Como alternativa, cree el enlace simbólico manualmente:
# ln -s ../usr/share/zoneinfo/Europe/Madrid /etc/localtime
Reloj del hardware
Systemd usará UTC para el reloj del hardware por defecto.
Reloj del hardware en localtime
Si desea cambiar el horario del reloj del hardware («hardware clock») utilizando la hora local («localtime») -SERIAMENTE DESACONSEJADO-, escriba:
# timedatectl set-local-rtc true
Si desea que el reloj del hardware vuelva a estar ajustado a UTC (Universal Time Coordinated), escriba:
# timedatectl set-local-rtc false
Tenga en cuenta que si el reloj del hardware está configurado para usar la hora local (localtime), tratar con el horario de verano es complicado. Si el horario de verano (DST: Daylight Saving Time) entra en vigor cuando el ordenador está apagado, el reloj mostrará un horario equivocado en el próximo arranque (aquí algo más sobre esto). Los kernels actuales obtienen el horario del sistema del reloj del hardware directamente en el arranque, asumiendo que el reloj del hardware indica el horario UTC. Esto significa que si el horario del hardware (RTC: Real Time Clock) está definido por la hora local (localtime, en lugar de UTC), el primer horario del sistema se configurará incorrectamente, y después será corregido sucesivamente en cada arranque. Esta es posiblemente la causa de ciertos errores extraños (ir hacia atrás en el tiempo no suele ser una buena cosa).
La razón para permitir que la hora del reloj del hardware esté en localtime es habilitar un arranque dual con Windows (que utiliza localtime). Windows es capaz de gestionar la hora del reloj del hardware basándose en UTC con un sencillo ajuste del registro. Por tanto, es recomendable que Windows gestione el uso de UTC, en lugar de hacer que linux use localtime. Si se usa UTC con Windows, recuerde también desactivar la opción de Windows «Internet Time Update», con el fin de evitar confusiones entre windows y el reloj del hardware, al intentar sincronizar con el horario de internet. Al contrario, debería dejar que Linux sincronice el horario del sistema con el horario de internet, activando el demonio NTP, como se sugirió anteriormente.
- Para más información, consulte Time.
Módulos del kernel
Hoy en día, la carga de todos los módulos necesarios se realiza automáticamente por udev, de modo que, si no quiere/necesita utilizar ningún módulo fuera del kernel, no hay necesidad de poner los módulos para que se carguen en el arranque en ningún archivo de configuración. Sin embargo, hay casos en que es posible que desee cargar un módulo adicional durante el proceso de arranque, o poner algunos en blacklist para que el equipo funcione correctamente.
Cargar módulos extras en el arranque
Los módulos adicionales al kernel que se deseen cargar durante el arranque se configuran en archivos como una lista estática ubicados en la carpeta /etc/modules-load.d/
. Cada archivo de configuración es nombrado siguiendo el formato: /etc/modules-load.d/<programa>.conf
. Los archivos de configuración contienen simplemente una lista de los nombres de los módulos del kernel a cargar, separados por saltos de línea. Las líneas vacías y las líneas cuyo primer signo sea #
o ;
se ignoran. Por ejemplo:
/etc/modules-load.d/virtio-net.conf
# Cargar virtio-net.ko en el arranque virtio-net
Consulte man 5 modules-load.d
para obtener más detalles.
Blacklisting
Los módulos incluidos en blacklist («la lista negra») tienen el mismo comportamiento que con initscripts, ya que en realidad están a cargo de kmod. Consulte Módulos en Blacklist para más detalles.
Montaje del sistema de archivos
La configuración por defecto (de fsck) comprueba automáticamente y monta los sistemas de archivos antes de iniciar los servicios que necesitan que aquellos estén montados. Por ejemplo, systemd se asegura automáticamente de que el montaje de los sistemas de archivos remotos como NFS o Samba solo se inicie después de que la red ha sido creada. Por lo tanto, el montaje de los sistemas de archivos, tanto locales como remotos, especificados en /etc/fstab
deberían funcionar igualmente.
Consulte man 5 systemd.mount
para más detalles.
Montaje automático
- Si tiene una partición
/home
grande, tal vez sería mejor permitir que los servicios que no dependen de/home
se inicien, mientras/home
es comprobada. Esto se puede lograr mediante la adición de las siguientes opciones en la entrada de la partición/home
en fstab :
noauto,x-systemd.automount
Esto comprobará el sistema de archivos y montará /home
cuando se acceda a la misma por primera vez, y el kenel demorará todos los accesos a los archivos de /home
, almacenándolos en un búfer, hasta que la partición esté lista.
- Lo mismo se aplica a los montajes del sistema de archivos remoto. Si quiere que se monte solo cuando se acceda, tendrá que usar el parámetro
noauto,x-systemd.automount
. Además, puede utilizar la opciónx-systemd.device-timeout=#
para especificar un tiempo de espera para el caso de que el recurso de red no esté disponible.
- Si tiene sistemas de archivos cifrados con keyfiles, también puede añadir el parámetro
noauto
para las entradas correspondientes de/etc/crypttab
. Systemd no abrirá el dispositivo cifrado en el arranque, sino que esperará hasta que realmente se acceda al mismo y entonces lo abrirá automáticamente con el archivo de claves («keyfiles») especificado antes de montarlo. Esto podría ahorrar unos segundos en el arranque si se está usando, por ejemplo, un dispositivo RAID cifrado, porque systemd no tiene que esperar a que el dispositivo esté disponible. Por ejemplo:
/etc/crypttab
data /dev/md0 /root/key noauto
LVM
Si tiene un volumen LVM («Logical Volume Manager») que no se activa a través de initramfs, habilite el servicio lvm-monitoring
, proporcionado por el paquete lvm2:
# systemctl enable lvm-monitoring
Del mismo modo, si tiene un dispositivo LVM cifrado, montado posteriormente durante el arranque (por ejemplo de /etc/crypttab
), habilite lvm-on-crypt.service
(también proporcionado por el paquete lvm2):
# systemctl enable lvm-on-crypt
ACPI administración de la energía
Systemd puede manejar algunos eventos ACPI («Interfaz Avanzada de Configuración y Energía») relacionados con la energía. Esto se configura a través de las siguientes opciones en /etc/systemd/logind.conf
:
-
HandlePowerKey
: especifica qué acción se invoca cuando el botón de encendido se pulsa. -
HandleSuspendKey
: especifica qué acción se invoca cuando se pulsa el botón de suspensión. -
HandleHibernateKey
: especifica qué acción se invoca cuando se pulsa el botón de hibernación. -
HandleLidSwitch
: especifica qué acción se invoca cuando la tapa del portátil es cerrada.
La acción especificada puede ser una cualquiera de las siguientes: ignore
, poweroff
, reboot
, halt
, suspend
, hibernate
o kexec
.
Si estas opciones no están configuradas, systemd utilizará los valores predeterminados: HandlePowerKey=poweroff
, HandleSuspendKey=suspend
, HandleHibernateKey=hibernate
, y HandleLidSwitch=suspend
.
En los sistemas que funcionan sin configuración gráfica o solo un simple gestor de ventanas como i3 o awesome, esto puede reemplazar al demonio acpid que se utiliza generalmente para gestionar estos eventos ACPI.
En la versión actual de systemd, las opciones Handle
se aplican a todo el sistema, a menos que sean «inhibidas» (desactivadas temporalmente) por un programa, como un gestor de energía de un entorno de escritorio. Si estos inhibidores no son usados, se puede terminar en una situación en la que systemd suspenda el sistema, para luego, cuando se active el administrador de energía, este lo suspenda de nuevo.
Sleep hooks
Systemd no utiliza pm-utils para poner la máquina en reposo cuando usa systemctl suspend
, systemctl hibernate
o systemctl hybrid-sleep
; los hooks pm-utils, incluyendo cualesquiera hooks personalizados que se hayan creado, no se ejecutarán. Sin embargo, systemd proporciona dos mecanismos similares para ejecutar scripts personalizados para estos eventos.
Archivos de servicios para suspender/reanudar
Los archivos de servicios pueden ser asociados a suspend.target, hibernate.target y sleep.target para ejecutar acciones antes o después de suspender/hibernar. Deben crearse archivos separados para las acciones del usuario y las acciones de root/sistema. Para activar los archivos de servicios del usuario, ejecute: # systemctl enable suspend@<usuario> && systemctl enable resume@<usuario>
. Ejemplos:
/etc/systemd/system/suspend@.service
[Unit] Description=User suspend actions Before=sleep.target [Service] User=%I Type=forking Environment=DISPLAY=:0 ExecStartPre= -/usr/bin/pkill -u %u unison ; /usr/local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop' ExecStart=/usr/bin/sflock [Install] WantedBy=sleep.target
/etc/systemd/system/resume@.service
[Unit] Description=User resume actions After=suspend.target [Service] User=%I Type=simple ExecStartPre=/usr/local/bin/ssh-connect.sh ExecStart=/usr/bin/mysql -e 'slave start' [Install] WantedBy=suspend.target
Para las acciones de root/sistema (se activa con # systemctl enable root-suspend
):
/etc/systemd/system/root-suspend.service
[Unit] Description=Local system resume actions After=suspend.target [Service] Type=simple ExecStart=/usr/bin/systemctl restart mnt-media.automount [Install] WantedBy=suspend.target
/etc/systemd/system/root-resume.service
[Unit] Description=Local system suspend actions Before=sleep.target [Service] Type=simple ExecStart=-/usr/bin/pkill -9 sshfs [Install] WantedBy=sleep.target
Unos consejos útiles acerca de estos archivos de servicio (más información en man systemd.service
):
- Si está presente
Type=OneShot
, entonces puede utilizar múltiples líneasExecStart=
. De lo contrario, solo está permitida una línea ExecStart. No obstante, puede agregar más órdenes conExecStartPre
o mediante la separación de las órdenes con un punto y coma (véase el primer ejemplo de arriba —fíjese en los espacios en blanco antes y después del punto y coma... ¡estos son necesarios!—). - Una orden con un prefijo '-' causará un código de salida distinto de cero que será ignorado y la orden será tratada como cumplida.
- El mejor método para encontrar errores a fin de solucionar problemas con estos archivos de servicios es, por supuesto, con
journalctl
.
Hooks en /usr/lib/systemd/system-sleep
Systemd iniciará todos los archivos ejecutables ubicados en /usr/lib/systemd/system-sleep/
, y pasará dos argumentos a cada uno de ellos:
- Argument 1: o bien
pre
opost
, dependiendo de si la máquina se está durmiendo o despertando. - Argument 2:
suspend
,hibernate
ohybrid-sleep
, ependiendo de lo que se ha invocado.
A diferencia de pm-utils, systemd ejecutará estos scripts en paralelo y no uno tras el otro.
Las salidas de cualquier script personalizado se registrarán por systemd-suspend.service
, systemd-hibernate.service
o systemd-hybrid-sleep.service
. Se pueden ver las salidas en el journal de systemd:
# journalctl -b -u systemd-suspend
Tenga en cuenta que también puede utilizar sleep.target
, suspend.target
, hibernate.target
o hybrid-sleep.target
para conectar la unidad al estado de suspensión, en lugar de utilizar scripts personalizados.
He aquí un ejemplo de script personalizado:
/usr/lib/systemd/system-sleep/example.sh
#!/bin/sh case $1/$2 in pre/*) echo "Going to $2..." ;; post/*) echo "Waking up from $2..." ;; esac
Véanse man 7 systemd.special
y man 8 systemd-sleep
para obtener más información.
Los archivos temporales
Systemd-tmpfiles utiliza archivos de configuración en /usr/lib/tmpfiles.d/
y /etc/tmpfiles.d/
para describir la creación, limpieza y eliminación de archivos y directorios temporales y volátiles que normalmente residen en directorios como /run
o /tmp
. Cada archivo de configuración toma el nombre con el formato /etc/tmpfiles.d/<programa>.conf
. Esto sobreescribirá cualquier archivo en /usr/lib/tmpfiles.d/
con el mismo nombre.
Los tmpfiles se suministran normalmente junto con los archivos de servicios para crear directorios que se espera que existan para ciertos daemons. Por ejemplo, el demonio Samba espera que el directorio /var/run/samba
exista para obtener los permisos adecuados. El tmpfile correspondiente es similar a esto:
/usr/lib/tmpfiles.d/samba.conf
D /var/run/samba 0755 root root
Sin embargo, los tmpfiles también pueden ser usados para escribir en el arranque valores en ciertos archivos. Por ejemplo, si usa /etc/rc.local
para dehabilitar la reactivación del sistema («wakeup») a través de dispositivos USB con echo USBE > /proc/acpi/wakeup
, se puede utilizar, en su lugar, el siguiente tmpfile:
/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE
El método de los tmpfiles se recomienda en este caso en cuanto que systemd, en realidad, ya no admite /etc/rc.local
.
Consulte man 5 tmpfiles.d
para obtener más detalles.
Unidades
Un archivo de configuración de una unidad contiene información sobre un servicio, un socket, un dispositivo, un punto de montaje, un punto de automontaje, un archivo o partición swap, un objetivo de arranque, una ruta del archivo de sistema o un temporizador controlado y supervisado por systemd. La sintaxis de los archivos del tipo .desktop está basada en los estándares de «XDG Desktop Entry Specification», inspirados, a su vez, en los archivos .ini de Microsoft Windows.
Consulte man 5 systemd.unit
para obtener más información.
Transición de initscripts a systemd
Emulación de los initscripts
La integración con la configuración clásica de Arch es proporcionado por el paquete initscripts. Cuando initscripts se instala en paralelo con systemd, con el sistema corriendo en systemd, systemd hará lo siguiente:
- Analizar la matriz
DAEMONS
de/etc/rc.conf
e iniciar la lista de demonios al arranque. - Ejecutar
/etc/rc.local
durante el arranque. - Ejecutar
/etc/rc.local.shutdown
durante el apagado.
La emulación de los initscripts simplemente pretende ser una medida de transición para facilitar a los usuarios el cambio a systemd, y eventualmente poder volver atrás. Systemd nativo no se basa en la configuración centralizada de rc.conf
, por lo que se recomienda el uso de los archivos de configuración nativos de systemd, los cuales tendrán prioridad sobre /etc/rc.conf
.
/etc/rc.local
es escribir los archivos de servicios personalizados para cualquier cosa que desee ejecutar en el inicio del sistema. Consulte la sección correspondiente./etc/inittab
, tendrá que volver a configurar este ajuste para systemd ejecutando systemctl mask ctrl-alt-del.target
como root.Abandonar la línea DAEMONS
Para una configuración pura de systemd, debe eliminar completamente el archivo /etc/rc.conf
y habilitar los servicios únicamente mediante systemctl
. Para activar cada <nombre_del_servicio>
correlativo a los DAEMONS
de /etc/rc.conf
, ejecute:
# systemctl enable <nombre_del_servicio>
Si el <nombre_del_servicio>.service
no existe:
- Lo más probable es que systemd utilice otro nombre. Por ejemplo,
cronie.service
reemplaza el lanzamiento del demoniocrond
yalsa-restore.service
reemplaza el lanzamiento del demonioalsa
. Otro ejemplo importante es el demonionetwork
, que es reemplazado por otro conjunto de archivos de servicio (consulte Configuración de Red para más detalles.) - Por otro lado, el servicio puede no estar disponible para systemd. En ese caso, necesitará mantener
rc.conf
para iniciar dicho servicio durante el arranque.
- Por último, algunos servicios no necesitan ser explícitamente activados por el usuario. Por ejemplo,
dbus.service
se activará automáticamente cuandodbus-core
está instalado.alsa-store.service
yalsa-restore.service
también vienen habilitados automáticamente por systemd. Revise la lista de servicios disponibles y su estado utilizando la ordensystemctl
, como este:systemctl status <nombre_del_servicio>
.
Uso básico de systemctl
La principal orden para controlar systemd es systemctl
. Algunos de los posibles usos son el examen del estado del sistema, y la gestión del sistema y de los servicios. Consulte man 1 systemctl
para conocer más detalles.
systemadm
es el frontend gráfico oficial para systemctl
. Proporcionado por el paquete systemd-ui-gitAUR disponible en AUR.Analizar el estado del sistema
Listado de unidades activas:
$ systemctl
o bien:
$ systemctl list-units
Listado de unidades que han tenido problemas:
$ 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
Usar las unidades
Las unidades pueden ser, por ejemplo, servicios (.service
), puntos de montaje (.mount
), dispositivos (.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, sshd.socket
. 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,netcfg
ynetcfg.service
se consideran equivalentes. - Los puntos de montaje se traducirán automáticamente en la correspondiente unidad
.mount
. Por ejemplo, si especifica/home
será equivalente ahome.mount
. - Similar a los puntos de montaje, los dispositivos se traducen automáticamente en la correspondiente unidad
.device
, por lo tanto, la especificación/dev/sda2
es equivalente adev-sda2.device
.
Consulte man systemd.unit
para más detalles.
Activa una unidad de inmediato:
# systemctl start <unidad>
Desactiva 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á habilitada o no:
$ systemctl is-enabled <unidad>
Habilita el inicio automático en el arranque:
# systemctl enable <unidad>
Install
significa, por lo general, que se les llama de forma automática por otros servicios. Pero si necesita instalarlos manualmente, utilice la orden siguiente, reemplazando foo
con el nombre del servicio.
# ln -s /usr/lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/
Desactiva el inicio automático durante el arranque:
# systemctl disable <unidad>
Muestra la página del manual asociada con una unidad (esto tiene que ser apoyado por el archivo .unit):
$ systemctl help <unidad>
Recarga systemd, escaneando en busca de unidades nuevas o modificadas:
# systemctl daemon-reload
Administración de 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
Hibernación del sistema:
$ systemctl hibernate
Poner el sistema en estado de reposo híbrido —«hybrid-sleep» — (o suspensión combinada —«suspend-to-both»—):
$ systemctl hybrid-sleep
Iniciar un entorno de escritorio con systemd
Para habilitar el inicio de sesión gráfico, ejecute el demonio de su gestor de pantalla correspondiente (por ejemplo, KDM). Por el momento, existen los archivos de servicio para GDM, KDM, SLiM, XDM, LXDM y LightDM.
# systemctl enable kdm
Esto debería funcionar. Si no es así, podría ocurrir que tuviera un default.target
configurado manualmente o de una instalación anterior:
# ls -l /etc/systemd/system/default.target
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target
Solo tiene que eliminar el enlace simbólico y systemd utilizará el default.target
predefinido (es decir, graphical.target
).
# rm /etc/systemd/system/default.target
Usar systemd-logind
Con el fin de comprobar el estado de la sesión de usuario, puede utilizar loginctl
. Todas las acciones de PolicyKit, como suspender el sistema o el montaje de discos duros externos, deberían funcionar.
$ loginctl show-session $XDG_SESSION_ID
Escribir los archivos .service personalizados
Véase: Systemd/Services
Manejar las dependencias
Con systemd las dependencias pueden ser resueltas planificando 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 Requires=B
y After=B
a la sección [Unit]
de A
. Si la dependencia es opcional agregue, en su lugar, Wants=B
y After=B
. Tenga en cuenta que Wants=
y Requires=
no incluyen After=
, lo que significa que si After=
no esté especificado, las dos unidades se iniciarán en paralelo.
Las dependencias se colocan normalmente en los archivos .service y no en los .target. Por ejemplo, network.target
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 network.target
se inicia de todos modos.
Type
Existen diferentes tipos de arranque a tener en cuenta cuando se escribe un archivo de servicio personalizado. Esto se configura mediante el parámetro Type=
en la sección [Service]
. Consulte man systemd.service
para una explicación más detallada.
-
Type=simple
: 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. -
Type=forking
: 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énPIDFile=
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 establecerRemainAfterExit=
de modo que systemd sigue considerando el servicio como activo después de que el proceso haya terminado. -
Type=notify
: Igual queType=simple
, 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 porlibsystemd-daemon.so
. -
Type=dbus
: El servicio se considera listo cuando elBusName
especificado que aparece en el sistema bus es DBus.
Reemplazar las unidades suministradas
Las unidades en /etc/systemd/system/
tienen prioridad sobre las de /usr/lib/systemd/system/
.
Para mantener su propia versión de una unidad (que no será destruida después de una actualización), copie la antigua unidad de /usr/lib /
a /etc/
y haga los cambios allí. Alternativamente, puede utilizar .include
para analizar un archivo de servicio existente y sobrescribir o añadir nuevas opciones. Por ejemplo, si se desea simplemente agregar una dependencia adicional al servicio, puede utilizar:
/etc/systemd/system/<nombre-del-servicio>.service
.include /usr/lib/systemd/system/<nombre-del-servicio>.service [Unit] Requires=<dependencia nueva> After=<dependencia nueva>
A continuación, ejecute las siguientes órdenes para que los cambios surtan efecto:
# systemctl reenable <unidad> # systemctl restart <unidad>
Como los archivos de unidades proporcionados se actualizarán de vez en cuando, utilice systemd-delta para el mantenimiento del sistema.
Resaltar la sintaxis de las unidades de systemd con Vim
El resaltado de sintaxis para las unidades de systemd con Vim se puede activar mediante la instalación de vim-systemdAUR de AUR.
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 que imitan los niveles de ejecución de SystemVinit, es, por tanto, posible pasar de un target a otro utilizando la orden telinit RUNLEVEL
.
Conocer los targets presentes
La siguiente orden debe ser utilizada bajo systemd, en lugar del runlevel
:
# systemctl list-units --type=target
Crear un target personalizado
Los niveles de ejecución («runlevels») son asignados a un fin específico de la instalación vanilla de Fedora; 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 /etc/systemd/system/<su target>
que tome como base uno de los runlevels existentes (vea /usr/lib/systemd/system/graphical.target
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 habilitar.
Tabla de Targets
Runlevel 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. 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 presente
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 telinit 3
o telinit 5
en Sysvinit.
Cambiar el target predeterminado para arrancar
El target estándar es default.target
, que es un alias predefinido para graphical.target
(que corresponde al antiguo nivel de ejecución 5). Para cambiar el target predeterminado en el arranque, añada uno de los siguientes parámetros del kernel al gestor de arranque:
-
systemd.unit=multi-user.target
(que corresponde con el antiguo nivel de ejecución 3), -
systemd.unit=rescue.target
(que corresponde con el antiguo nivel de ejecución 1).
Como alternativa, se puede dejar el gestor de arranque inalterado y cambiar default.target
. Esto puede hacerse usando systemctl
:
# systemctl enable multi-user.target
El efecto de esta orden se puede ver en la salida de systemctl
; se crea un enlace simbólico al nuevo target prefedinido en /etc/systemd/system/default.target
. Esto funciona solo si:
[Install] Alias=default.target
reside en el archivo de configuración del target. En la actualidad, tanto multi-user.target
como graphical.target
lo tienen.
Journal
Desde la versión 38, systemd tiene un sistema de registro («log») propio llamado journal. Por tanto, ya no es necesario hacer funcionar el demonio syslog. Para leer el registro, utilice:
# journalctl
Por defecto (cuando Storage=
está definido como auto
en /etc/systemd/journald.conf
), journal escribe en /var/log/journal/
. Si el directorio /var/log/journal/
no existe (por ejemplo, si lo ha eliminado usted o algún programa), systemd no lo crea de forma automática, sino que escribe los registros en /run/systemd/journal
. Esto significa que los registros se perderán al reiniciar.
Filtrar la salida
journalctl
le permite filtrar los resultados por campos específicos.
Ejemplos:
Mostrar todos los mensajes del arranque:
# journalctl -b
Sin embargo, a veces a uno le interesan no los mensajes actuales, sino los mensajes desde el arranque anterior (por ejemplo, si ocurrió un fallo del sistema no recuperable). En la actualidad, esta función no está implementada, aunque hubo una discusión sobre ello en systemd-devel@lists.freedesktop.org (septiembre/octubre 2012).
Para solucionar este problema, de momento, se puede utilizar este argumento:
# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- Reboot --/q;p;n;b r}' | tac
entendiéndose que el arranque anterior se cuenta a partir de hoy. Tenga en cuenta que, si hay muchos mensajes para el día actual, la salida de esta orden puede consumir bastante tiempo.
Seguir los mensajes nuevos:
# journalctl -f
Mostrar todos los mensajes de un ejecutable específico:
# journalctl /usr/lib/systemd/systemd
Mostrar todos los mensajes de un proceso específico:
# journalctl _PID=1
Mostrar todos los mensajes por una unidad específica:
# journalctl -u netcfg
Véase man journalctl
, systemd.journal-fields
o esta entrada del blog de Lennert para obtener más detalles.
Límite del tamaño de journal
Si journal se ha creado como permanente (no volátil), el límite de su tamaño se establece con un valor predeterminado correspondiente al 10% del tamaño del sistema de archivos. Por ejemplo, con /var/log/journal
alojado en una partición raíz de 50 GiB, esto permitiría almacenar hasta 5 GiB de datos en journal. El tamaño máximo del journal permanente puede ser controlado por SystemMaxUse
en /etc/systemd/journald.conf
, por lo que, para limitarlo, por ejemplo, a 50 MiB, descomente y modifique la correspondiente línea a:
SystemMaxUse=50M
Consulte man journald.conf
para más información.
Journald coexistiendo con syslog
La compatibilidad con las implementaciones del clásico syslog se proporciona a través de un
socket: /run/systemd/journal/syslog
, por donde pasan todos los mensajes.
Para hacer que el demonio syslog funcione con journal, tiene que asociarlo a este socket en vez de a /dev/log
(anuncio oficial). El paquete syslog-ng de los repositorios proporciona automáticamente la configuración necesaria.
# systemctl enable syslog-ng
Optimización
Véase Improve Boot Performance.
Analizar el proceso de arranque
Usar systemd-analyze
Systemd proporciona una herramienta llamada systemd-analyze
que le permite analizar el proceso de arranque con el fin de mostrar qué unidades están causando ralentización en el proceso de arranque. Posteriormente, puede optimizar el sistema en consecuencia. Tiene que instalar python2-dbus y python2-cairo para usarlo.
Para ver cuánto tiempo ha empleado el arranque del espacio del kernel y del espacio del usuario, solo tiene que utilizar:
$ systemd-analyze
Para ver un listado de las unidades iniciadas, ordenadas según el tiempo que necesitan para comenzar, escriba:
$ systemd-analyze blame
También puede crear un archivo SVG que describe el proceso de arranque gráficamente, similar a Bootchart:
$ systemd-analyze plot > plot.svg
Usar bootchart2
Puede utilizar una versión de bootchart («trazado gráfico del arranque») para visualizar la secuencia de arranque. Puesto que no es posible poner un segundo init en la línea de órdenes del kernel, no será posible utilizar cualquiera de las configuraciones estándar de bootchart. Todavía, el paquete bootchart2AUR de AUR viene con un indocumentado servicio de systemd. Después de haber instalado bootchart2, escriba:
# systemctl enable bootchart
Consulte la documentación de bootchart para obtener más información sobre el uso de esta versión de bootchart.
Readahead
Systemd viene con su propia implementación de readahead («lectura previa»), esto debería, en principio, mejorar el tiempo de arranque. Sin embargo, dependiendo de la versión del kernel y del tipo de disco duro, el tiempo puede variar (por ejemplo, podría ser más lento). Para activarlo, escriba:
# systemctl enable systemd-readahead-collect systemd-readahead-replay
Recuerde que para que readahead despliegue su trabajo, tendrá que reiniciar un par de veces.
Solución de problemas
"Error: No space left on device" («Error: No queda espacio en el disco») al intentar iniciar/reiniciar un servicio
Nota: Puede que esta solución no sea adecuada, pero ha funcionado para algunos usuarios.
Véase este enlace: CrashPlan Support
Agradecimientos a Fedora Forum.
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 systemctl -u foounit.service
no muestra ninguna salida para un servicio de breve duración, compruebe el PID. Por ejemplo, si systemd-modules-load.service 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 journalctl -b _PID=123
. Los campos con metadatos para journal, como _SYSTEMD_UNIT y _COMM, se recogen en modo asíncrono y se basan en la carpeta /proc
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.
/var en una partición separada
Si systemd intenta crear tmpfiles antes de montar /var anule local-fs.target copiándolo en /etc
cp /usr/lib/systemd/system/local-fs.target /etc/systemd/system/local-fs.target
y añada la dependencia var.mount
Requires=var.mount After=var.mount
en la seccción [Unit].
Véase también
- Sitio Web Oficial
- Manual systemd
- Optimizaciones systemd
- FAQ
- Consejos y trucos
- Systemd para administradores (PDF)
- Acerca de systemd en Fedora Project
- Cómo depurar problemas en Systemd
- Two part artículo introductorio de la revista The H Open.
- Lennart's blog story
- status update
- status update2
- status update3
- Resumen más reciente
- Fedora's SysVinit to systemd cheatsheet