Difference between revisions of "Systemd (Español)"

From ArchWiki
Jump to: navigation, search
(LVM: Actualizar)
(flagged broken section links)
(Tag: wiki-scripts)
 
(33 intermediate revisions by 6 users not shown)
Line 2: Line 2:
 
[[Category:Daemons and system services (Español)]]
 
[[Category:Daemons and system services (Español)]]
 
[[Category:Boot process (Español)]]
 
[[Category:Boot process (Español)]]
 +
[[ar:Systemd]]
 +
[[de:Systemd]]
 +
[[el:Systemd]]
 
[[en:Systemd]]
 
[[en:Systemd]]
 +
[[fa:Systemd]]
 
[[fr:Systemd]]
 
[[fr:Systemd]]
 
[[it:Systemd]]
 
[[it:Systemd]]
 
[[ja:Systemd]]
 
[[ja:Systemd]]
 +
[[pt:Systemd]]
 
[[ru:Systemd]]
 
[[ru:Systemd]]
[[zh-CN:Systemd]]
+
[[zh-cn:Systemd]]
[[zh-TW:Systemd]]
+
[[zh-tw:Systemd]]
{{Article summary start|Sumario}}
+
{{Related articles start (Español)}}
{{Article summary text|Este artículo explica cómo instalar y configurar systemd.}}
+
{{Related|systemd/User (Español)}}
{{Article summary heading|Relacionado}}
+
{{Related|systemd/Timers}}
{{Article summary wiki|systemd/User (Español)}}
+
{{Related|systemd FAQ (Español)}}
{{Article summary wiki|Systemd/Services}}
+
{{Related|init Rosetta (Español)}}
{{Article summary wiki|Systemd FAQ (Español)}}
+
{{Related|Daemons List}}
{{Article summary wiki|Init Rosetta (Español)}}
+
{{Related|udev (Español)}}
{{Article summary wiki|udev (Español)}}
+
{{Related|Improve boot performance}}
{{Article summary end}}
+
{{Related articles end}}
 +
 
 
De la página web del [http://freedesktop.org/wiki/Software/systemd proyecto]:
 
De la página web del [http://freedesktop.org/wiki/Software/systemd 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 [[cgroups|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 (Español)|sysvinit]].»''
+
:''«'''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 [[cgroups|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.»''
  
 
{{Nota|Para conocer una explicación detallada del motivo por el cual Arch está cambiando a systemd, consulte este [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 post].}}
 
{{Nota|Para conocer una explicación detallada del motivo por el cual Arch está cambiando a systemd, consulte este [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 post].}}
 
Consulte también el [http://es.wikipedia.org/wiki/Systemd artículo de Wikipedia].
 
 
==Consideraciones previas antes de pasarse a systemd==
 
* Para una aproximación al tema son recomendables [http://freedesktop.org/wiki/Software/systemd/ 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 [[#Journal|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''' [https://bugs.archlinux.org/task/31377 no puede] ser usado al inicio del sistema.
 
 
==Instalación==
 
{{Nota|{{pkg|systemd}} y {{pkg|systemd-sysvcompat}} son utilizados de forma predeterminada en los nuevos soportes de instalación desde el [https://www.archlinux.org/news/systemd-is-now-the-default-on-new-installations/ 2012-10-13].}}
 
{{Nota|Si se está utilizando Arch Linux en un  [[wikipedia:es:Servidor_virtual_privado|VPS]], véase [https://wiki.archlinux.org/index.php/Virtual_Private_Server#Moving_your_VPS_from_initscripts_to_systemd la página apropiada].}}
 
El presente apartado está dirigido a las instalaciones de Arch Linux que siguen basándose en {{pkg|sysvinit}} e {{pkg|initscripts}} y que aún no han migrado a {{pkg|systemd}}.
 
 
# Instale {{pkg|systemd}} y añada a la [[Kernel parameters (Español)|línea de órdenes del kernel]] lo siguiente: {{ic|1=init=/usr/lib/systemd/systemd}}
 
# Una vez hecho, puede habilitar los servicios deseados mediente el uso de {{ic|systemctl enable <nombre_del_servicio>}} (los cuales equivalen aproximadamente a los demonios incluidos en la matriz {{ic|DAEMONS}} con [[Daemons List|nombres diferentes]]).
 
# Reinicie el sistema y compruebe que {{ic|systemd}} está realmente activo mediante la orden siguiente: {{ic|$ cat /proc/1/comm}}. Esta debería devolver la salida: {{ic|systemd}}.
 
# Asegúrese de que el nombre del equipo está configurado correctamente en systemd:  {{ic|hostnamectl set-hostname elnombredemiequipo}}.
 
# Proceda a eliminar {{pkg|initscripts}} y {{pkg|sysvinit}} del sistema e instale {{pkg|systemd-sysvcompat}}.
 
# Opcionalmente, retire el parámetro {{ic|1=init=/usr/lib/systemd/systemd}} en cuanto que ya no es necesario. {{pkg|systemd-sysvcompat}} proporciona init de forma predeterminada.
 
 
===Información complementaria ===
 
*Se si utiliza {{ic|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 [[Users and Groups (Español)|grupos]] ({{ic|sys}}, {{ic|disk}}, {{ic|lp}}, {{ic|network}}, {{ic|video}}, {{ic|audio}}, {{ic|optical}}, {{ic|storage}}, {{ic|scanner}}, {{ic|power}}, 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 [[Wikipedia:es:Lista_de_control_de_acceso|POSIX ACLs]] para dispositivos de audio/vídeo, y permitirá ciertas operaciones, como el montaje de discos extraíbles, a través de [[Udev_(Español)#Udisks|udisks]].
 
 
* Consulte el artículo sobre [[Network Configuration (Español)|Network Configuration]] para saber cómo configurar los targets de las conexiones de red.
 
 
==Configuración nativa==
 
 
{{Nota|Puede que tenga que crear estos archivos. Todos los archivos deben tener permisos {{ic|644}} y propiedad de {{ic|root:root}}.}}
 
 
===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 {{ic|/etc/vconsole.conf}}.
 
 
{{hc|/etc/vconsole.conf|<nowiki>
 
KEYMAP=es
 
FONT=Lat2-Terminus16
 
FONT_MAP=</nowiki>}}
 
 
{{Nota|Desde {{pkg|systemd}}-194, el ''kernel'' incorpora por defecto el tipo de letra y la distribución del teclado para ''us'' (''«EE.UU.»''), si las opciones {{ic|1=KEYMAP=}} y {{ic|1=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
 
 
<code>localectl</code> también se puede utilizar para establecer la distribución del teclado de X11:
 
 
# localectl set-x11-keymap es
 
 
Consulte {{ic|man 1 localectl}} y {{ic|man 5 vconsole.conf}} para más detalles.
 
 
* Para obtener más información, consulte [[Fonts#Console fonts|console fonts]] y [[KEYMAP (Español)|keymaps]].
 
 
=== Reloj del hardware ===
 
Systemd usará '''UTC''' para el reloj del hardware por defecto.
 
 
{{Sugerencia|Se aconseja tener un demonio [[Network Time Protocol daemon (Español)|Network Time Protocol]] activo para mantener la hora del sistema sincronizada con la hora de Internet y con la hora del reloj del hardware.}}
 
 
==== 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 [[wikipedia:es:UTC|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 ([[wikipedia:es: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 ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html 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 ([[wikipedia:es:Reloj_en_tiempo_real|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 ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx que utiliza ''localtime'']). Windows es capaz de gestionar la hora del reloj del hardware basándose en UTC con un [[Time (Español)#UTC_en_Windows|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 [[Network Time Protocol daemon (Español)|NTP]], como se sugirió anteriormente.
 
 
* Para más información, consulte [[Time (Español)|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 {{ic|/etc/modules-load.d/}}. Cada archivo de configuración es nombrado siguiendo el formato: {{ic|/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 {{ic|#}} o {{ic|;}} se ignoran. Por ejemplo:
 
 
{{hc|/etc/modules-load.d/virtio-net.conf|
 
# Cargar virtio-net.ko en el arranque
 
virtio-net}}
 
 
Consulte {{ic|man 5 modules-load.d}} para obtener más detalles.
 
 
==== Configurar las opciones de los módulos ====
 
 
Las opciones adicionales del módulo las debemos establecer en el archivo {{ic|/etc/modprobe.d/modprobe.conf}}.
 
 
Ejemplo:
 
 
* tenemos {{ic|/etc/modules-load.d/loop.conf}} con el módulo {{ic|loop}} para cargar durante el arranque.
 
 
* en el archivo {{ic|/etc/modprobe.d/modprobe.conf}} especificaremos las opciones adicionales, por ejemplo {{ic|options loop max_loop&#61;64}}
 
 
A continuación, la opción de nueva creación puede ser verificada a través de la orden {{ic|cat /sys/module/loop/parameters/max_loop}}
 
 
====Blacklisting====
 
 
Los módulos incluidos en blacklist (''«la lista negra»'') tienen el mismo comportamiento que con {{Pkg|initscripts}}, ya que en realidad están a cargo de {{Pkg|kmod}}. Consulte [[Kernel_modules_(Español)#Blacklisting|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 {{ic|/etc/fstab}} deberían funcionar igualmente.
 
 
Consulte {{ic|man 5 systemd.mount}} para más detalles.
 
 
====Montaje automático====
 
* Si tiene una partición {{ic|/home}} grande, tal vez sería mejor permitir que los servicios que no dependen de {{ic|/home}} se inicien, mientras {{ic|/home}} es comprobada. Esto se puede lograr mediante la adición de las siguientes opciones en la entrada de la partición {{ic|/home}} en fstab :
 
 
noauto,x-systemd.automount
 
 
Esto comprobará el sistema de archivos y montará {{ic|/home}} cuando se acceda a la misma por primera vez, y el kenel demorará todos los accesos a los archivos de {{ic|/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 {{ic|noauto,x-systemd.automount}}. Además, puede utilizar la opción {{ic|1=x-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 {{ic|noauto}} para las entradas correspondientes de {{ic|/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:
 
{{hc|/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 [[Mkinitcpio (Español)|initramfs]], habilite el servicio {{ic|lvm-monitoring}}, proporcionado por el paquete {{pkg|lvm2}}:
 
 
# systemctl enable lvm-monitoring
 
 
===ACPI administración de la energía===
 
 
Systemd puede manejar algunos eventos [[wikipedia:es:Advanced Configuration and Power Interface|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 {{ic|/etc/systemd/logind.conf}}:
 
* {{ic|HandlePowerKey}}: especifica qué acción se invoca cuando el botón de encendido se pulsa.
 
* {{ic|HandleSuspendKey}}: especifica qué acción se invoca cuando se pulsa el botón de suspensión.
 
* {{ic|HandleHibernateKey}}: especifica qué acción se invoca cuando se pulsa el botón de hibernación.
 
* {{ic|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: {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}} o {{ic|kexec}}.
 
 
Si estas opciones no están configuradas, systemd utilizará los valores predeterminados: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, y {{ic|1=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.
 
 
{{Nota|Ejecute {{ic|systemctl restart systemd-logind.service}} para que los cambios surtan efecto.}}
 
 
{{Nota|Systemd no puede manejar los eventos de AC y de Batería que realiza ACPI, así que sigue siendo necesario el uso de [[Laptop Mode Tools]] u otras herramientas similares a [[acpid]].}}
 
 
En la versión actual de systemd, las opciones {{ic|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.
 
 
{{Advertencia|Actualmente, los gestores de energía en las nuevas versiones de [[KDE]] y [[GNOME]] son los únicos que poseen los comandos necesarios  para «inhibir». Hasta tanto los otros lo hagan, tendrá que configurar manualmente las opciones {{ic|Handle}} a {{ic|ignore}} si desea gestionar los eventos ACPI con [[Xfce]], [[acpid]] u otros programas.}}
 
 
{{Nota|Systemd también puede utilizar otros [[wikipedia:es:Front-end_y_back-end|backends]] para suspender (como [[Uswsusp]] o [[TuxOnIce]]), en conjunción con el backend por defecto del ''kernel'', con el fin de poner el equipo en estado de suspensión o hibernación.}}
 
 
==== Sleep hooks ====
 
 
Systemd no utiliza [[pm-utils]] para poner la máquina en reposo cuando usa {{ic|systemctl suspend}}, {{ic|systemctl hibernate}} o {{ic|systemctl hybrid-sleep}}; los hooks [[pm-utils]], incluyendo cualesquiera [[Pm-utils#Creating_your_own_hooks|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: {{ic|# systemctl enable suspend@<usuario> && systemctl enable resume@<usuario>}}. Ejemplos:
 
 
{{hc|/etc/systemd/system/suspend@.service|2=<nowiki>
 
[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</nowiki>}}
 
 
{{hc|/etc/systemd/system/resume@.service|2=<nowiki>
 
[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</nowiki>}}
 
 
Para las acciones de root/sistema (se activa con {{ic|# systemctl enable root-suspend}}):
 
 
{{hc|/etc/systemd/system/root-suspend.service|2=<nowiki>
 
[Unit]
 
Description=Local system resume actions
 
After=suspend.target
 
 
[Service]
 
Type=simple
 
ExecStart=/usr/bin/systemctl restart mnt-media.automount
 
 
[Install]
 
WantedBy=suspend.target</nowiki>}}
 
 
{{hc|/etc/systemd/system/root-resume.service|2=<nowiki>
 
[Unit]
 
Description=Local system suspend actions
 
Before=sleep.target
 
 
[Service]
 
Type=simple
 
ExecStart=-/usr/bin/pkill -9 sshfs
 
 
[Install]
 
WantedBy=sleep.target</nowiki>}}
 
 
Unos consejos útiles acerca de estos archivos de servicio (más información en {{ic|man systemd.service}}):
 
* Si está presente {{ic|1=<nowiki>Type=OneShot</nowiki>}}, entonces puede utilizar múltiples líneas {{ic|1=<nowiki>ExecStart=</nowiki>}}. De lo contrario, solo está permitida una línea ExecStart. No obstante, puede agregar más órdenes con {{ic|ExecStartPre}} o mediante la separación de las órdenes con un punto y coma (véase el primer ejemplo de arriba &mdash;fíjese en los espacios en blanco antes y después del punto y coma... ¡estos son necesarios!&mdash;).
 
* 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 {{ic|journalctl}}.
 
 
===== Archivo de servicio combinando suspensión/reanudación =====
 
 
Con el archivo de servicio que combina suspender/reanudar, un solo  hook puede hacer todo el trabajo para las diferentes fases (sleep/resume) y para diferentes objetivos (suspend/hibernate/hybrid-sleep).
 
 
He aquí un ejemplo y su explicación:
 
 
{{hc|/etc/systemd/system/wicd-sleep.service|2=<nowiki>
 
[Unit]
 
Description=Wicd sleep hook
 
Before=sleep.target
 
StopWhenUnneeded=yes
 
 
[Service]
 
Type=oneshot
 
RemainAfterExit=yes
 
ExecStart=-/usr/share/wicd/daemon/suspend.py
 
ExecStop=-/usr/share/wicd/daemon/autoconnect.py
 
 
[Install]
 
WantedBy=sleep.target</nowiki>}}
 
 
* {{ic|1=<nowiki>RemainAfterExit=yes</nowiki>}}: Después de iniciado, el servicio se mantiene siempre activo hasta que se detenga explícitamente.
 
* {{ic|1=<nowiki>StopWhenUnneeded=yes</nowiki>}}: Cuando se activa, el servicio se detendrá después de que se detenga sleep.target.
 
* Debido a que sleep.target es apartado por suspend.target, hibernate.target y hybrid-sleep.target y sleep.target son en sí mismo un servicio StopWhenUnneeded, lo que nos garantiza que el hook iniciará/detendrá correctamente las diferentes tareas.
 
 
===== Hooks en /usr/lib/systemd/system-sleep =====
 
 
Systemd iniciará todos los archivos ejecutables ubicados en {{ic|/usr/lib/systemd/system-sleep/}}, y pasará dos argumentos a cada uno de ellos:
 
 
* Argument 1: o bien {{ic|pre}} o {{ic|post}}, dependiendo de si la máquina se está durmiendo o despertando.
 
* Argument 2: {{ic|suspend}}, {{ic|hibernate}} o {{ic|hybrid-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 {{ic|systemd-suspend.service}}, {{ic|systemd-hibernate.service}} o {{ic|systemd-hybrid-sleep.service}}. Se pueden ver las salidas en el [[Systemd (Español)#Journal|journal]] de systemd:
 
# journalctl -b -u systemd-suspend
 
 
Tenga en cuenta que también puede utilizar {{ic|sleep.target}}, {{ic|suspend.target}}, {{ic|hibernate.target}} o {{ic|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:
 
 
{{hc|/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}}
 
 
No debemos olvidarnos de hacer el script ejecutable:
 
# chmod a+x /usr/lib/systemd/system-sleep/example.sh
 
 
Véanse {{ic|man 7 systemd.special}} y {{ic|man 8 systemd-sleep}} para obtener más información.
 
 
===Los archivos temporales===
 
 
Systemd-tmpfiles utiliza archivos de configuración en {{ic|/usr/lib/tmpfiles.d/}} y {{ic|/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 {{ic|/run}} o {{ic|/tmp}}. Cada archivo de configuración toma el nombre con el formato {{ic|/etc/tmpfiles.d/<programa>.conf}}. Esto sobreescribirá cualquier archivo en {{ic|/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 {{ic|/var/run/samba}} exista para obtener los permisos adecuados. El tmpfile correspondiente es similar a esto:
 
{{hc|/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 {{ic|/etc/rc.local}} para dehabilitar la reactivación del sistema  (''«wakeup»'') a través de dispositivos USB con {{ic|echo USBE > /proc/acpi/wakeup}}, se puede utilizar, en su lugar, el siguiente tmpfile:
 
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
 
w /proc/acpi/wakeup - - - - USBE
 
}}
 
 
Consulte {{ic|man 5 tmpfiles.d}} para obtener más detalles.
 
 
{{nota|Este método puede no funcionar ajustando las opciones en {{ic|/sys}} desde el momento en que el servicio {{ic|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 {{ic|modinfo <module>}} y establecer esta opción con un [[Modprobe.d#Configuration|archivo config en {{ic|/etc/modprobe.d}}]].  De lo contrario, tendrá que escribir una [[Udev#About_udev_rules|regla udev]] para establecer el atributo apropiado tan pronto como el dispositivo lo reclame.}}
 
 
===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 {{ic|man 5 systemd.unit}} para obtener más información.
 
  
 
== Uso básico de systemctl==
 
== Uso básico de systemctl==
  
La principal orden para controlar systemd es {{ic|systemctl}}. Algunos de los posibles usos son el examen del estado del sistema, y la gestión del sistema y de los servicios. Consulte {{ic|man 1 systemctl}} para conocer más detalles.
+
La principal orden para controlar ''systemd'' es {{ic|systemctl}}. Algunos de los posibles usos son el examen del estado del sistema, y la gestión del sistema y de los servicios. Consulte {{ic|man 1 systemctl}} para conocer más detalles.
  
{{Sugerencia|Puede utilizar las siguientes órdenes {{ic|systemctl}} con el parámetro {{ic|-H <user>@<host>}} para controlar una instancia de systemd en una máquina remota. Esto utilizará [[SSH]] para conectarse a la instancia systemd remota.}}
+
{{Sugerencia|Puede utilizar las siguientes órdenes {{ic|systemctl}} con el parámetro {{ic|-H ''usario''@''host''}} para controlar una instancia de systemd en una máquina remota. Esto utilizará [[SSH]] para conectarse a la instancia systemd remota.}}
  
{{Nota|{{ic|systemadm}} es el frontend gráfico oficial para {{ic|systemctl}}. Proporcionado por el paquete {{AUR|systemd-ui-git}} disponible en [[AUR]].}}
+
{{Nota|{{ic|systemadm}} es el frontend gráfico oficial para {{ic|systemctl}}. Proporcionado por el paquete {{AUR|systemd-ui-git}}{{Broken package link|{{aur-mirror|systemd-ui-git}}}} disponible en [[AUR]].}}
  
 
=== Analizar el estado del sistema ===
 
=== Analizar el estado del sistema ===
 +
 
Listado de unidades activas:
 
Listado de unidades activas:
  
Line 349: Line 55:
 
{{bc|$ systemctl list-unit-files}}
 
{{bc|$ systemctl list-unit-files}}
  
===Usar las unidades===  
+
===Usar las unidades===
 +
 
 
Las unidades pueden ser, por ejemplo, servicios ({{ic|.service}}), puntos de montaje ({{ic|.mount}}), dispositivos ({{ic|.device}}) o sockets ({{ic|.socket}}).
 
Las unidades pueden ser, por ejemplo, servicios ({{ic|.service}}), puntos de montaje ({{ic|.mount}}), dispositivos ({{ic|.device}}) o sockets ({{ic|.socket}}).
  
Line 359: Line 66:
  
 
Consulte {{ic|man systemd.unit}} para más detalles.
 
Consulte {{ic|man systemd.unit}} para más detalles.
 +
 +
{{Sugerencia|La mayoría de las siguientes órdenes también funcionan si se especifican varias unidades, vea {{ic|man systemctl}} para más información.}}
  
 
Activa una unidad de inmediato:
 
Activa una unidad de inmediato:
  
{{bc|# systemctl start <unidad>}}
+
{{bc|# systemctl start ''unidad''}}
  
 
Desactiva una unidad de inmediato:
 
Desactiva una unidad de inmediato:
  
{{bc|# systemctl stop <unidad>}}
+
{{bc|# systemctl stop ''unidad''}}
  
 
Reinicia la unidad:
 
Reinicia la unidad:
  
{{bc|# systemctl restart <unidad>}}
+
{{bc|# systemctl restart ''unidad''}}
  
 
Hace que una unidad recargue su configuración:
 
Hace que una unidad recargue su configuración:
  
{{bc|# systemctl reload <unidad>}}
+
{{bc|# systemctl reload ''unidad''}}
  
 
Muestra el estado de una unidad, incluso si se está ejecutando o no:
 
Muestra el estado de una unidad, incluso si se está ejecutando o no:
  
{{bc|$ systemctl status <unidad>}}
+
{{bc|$ systemctl status ''unidad''}}
  
 
Comprueba si la unidad ya está habilitada o no:
 
Comprueba si la unidad ya está habilitada o no:
  
{{bc|$ systemctl is-enabled <unidad>}}
+
{{bc|$ systemctl is-enabled ''unidad''}}
  
Habilita el inicio automático en el arranque:
+
Activa el inicio automático en el arranque:
  
{{bc|# systemctl enable <unidad>}}
+
{{bc|# systemctl enable ''unidad''}}
  
{{Nota|Si los servicios no tienen una sección {{ic|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 {{ic|foo}} con el nombre del servicio.
+
{{Nota|Si los servicios no tienen una sección {{ic|[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 {{ic|foo}} con el nombre del servicio.
  
 
{{bc|# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/}}
 
{{bc|# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/}}
Line 396: Line 105:
 
Desactiva el inicio automático durante el arranque:
 
Desactiva el inicio automático durante el arranque:
  
{{bc|# systemctl disable <unidad>}}
+
{{bc|# systemctl disable ''unidad''}}
  
 
Muestra la página del manual asociada con una unidad (esto tiene que ser apoyado por el archivo .unit):
 
Muestra la página del manual asociada con una unidad (esto tiene que ser apoyado por el archivo .unit):
  
{{bc|$ systemctl help <unidad>}}
+
{{bc|$ systemctl help ''unidad''}}
  
Recarga systemd, escaneando en busca de unidades nuevas o modificadas:
+
Recarga ''systemd'', escaneando en busca de unidades nuevas o modificadas:
  
 
  # systemctl daemon-reload
 
  # systemctl daemon-reload
  
===Administración de la energía ===  
+
===Gestionar la energía ===  
Si se encuentra en una sesión local de {{ic|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.
+
 
 +
[[polkit]] es necesario para gestionar la energía. Si se encuentra en una sesión local de {{ic|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:
 
Apagado y reinicio del sistema:
Line 421: Line 131:
 
{{bc|$ systemctl suspend}}
 
{{bc|$ systemctl suspend}}
  
Hibernación del sistema:
+
Poner el sistema en hibernación:
  
 
{{bc|$ systemctl hibernate}}
 
{{bc|$ systemctl hibernate}}
  
Poner el sistema en estado de reposo híbrido &mdash;''«hybrid-sleep»'' &mdash; (o suspensión combinada &mdash;''«suspend-to-both»''&mdash;):
+
Poner el sistema en estado de reposo híbrido &mdash;''«hybrid-sleep»'' &mdash; (o suspensión combinada &mdash;''«suspend-to-both»''&mdash;):
  
 
  $ systemctl hybrid-sleep
 
  $ systemctl hybrid-sleep
  
==Iniciar un entorno de escritorio con systemd==
+
==Escribir archivos .service personalizados==
Para habilitar el inicio de sesión gráfico, ejecute el demonio de su [[Display Manager (Español)|gestor de pantalla]] correspondiente (por ejemplo, [[KDM]]). Por el momento, existen los archivos de servicio para [[GDM]], [[KDM]], [[SLiM]], [[XDM]], [[LXDM]] y [[LightDM]].
+
  
{{bc|# systemctl enable kdm}}
+
La sintaxis de los [[#Usar las unidades|archivos de unidad]] de ''systemd'' se inspira en los archivos .desktop de XDG Desktop Entry Specification, que, a su vez, están inspirados en los archivos .ini de Microsoft Windows.
  
Esto debería funcionar. Si no es así, podría ocurrir que tuviera un {{ic|default.target}} configurado manualmente o de una instalación anterior:
+
===Manejar las dependencias===
  
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}
+
Con ''systemd'' las dependencias  pueden ser resueltas planificando la unidad correctamente. El caso más típico es que la unidad {{ic|A}} requiere la unidad {{ic|B}} para poder funcionar, por lo que esta última debe iniciarse antes que {{ic|A}}. En ese caso, agregue {{ic|1=Requires=B}} y {{ic|1=After=B}} a la sección {{ic|[Unit]}} de {{ic|A}}. Si la dependencia es opcional agregue, en su lugar, {{ic|1 =Wants=B}} y {{ic|1=After=B}}. Tenga en cuenta que {{ic|1=Wants=}} y {{ic|1=Requires=}} no incluyen {{ic|1=After=}}, lo que significa que si {{ic|1=After=}} no esté especificado, las dos unidades se iniciarán en paralelo.
  
Solo tiene que eliminar el enlace simbólico y systemd utilizará el {{ic|default.target}} predefinido (es decir, {{ic|graphical.target}}).
+
Las dependencias se colocan normalmente en los archivos .service y no en los .target. Por ejemplo, {{ic|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 {{ic|network.target}} se inicia de todos modos.
  
{{bc|# rm /etc/systemd/system/default.target}}
+
===Type===
  
===Usar systemd-logind===
+
Existen diferentes tipos de arranque a tener en cuenta cuando se escribe un archivo de servicio personalizado. Esto se configura mediante el parámetro {{ic|1=Type=}} en la sección {{ic|[Service]}}. Consulte {{ic|man systemd.service}} para una explicación más detallada.
{{Nota|A partir de 2012-10-30, [[ConsoleKit]] ha sido reemplazado por [https://www.archlinux.org/news/consolekit-replaced-by-logind/ systemd-logind] como el método por defecto para acceder a entornos de escritorios.}}
+
* {{ic|1=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.
 +
* {{ic|1=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én {{ic|1=PIDFile=}} para que ''systemd'' puede realizar un seguimiento del proceso principal.
 +
* {{ic|1=Type=oneshot}}: Esto es útil para los scripts que hacen un solo trabajo y luego concluyen. Es posible que desee también establecer {{ic|1 =RemainAfterExit=yes}} de modo que ''systemd'' sigue considerando el servicio como activo después de que el proceso haya terminado.
 +
* {{ic|1=Type=notify}}: Igual que {{ic|1=Type=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 por {{ic|libsystemd-daemon.so}}.
 +
* {{ic|1=Type=dbus}}: El servicio se considera listo cuando el {{ic|BusName}} especificado aparece en el [[wikipedia:es:Bus_(informática)|bus]] del sistema [[wikipedia:es:D-Bus|DBus]].
  
Con el fin de comprobar el estado de la sesión de usuario, puede utilizar {{ic|loginctl}}. Todas las acciones de [[PolicyKit]], como suspender el sistema o el montaje de discos duros externos, deberían funcionar.
+
===Modificar los archivos de unidad suministrados===
  
  $ loginctl show-session $XDG_SESSION_ID
+
Para editar un archivo de unidad proporcionado por un paquete, podemos crear un directorio llamado {{ic|/etc/systemd/system/''unit''.d/}} por ejemplo {{ic|/etc/systemd/system/httpd.service.d/}} y colocar los archivos {{ic|*.conf}} en dicho directorio para reemplazarlos o añadir nuevas opciones. ''systemd'' analizará estos archivos {{ic|*.conf}} y los aplicará antes que los de la unidad original. Por ejemplo, si deseamos simplemente agregar una dependencia adicional a una unidad, podemos crear el siguiente archivo:
  
==Escribir los archivos .service personalizados==
+
{{hc|/etc/systemd/system/''unit''.d/customdependency.conf|2=
''Véase: [[Systemd/Services]]''
+
[Unit]
 +
Requires=''dependencia nueva''
 +
After=''dependencia nueva''}}
  
===Manejar las dependencias===
+
Siguiendo otro ejemplo, con el fin de reemplazar la directiva {{ic|ExecStart}} para una unidad que no es del tipo {{ic|oneshot}}, crearemos el siguiente archivo:
Con systemd las dependencias  pueden ser resueltas planificando la unidad correctamente. El caso más típico es que la unidad {{ic|A}} requiere la unidad {{ic|B}} para poder funcionar, por lo que esta última debe iniciarse antes que {{ic|A}}. En ese caso, agregue {{ic|1=Requires=B}} y {{ic|1=After=B}} a la sección {{ic|[Unit]}} de {{ic|A}}. Si la dependencia es opcional agregue, en su lugar, {{ic|1 =Wants=B}} y {{ic|1=After=B}}. Tenga en cuenta que {{ic|1=Wants=}} y {{ic|1=Requires=}} no incluyen {{ic|1=After=}}, lo que significa que si {{ic|1=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, {{ic|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 {{ic|network.target}} se inicia de todos modos.
+
{{hc|/etc/systemd/system/''unit''.d/customexec.conf|2=
 +
[Service]
 +
ExecStart=
 +
ExecStart=''orden nueva''
 +
}}
  
===Type===
+
Otro último ejemplo, para reiniciar automáticamente un servicio:
Existen diferentes tipos de arranque a tener en cuenta cuando se escribe un archivo de servicio personalizado. Esto se configura mediante el parámetro {{ic|1=Type=}} en la sección {{ic|[Service]}}. Consulte {{ic|man systemd.service}} para una explicación más detallada.
+
* {{ic|1=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.
+
* {{ic|1=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én {{ic|1=PIDFile=}} para que systemd puede realizar un seguimiento del proceso principal.
+
* {{ic|1=Type=oneshot}}: Esto es útil para los scripts que hacen un solo trabajo y luego concluyen. Es posible que desee también establecer {{ic|1 =RemainAfterExit=}} de modo que systemd sigue considerando el servicio como activo después de que el proceso haya terminado.
+
* {{ic|1=Type=notify}}: Igual que {{ic|1=Type=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 por {{ic|libsystemd-daemon.so}}.
+
* {{ic|1=Type=dbus}}: El servicio se considera listo cuando el {{ic|BusName}} especificado que aparece en el sistema bus es DBus.
+
  
===Editar los archivos de unidades suministradas===
+
{{hc|/etc/systemd/system/''unit''.d/restart.conf|2=
Para editar un archivo de unidad proporcionado por un paquete, podemos crear un directorio llamado {{ic|/etc/systemd/system/<unit>.d/}} por ejemplo {{ic|/etc/systemd/system/httpd.service.d/}}  y colocar los archivos {{ic|*.conf}} en dicho directorio para reemplazarlos o añadir nuevas opciones. Systemd analizará estos archivos {{ic|*.conf}} y los aplicará antes que los de la unidad original.  Por ejemplo, si deseamos simplemente agregar una dependencia adicional a una unidad, podemos crear el siguiente archivo:
+
[Service]
 
+
Restart=always
{{hc|/etc/systemd/system/<unit>.d/customdependency.conf|2=
+
RestartSec=30
[Unit]
+
}}
Requires=<new dependency>
+
After=<new dependency>}}
+
  
 
A continuación, ejecutaremos lo que sigue para que los cambios surtan efecto:
 
A continuación, ejecutaremos lo que sigue para que los cambios surtan efecto:
  
 
  # systemctl daemon-reload
 
  # systemctl daemon-reload
  # systemctl restart <unit>
+
  # systemctl restart ''unidad''
  
Alternativamente, podemos copiar el archivo de la antigua unidad desde {{ic|/usr/lib/systemd/system/}} a {{ic|/etc/systemd/system/}} y realizar los cambios allí. Un archivo de unidad ubicado en {{ic|/etc/systemd/system/}} siempre tiene preferencia sobre la misma unidad localizada en {{ic|/usr/lib/systemd/system/}}. Debemos tener en cuenta que cuando la unidad original localizada en {{ic|/usr/lib/}} ha cambiado debido a una actualización del paquete que lo suministra, estos cambios no se aplicarán automáticamente al archivo de unidad personalizada ubicado en {{ic|/etc/}}. Además, tendremos que volver a activar manualmente la unidad con la orden {{ic|systemctl reenable <unit>}}. Por consiguiente, se recomienda utilizar el método {{ic|*.conf}} descrito anteriormente.
+
Por otro lado, podemos copiar el archivo de la antigua unidad desde {{ic|/usr/lib/systemd/system/}} a {{ic|/etc/systemd/system/}} y realizar los cambios allí. Un archivo de unidad ubicado en {{ic|/etc/systemd/system/}} siempre tiene preferencia sobre la misma unidad localizada en {{ic|/usr/lib/systemd/system/}}. Debemos tener en cuenta que cuando la unidad original localizada en {{ic|/usr/lib/}} ha cambiado debido a una actualización del paquete que lo suministra, estos cambios no se aplicarán automáticamente al archivo de unidad personalizada ubicado en {{ic|/etc/}}. De este modo, tendremos que volver a activar manualmente la unidad con la orden {{ic|systemctl reenable ''unidad''}}. Por consiguiente, se recomienda utilizar el método {{ic|*.conf}} descrito anteriormente.
  
{{Sugerencia|Podemos utilizar la orden {{ic|systemd-delta}}  para ver qué archivos de la unidad han sido invalidados y cuáles han cambiado.}} Como los archivos de unidad suministrados se actualizarán de vez en cuando, es conveniente utilizar systemd-delta para tareas de mantenimiento del sistema.
+
{{Sugerencia|Podemos utilizar la orden '''systemd-delta''' para ver qué archivos de la unidad han sido invalidados y cuáles han cambiado.}} Como los archivos de unidad suministrados se actualizarán de vez en cuando, es conveniente utilizar systemd-delta para tareas de mantenimiento del sistema.
  
 
===Resaltar la sintaxis de las unidades de systemd con Vim===
 
===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 {{AUR|vim-systemd}} de [[Arch User Repository|AUR]].
+
 
 +
El resaltado de sintaxis para las unidades de ''systemd'' con [[Vim]] se puede activar mediante la instalación de {{Pkg|vim-systemd}} desde los [[Official repositories (Español)|repositorios oficiales]].
  
 
==Targets==
 
==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 {{ic|telinit RUNLEVEL}}.
+
 
 +
''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 {{ic|telinit RUNLEVEL}}.
  
 
===Conocer los targets presentes===
 
===Conocer los targets presentes===
La siguiente orden debe ser utilizada bajo systemd, en lugar del {{ic|runlevel}}:
+
 
 +
La siguiente orden debe ser utilizada bajo ''systemd'', en lugar de {{ic|runlevel}}:
 
{{bc|1=# systemctl list-units --type=target}}
 
{{bc|1=# systemctl list-units --type=target}}
  
 
===Crear un target personalizado ===  
 
===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 {{ic|/etc/systemd/system/<su target>}} que tome como base uno de los runlevels existentes (vea {{ic|/usr/lib/systemd/system/graphical.target}} como ejemplo), cree un directorio  {{ic|/etc/systemd/system/<su target>.wants}}, y haga un enlace a los servicios adicionales de {{ic|/usr/lib/systemd/system/}} que desea habilitar.
 
  
===Tabla de Targets===  
+
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 {{ic|/etc/systemd/system/''su target''}} que tome como base uno de los runlevels existentes (vea {{ic|/usr/lib/systemd/system/graphical.target}} como ejemplo), cree un directorio  {{ic|/etc/systemd/system/''su target''.wants}}, y haga un enlace a los servicios adicionales de {{ic|/usr/lib/systemd/system/}} que desea habilitar.
{| border="1"
+
 
 +
===Tabla de targets===  
 +
 
 +
{| class="wikitable"
 
!Runlevel de SysV!!Target de systemd!!Notas
 
!Runlevel de SysV!!Target de systemd!!Notas
 
|-
 
|-
Line 515: Line 230:
 
|}
 
|}
  
===Cambiar el target presente===
+
===Cambiar el target vigente===
En systemd los targets quedan expuestos a través de «target units». Se pueden cambiar de esta manera:
+
 
 +
En ''systemd'' los targets quedan expuestos a través de «target units». Se pueden cambiar de esta manera:
  
 
{{bc|# systemctl isolate graphical.target}}
 
{{bc|# systemctl isolate graphical.target}}
Line 523: Line 239:
  
 
===Cambiar el target predeterminado para arrancar===
 
===Cambiar el target predeterminado para arrancar===
El target estándar es {{ic|default.target}}, que es un alias predefinido para {{ic|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 [[kernel parameters|parámetros del kernel]] al gestor de arranque:
+
 
{{Sugerencia|La extensión {{ic|.target}} puede omitirse.}}
+
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 [[kernel parameters|parámetros del kernel]] al gestor de arranque:
 +
{{Sugerencia|La extensión ''.target'' puede omitirse.}}
 
* {{ic|1=systemd.unit=multi-user.target}} (que corresponde con el antiguo nivel de ejecución 3),
 
* {{ic|1=systemd.unit=multi-user.target}} (que corresponde con el antiguo nivel de ejecución 3),
 
* {{ic|1=systemd.unit=rescue.target}} (que corresponde con el antiguo nivel de ejecución 1).
 
* {{ic|1=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 {{ic|default.target}}. Esto puede hacerse usando {{ic|systemctl}}:
+
Como alternativa, se puede dejar el gestor de arranque inalterado y cambiar ''default.target''. Esto puede hacerse usando ''systemctl'':
 
{{bc|# systemctl enable multi-user.target}}
 
{{bc|# systemctl enable multi-user.target}}
  
El efecto de esta orden se puede ver en la salida de {{ic | systemctl}}; se crea un enlace simbólico al nuevo target prefedinido en {{ic|/etc/systemd/system/default.target}}. Esto funciona solo si:
+
El efecto de esta orden se puede ver en la salida de '' systemctl''; se crea un enlace simbólico al nuevo target prefedinido en {{ic|/etc/systemd/system/default.target}}. Esto funciona solo si:
 
  [Install]
 
  [Install]
 
  Alias=default.target
 
  Alias=default.target
reside en el archivo de configuración del target. En la actualidad, tanto {{ic|multi-user.target}} como {{ic|graphical.target}} lo tienen.
+
reside en el archivo de configuración del target. En la actualidad, tanto ''multi-user.target'' como ''graphical.target'' lo tienen.
 +
 
 +
==Archivos temporales==
 +
 
 +
«'''systemd-tmpfiles''' crea, elimina y limpia archivos y directorios volátiles y temporales.» Lee los archivos de configuración en {{ic|/etc/tmpfiles.d/}} y {{ic|/usr/lib/tmpfiles.d/}} 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 proveidos normalmente junto con los archivos de servicio, y reciben su nombre en el estilo {{ic|/usr/lib/tmpfiles.d/''programa''.conf}}. Por ejemplo, el demonio [[Samba]]  espera que el directorio  {{ic|/run/samba}} exista para obtener los permisos adecuados. Por tanto, el paquete {{Pkg|samba}} viene con esta configuración:
 +
{{hc|/usr/lib/tmpfiles.d/samba.conf|
 +
D /var/run/samba 0755 root root
 +
}}
 +
 
 +
Los archivos de configuración también pueden ser usados para escribir en el arranque valores en ciertos archivos. Por ejemplo, si usa {{ic|/etc/rc.local}} para dehabilitar la reactivación del sistema  (''«wakeup»'') a través de dispositivos USB con la orden {{ic|echo USBE > /proc/acpi/wakeup}}, se puede utilizar, en su lugar, el siguiente tmpfile:
 +
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
 +
w /proc/acpi/wakeup - - - - USBE
 +
}}
 +
 
 +
Consulte {{ic|systemd-tmpfiles}} y  {{ic|tmpfiles.d(5)}} para obtener más detalles.
 +
 
 +
{{nota|Este método puede no funcionar ajustando las opciones en {{ic|/sys}} desde el momento en que el servicio {{ic|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 {{ic|modinfo ''modulo''}} y establecer esta opción con un [[Modprobe.d#Configuration|archivo de configuración en /etc/modprobe.d]]{{Broken section link}}.  De lo contrario, tendrá que escribir una [[Udev#About_udev_rules|regla udev]] para establecer el atributo apropiado tan pronto como el dispositivo lo reclame.}}
 +
 
 +
== Temporizadores ==
 +
 
 +
''systemd'' puede reemplazar la funcionalidad cron en gran medida. Para más información, consulte [[systemd/Timers]].
  
 
== Journal==
 
== 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:
+
 
 +
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
 
  # journalctl
  
Por defecto (cuando {{ic|Storage&#61;}} está definido como {{ic|auto}} en {{ic|/etc/systemd/journald.conf}}), journal escribe en {{ic|/var/log/journal/}}. Si el directorio {{ic|/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 {{ic|/run/systemd/journal}}. Esto significa que los registros se perderán al reiniciar.
+
Por defecto, (cuando {{ic|Storage&#61;}} está definido como {{ic|auto}} en {{ic|/etc/systemd/journald.conf}}), journal escribe en {{ic|/var/log/journal/}}. Si el directorio {{ic|/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 {{ic|/run/systemd/journal}}. Esto significa que los registros se perderán al reiniciar.
 +
 
 +
{{Sugerencia|Si {{ic|/var/log/journal/}} reside en un sistema de archivos [[btrfs]] debería considerar la opción de desactivar [[Btrfs#Copy-On-Write_.28CoW.29|Copy-on-Write]] para el directorio:
 +
# chattr +C /var/log/journal
 +
}}
  
 
===Filtrar la salida ===  
 
===Filtrar la salida ===  
{{ic|journalctl}} le permite filtrar los resultados por campos específicos.
+
 
 +
{{ic|journalctl}} le permite filtrar los resultados por campos específicos. Tenga en cuenta que si hay muchos mensajes para mostrar o el filtrado que hay que hacer abarca mucho tiempo, la salida de esta orden puede retrasarse durante bastante tiempo.
  
 
Ejemplos:
 
Ejemplos:
Line 552: Line 297:
 
  # journalctl -b
 
  # 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 [http://comments.gmane.org/gmane.comp.sysutils.systemd.devel/6608 systemd-devel@lists.freedesktop.org] (septiembre/octubre 2012).
+
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 irrecuperable). Esto es posible pasando el parámetro {{ic|-b}}: {{ic|journalctl -b -0}} muestra los mensajes del arranque actual, {{ic|journalctl -b -1}} muestra los mensajes del arranque anterior, {{ic|journalctl -b -2}} muestra los mensajes desde los dos últimos arranques y así sucesivamente. Véase {{ic|man 1 journalctl}} para una descripción completa, dado que los argumentos que se pueden pasar a la orden hacen que el filtrado pueda ser mucho más potente.
 
+
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:
 
Seguir los mensajes nuevos:
Line 576: Line 315:
 
  # journalctl -u netcfg
 
  # journalctl -u netcfg
  
Véase {{ic|man journalctl}}, {{ic|systemd.journal-fields}} o esta [http://0pointer.de/blog/projects/journalctl.html entrada del blog] de Lennert para obtener más detalles.
+
Mostrar búfer circular del kernel:
 +
 
 +
# journalctl _TRANSPORT=kernel
 +
 
 +
Véase {{ic|man 1 journalctl}}, {{ic|man 7 systemd.journal-fields}} o esta [http://0pointer.de/blog/projects/journalctl.html entrada del blog] de Lennert para obtener más detalles.
  
 
===Límite del tamaño de journal===   
 
===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 {{ic|/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 {{ic|SystemMaxUse}} en {{ic|/etc/systemd/journald.conf}}, por lo que, para limitarlo, por ejemplo, a 50 MiB, descomente y modifique la correspondiente línea a:
 
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 {{ic|/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 {{ic|SystemMaxUse}} en {{ic|/etc/systemd/journald.conf}}, por lo que, para limitarlo, por ejemplo, a 50 MiB, descomente y modifique la correspondiente línea a:
 
{{bc|1=SystemMaxUse=50M}}
 
{{bc|1=SystemMaxUse=50M}}
Line 584: Line 328:
  
 
===Journald coexistiendo con syslog ===
 
===Journald coexistiendo con syslog ===
 +
 
La compatibilidad con las implementaciones del clásico syslog se proporciona a través de un
 
La compatibilidad con las implementaciones del clásico syslog se proporciona a través de un
 
socket: {{ic|/run/systemd/journal/syslog}}, por donde pasan todos los mensajes.
 
socket: {{ic|/run/systemd/journal/syslog}}, por donde pasan todos los mensajes.
Line 590: Line 335:
 
Podemos encontrar un buen tutorial de {{ic|journalctl}} [http://0pointer.de/blog/projects/journalctl.html aquí].
 
Podemos encontrar un buen tutorial de {{ic|journalctl}} [http://0pointer.de/blog/projects/journalctl.html aquí].
  
==Optimización==
+
=== Reenviar journald a /dev/tty12 ===
  
 +
En {{ic|/etc/systemd/journald.conf}} active lo siguiente:
  
{{merge|Improve Boot Performance|reason=Should be moved to the article covering this topic.}}
+
ForwardToConsole=yes
 +
TTYPath=/dev/tty12
 +
MaxLevelConsole=info
  
Véase [[Improve Boot Performance]].
+
Reinicie journald con {{ic|sudo systemctl restart systemd-journald}}.
  
=== Analizar el proceso de arranque ===
+
== Solución de problemas ==
==== Usar systemd-analyze ====
+
=== Investigar errores de systemd ===
Systemd proporciona una herramienta llamada {{ic|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 {{Pkg|python2-dbus}} y {{Pkg|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:
+
Como ejemplo, vamos a investigar un error con el servicio {{ic|systemd-modules-load}}:
  
$ systemd-analyze
+
'''1.''' Vamos a determinar los servicios de ''systemd'' que fallan al inicio:
 +
{{hc|1=$ systemctl --state=failed|2=
 +
systemd-modules-load.service  loaded '''failed failed'''  Load Kernel Modules
 +
}}
  
{{Sugerencia|
+
'''2.''' Encontramos un problema con el servicio {{ic|systemd-modules-load}}. Indaguemos un poco más:
* Si añadimos el hook {{ic|timestamp}} a la matriz {{ic|HOOKS}} del archivo {{ic|/etc/[[mkinitcpio]].conf}} y reconstruimos initramfs con la orden {{ic|mkinitcpio -p linux}}, systemd-analyze también será capaz de mostrar cuánto tiempo ha empleado initramfs.
+
{{hc|$ systemctl status systemd-modules-load|2=
* Si arrancamos mediante [[UEFI]] y usamos un cargador de arranque que implemente una [http://www.freedesktop.org/wiki/Software/systemd/BootLoader Interfaz de Gargador de Arranque] para systemd (que actualmente solo lo hace [[Gummiboot]]), systemd-analyze además, puede mostrar cuánto tiempo emplea el firmware de EFI y el propio gestor de arranque.}}
+
systemd-modules-load.service - Load Kernel Modules
 +
  Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
 +
  Active: '''failed''' (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago
 +
    Docs: man:systemd-modules-load.service(8).
 +
          man:modules-load.d(5)
 +
  Process: '''15630''' ExecStart=/usr/lib/systemd/systemd-modules-load ('''code=exited, status=1/FAILURE''')
 +
}}
  
Para ver un listado de las unidades iniciadas, ordenadas según el tiempo que necesitan para comenzar, escriba:
+
'''3.''' Ahora tenemos el identificador del proceso (PID) para investigar este error en profundidad. Escribimos la siguiente orden con el  {{ic|Process ID}} (en este caso: 15630):
+
{{hc|1=$ journalctl -b _PID=15630|2=
$ systemd-analyze blame
+
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. --
 +
Aug 25 11:48:13 mypc systemd-modules-load[15630]: '''Failed to find module 'blacklist usblp''''
 +
Aug 25 11:48:13 mypc systemd-modules-load[15630]: '''Failed to find module 'install usblp /bin/false''''
 +
}}
  
También puede crear un archivo SVG que describe el proceso de arranque gráficamente, similar a [[Bootchart]]:
+
'''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 {{ic|/etc/modules-load.d/}}:
 +
{{hc|$ ls -Al /etc/modules-load.d/|
 +
...
 +
-rw-r--r--  1 root root    79  1. Dez 2012  blacklist.conf
 +
-rw-r--r--  1 root root    1  2. Mär 14:30 encrypt.conf
 +
-rw-r--r--  1 root root    3  5. Dez 2012  printing.conf
 +
-rw-r--r--  1 root root    6 14. Jul 11:01 realtek.conf
 +
-rw-r--r--  1 root root    65  2. Jun 23:01 virtualbox.conf
 +
...
 +
}}
  
  $ systemd-analyze plot > plot.svg
+
'''5.''' El mensaje del error {{ic|Failed to find module 'blacklist usblp'}} puede estar relacionado con un mal ajuste de {{ic|blacklist.conf}}. Podemos desactivarlo insertando un signo '''#''' delante de cada opción que hemos descubierto que falla por medio del paso 3:
 +
{{hc|/etc/modules-load.d/blacklist.conf|
 +
'''#''' blacklist usblp
 +
'''#''' install usblp /bin/false
 +
}}
  
==== Usar systemd-bootchart ====
+
'''6.''' Ahora, intente iniciar {{ic|systemd-modules-load}}:
 +
$ 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.
  
Bootchart se ha fusionado en systemd desde el 17 de octubre, y se puede utilizar para arrancar tal como lo haría con el bootchart original. Agregue esto a la línea del kernel:
+
Si todo está bien, se puede verificar que el servicio se ha iniciado satisfactoriamente con:
 +
{{hc|$ systemctl status systemd-modules-load|2=
 +
systemd-modules-load.service - Load Kernel Modules
 +
  Loaded: '''loaded''' (/usr/lib/systemd/system/systemd-modules-load.service; static)
 +
  Active: '''active (exited)''' since So 2013-08-25 12:22:31 CEST; 34s ago
 +
    Docs: man:systemd-modules-load.service(8)
 +
          man:modules-load.d(5)
 +
Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
 +
Aug 25 12:22:31 mypc systemd[1]: '''Started Load Kernel Modules'''.
 +
}}
  
initcall_debug printk.time=y init=/usr/lib/systemd/systemd-bootchart
+
A menudo se puede resolver este tipo de problemas como se ha descrito arriba. Para indagar más, mire el epígrafe siguiente: «'''Diagnosticar problemas de arranque'''».
  
====Usar bootchart2====
+
=== Diagnosticar problemas de arranque ===
Puede utilizar una versión de [[wikipedia:es:Bootchart|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 {{AUR|bootchart2}} de [[AUR]] viene con un indocumentado servicio de systemd. Después de haber instalado bootchart2, escriba:
+
  
# systemctl enable bootchart
+
Arranque con esos parámetros en la línea de órdenes del kernel:
 +
{{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}}
  
Consulte la [https://github.com/mmeeks/bootchart documentación de bootchart] para obtener más información sobre el uso de esta versión de bootchart.
+
[http://freedesktop.org/wiki/Software/systemd/Debugging Más información sobre depuración de errores]
  
===Readahead===
+
===Apagar/reiniciar se hace terriblemente largo===
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
+
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 [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually este artículo].
  
Recuerde que para que readahead despliegue su trabajo, tendrá que reiniciar un par de veces.
+
=== Los procesos de corta duración parecen no registrar ninguna salida ===
  
==Solución de problemas ==
+
Si {{ic|systemctl -u foounit.service}} no muestra ninguna salida para un servicio de breve duración, compruebe el PID. Por ejemplo, si {{ic|systemd-modules-load.service}} falla, y {{ic|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 {{ic|journalctl -b _PID&#61;123}}. Los campos con metadatos para journal, como _SYSTEMD_UNIT y _COMM, se recogen en modo asíncrono y se basan en la carpeta {{ic|/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.
===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 [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually este artículo].
+
  
=== Los procesos de corta duración parecen no registrar ninguna salida ===
+
=== Desactivar el volcado de sucesos de journal respecto de las aplicaciones ===
  
Si {{ic|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 {{ic|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 {{ic|journalctl -b _PID&#61;123}}. Los campos con metadatos para journal, como _SYSTEMD_UNIT y _COMM, se recogen en modo asíncrono y se basan en la carpeta {{ic|/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.
+
Ejecute lo siguiente para sobrescribir la configuración de {{ic|/lib/sysctl.d/}}:
=== Diagnosticar problemas de arranque ===
+
# ln -s /dev/null /etc/sysctl.d/50-coredump.conf
 +
# sysctl kernel.core_pattern=core
  
Arranque con esos parámetros en la línea de órdenes del kernel:
+
Esto desactivará el registro de coredumps en journal.
{{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}}
+
  
[http://freedesktop.org/wiki/Software/systemd/Debugging Más información sobre depuración de errores]
+
Tenga en cuenta que el RLIMIT_CORE por defecto es 0, lo que significa que tampoco hay archivos básicos que escribir.
 +
Si quiere que dichos archivos existan, necesita añadir el valor «unlimit» para el tamaño del archivo básico con la siguiente orden:
 +
$ ulimit -c unlimited
 +
 
 +
Véase [http://www.freedesktop.org/software/systemd/man/sysctl.d.html sysctl.d] y [https://www.kernel.org/doc/Documentation/sysctl/kernel.txt the documentation for /proc/sys/kernel] para obtener más información.
 +
 
 +
=== Mensaje de error al reiniciar o apagar ===
 +
==== cgroup : option or name mismatch, new: 0x0 "", old: 0x4 "systemd" ====
 +
Véase [https://bbs.archlinux.org/viewtopic.php?pid=1372562#p1372562 este hilo] para mayor explicación.
 +
==== watchdog watchdog0: watchdog did not stop! ====
 +
Véase [https://bbs.archlinux.org/viewtopic.php?pid=1372562#p1372562 este hilo] para mayor explicación.
  
 
== Véase también ==
 
== Véase también ==
 +
 
*[http://www.freedesktop.org/wiki/Software/systemd Sitio Web Oficial]
 
*[http://www.freedesktop.org/wiki/Software/systemd Sitio Web Oficial]
*[http://0pointer.de/public/systemd-man/ Manual systemd]
+
*[[Wikipedia:systemd|Artículo de Wikipedia]]
*[http://freedesktop.org/wiki/Software/systemd/Optimizations Optimizaciones systemd]
+
*[http://0pointer.de/public/systemd-man/ Páginas del manual]
 +
*[http://freedesktop.org/wiki/Software/systemd/Optimizations Optimizar systemd]
 
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]
 
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]
 
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Consejos y trucos]
 
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Consejos y trucos]
*[http://0pointer.de/public/systemd-ebook-psankar.pdf Systemd para administradores (PDF)]
+
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd para Administradores (PDF)]
 
*[http://fedoraproject.org/wiki/Systemd Acerca de systemd en Fedora Project]
 
*[http://fedoraproject.org/wiki/Systemd Acerca de systemd en Fedora Project]
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems Cómo depurar problemas en Systemd]
+
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems Cómo depurar problemas en systemd]
 
*[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html Two] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html part] artículo introductorio de la revista ''The H Open''.
 
*[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html Two] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html part] artículo introductorio de la revista ''The H Open''.
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]
+
*[http://0pointer.de/blog/projects/systemd.html Historia del blog de Lennart]
*[http://0pointer.de/blog/projects/systemd-update.html status update]
+
*[http://0pointer.de/blog/projects/systemd-update.html Status update]
*[http://0pointer.de/blog/projects/systemd-update-2.html status update2]
+
*[http://0pointer.de/blog/projects/systemd-update-2.html Status update2]
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]
+
*[http://0pointer.de/blog/projects/systemd-update-3.html Status update3]
 
*[http://0pointer.de/blog/projects/why.html Resumen más reciente]
 
*[http://0pointer.de/blog/projects/why.html Resumen más reciente]
 
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]
 
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]
 +
*[[Allow users to shutdown|Configurar systemd para permitir apagar a los usuarios normales]]

Latest revision as of 17:04, 6 August 2016

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.»
Nota: Para conocer una explicación detallada del motivo por el cual Arch está cambiando a systemd, consulte este post.

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.

Sugerencia: Puede utilizar las siguientes órdenes systemctl con el parámetro -H usario@host para controlar una instancia de systemd en una máquina remota. Esto utilizará SSH para conectarse a la instancia systemd remota.
Nota: systemadm es el frontend gráfico oficial para systemctl. Proporcionado por el paquete systemd-ui-gitAUR[broken link: archived in aur-mirror] 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 y netcfg.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 a home.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 a dev-sda2.device.

Consulte man systemd.unit para más detalles.

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

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

Activa el inicio automático en el arranque:

# systemctl enable unidad
Nota: Si los servicios no tienen una sección [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

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 .service personalizados

La sintaxis de los archivos de unidad de systemd se inspira en los archivos .desktop de XDG Desktop Entry Specification, que, a su vez, están inspirados en los archivos .ini de Microsoft Windows.

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én PIDFile= 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 RemainAfterExit=yes de modo que systemd sigue considerando el servicio como activo después de que el proceso haya terminado.
  • Type=notify: Igual que Type=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 por libsystemd-daemon.so.
  • Type=dbus: El servicio se considera listo cuando el BusName especificado aparece en el bus del sistema DBus.

Modificar los archivos de unidad suministrados

Para editar un archivo de unidad proporcionado por un paquete, podemos crear un directorio llamado /etc/systemd/system/unit.d/ por ejemplo /etc/systemd/system/httpd.service.d/ y colocar los archivos *.conf en dicho directorio para reemplazarlos o añadir nuevas opciones. systemd analizará estos archivos *.conf y los aplicará antes que los de la unidad original. Por ejemplo, si deseamos simplemente agregar una dependencia adicional a una unidad, podemos crear el siguiente archivo:

/etc/systemd/system/unit.d/customdependency.conf
[Unit]
Requires=dependencia nueva
After=dependencia nueva

Siguiendo otro ejemplo, con el fin de reemplazar la directiva ExecStart para una unidad que no es del tipo oneshot, crearemos el siguiente archivo:

/etc/systemd/system/unit.d/customexec.conf
[Service]
ExecStart=
ExecStart=orden nueva

Otro último ejemplo, para reiniciar automáticamente un servicio:

/etc/systemd/system/unit.d/restart.conf
[Service]
Restart=always
RestartSec=30

A continuación, ejecutaremos lo que sigue para que los cambios surtan efecto:

# systemctl daemon-reload
# systemctl restart unidad

Por otro lado, podemos copiar el archivo de la antigua unidad desde /usr/lib/systemd/system/ a /etc/systemd/system/ y realizar los cambios allí. Un archivo de unidad ubicado en /etc/systemd/system/ siempre tiene preferencia sobre la misma unidad localizada en /usr/lib/systemd/system/. Debemos tener en cuenta que cuando la unidad original localizada en /usr/lib/ ha cambiado debido a una actualización del paquete que lo suministra, estos cambios no se aplicarán automáticamente al archivo de unidad personalizada ubicado en /etc/. De este modo, tendremos que volver a activar manualmente la unidad con la orden systemctl reenable unidad. Por consiguiente, se recomienda utilizar el método *.conf descrito anteriormente.

Sugerencia: Podemos utilizar la orden systemd-delta para ver qué archivos de la unidad han sido invalidados y cuáles han cambiado.
Como los archivos de unidad suministrados se actualizarán de vez en cuando, es conveniente utilizar systemd-delta para tareas de 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-systemd desde los repositorios oficiales.

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 telinit RUNLEVEL.

Conocer los targets presentes

La siguiente orden debe ser utilizada bajo systemd, en lugar de 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 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 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:

Sugerencia: La extensión .target puede omitirse.
  • 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.

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 /usr/lib/tmpfiles.d/ 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 proveidos normalmente junto con los archivos de servicio, y reciben su nombre en el estilo /usr/lib/tmpfiles.d/programa.conf. Por ejemplo, el demonio Samba espera que el directorio /run/samba exista para obtener los permisos adecuados. Por tanto, el paquete samba viene con esta configuración:

/usr/lib/tmpfiles.d/samba.conf
D /var/run/samba 0755 root root

Los archivos de configuración 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 la orden 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

Consulte systemd-tmpfiles y tmpfiles.d(5) 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[broken link: invalid section]. De lo contrario, tendrá que escribir una regla udev para establecer el atributo apropiado tan pronto como el dispositivo lo reclame.

Temporizadores

systemd puede reemplazar la funcionalidad cron en gran medida. Para más información, consulte systemd/Timers.

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.

Sugerencia: Si /var/log/journal/ reside en un sistema de archivos btrfs debería considerar la opción de desactivar Copy-on-Write para el directorio:
# chattr +C /var/log/journal

Filtrar la salida

journalctl le permite filtrar los resultados por campos específicos. Tenga en cuenta que si hay muchos mensajes para mostrar o el filtrado que hay que hacer abarca mucho tiempo, la salida de esta orden puede retrasarse durante bastante tiempo.

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 irrecuperable). Esto es posible pasando el parámetro -b: journalctl -b -0 muestra los mensajes del arranque actual, journalctl -b -1 muestra los mensajes del arranque anterior, journalctl -b -2 muestra los mensajes desde los dos últimos arranques y así sucesivamente. Véase man 1 journalctl para una descripción completa, dado que los argumentos que se pueden pasar a la orden hacen que el filtrado pueda ser mucho más potente.

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

Mostrar búfer circular del kernel:

# journalctl _TRANSPORT=kernel

Véase man 1 journalctl, man 7 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

Podemos encontrar un buen tutorial de journalctl aquí.

Reenviar journald a /dev/tty12

En /etc/systemd/journald.conf active lo siguiente:

ForwardToConsole=yes
TTYPath=/dev/tty12
MaxLevelConsole=info

Reinicie journald con sudo systemctl restart systemd-journald.

Solución de problemas

Investigar errores de systemd

Como ejemplo, vamos a investigar un error con el servicio systemd-modules-load:

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

2. Encontramos un problema con el servicio systemd-modules-load. Indaguemos un poco más:

$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: failed (Result: exit-code) since So 2013-08-25 11:48:13 CEST; 32s ago
     Docs: man:systemd-modules-load.service(8).
           man:modules-load.d(5)
  Process: 15630 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)

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

$ journalctl -b _PID=15630
-- Logs begin at Sa 2013-05-25 10:31:12 CEST, end at So 2013-08-25 11:51:17 CEST. --
Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'blacklist usblp'
Aug 25 11:48:13 mypc systemd-modules-load[15630]: Failed to find module 'install usblp /bin/false'

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 /etc/modules-load.d/:

$ ls -Al /etc/modules-load.d/
...
-rw-r--r--   1 root root    79  1. Dez 2012  blacklist.conf
-rw-r--r--   1 root root     1  2. Mär 14:30 encrypt.conf
-rw-r--r--   1 root root     3  5. Dez 2012  printing.conf
-rw-r--r--   1 root root     6 14. Jul 11:01 realtek.conf
-rw-r--r--   1 root root    65  2. Jun 23:01 virtualbox.conf
...

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

/etc/modules-load.d/blacklist.conf
# blacklist usblp
# install usblp /bin/false

6. Ahora, intente iniciar systemd-modules-load:

$ 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:

$ systemctl status systemd-modules-load
systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
   Active: active (exited) since So 2013-08-25 12:22:31 CEST; 34s ago
     Docs: man:systemd-modules-load.service(8)
           man:modules-load.d(5)
 Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
Aug 25 12:22:31 mypc systemd[1]: Started Load Kernel Modules.

A menudo se puede resolver este tipo de problemas como se ha descrito arriba. Para indagar más, mire el epígrafe siguiente: «Diagnosticar problemas de arranque».

Diagnosticar problemas de arranque

Arranque con esos parámetros en la línea de órdenes del kernel: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M

Más información sobre depuración de errores

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.

Desactivar el volcado de sucesos de journal respecto de las aplicaciones

Ejecute lo siguiente para sobrescribir la configuración de /lib/sysctl.d/:

# ln -s /dev/null /etc/sysctl.d/50-coredump.conf
# sysctl kernel.core_pattern=core

Esto desactivará el registro de coredumps en journal.

Tenga en cuenta que el RLIMIT_CORE por defecto es 0, lo que significa que tampoco hay archivos básicos que escribir. Si quiere que dichos archivos existan, necesita añadir el valor «unlimit» para el tamaño del archivo básico con la siguiente orden:

$ ulimit -c unlimited

Véase sysctl.d y the documentation for /proc/sys/kernel para obtener más información.

Mensaje de error al reiniciar o apagar

cgroup : option or name mismatch, new: 0x0 "", old: 0x4 "systemd"

Véase este hilo para mayor explicación.

watchdog watchdog0: watchdog did not stop!

Véase este hilo para mayor explicación.

Véase también