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

From ArchWiki
Jump to: navigation, search
(Reloj del hardware en localtime)
m (errores menores y actualizada fecha de revisión)
 
(98 intermediate revisions by 10 users not shown)
Line 1: Line 1:
 
{{Lowercase title}}
 
{{Lowercase title}}
[[Category:Daemons and system services (Español)]]
+
[[Category:Daemons (Español)]]
[[Category:Boot process (Español)]]
+
[[Category:Init (Español)]]
 +
[[Category:Logging (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-hans:Systemd]]
{{Article summary start|Sumario}}
+
[[zh-hant:Systemd]]
{{Article summary text|Este artículo explica cómo instalar y configurar systemd.}}
+
{{TranslationStatus (Español)|Systemd|2018-12-09|555139}}
{{Article summary heading|Relacionado}}
+
{{Related articles start (Español)}}
{{Article summary wiki|systemd/User (Español)}}
+
{{Related|systemd/User (Español)}}
{{Article summary wiki|Systemd/Services}}
+
{{Related|systemd/Timers (Español)}}
{{Article summary wiki|Systemd FAQ (Español)}}
+
{{Related|systemd FAQ (Español)}}
{{Article summary wiki|Init Rosetta (Español)}}
+
{{Related|init}}
{{Article summary wiki|udev (Español)}}
+
{{Related|Daemons (Español)}}
{{Article summary end}}
+
{{Related|udev (Español)}}
De la página web del [http://freedesktop.org/wiki/Software/systemd proyecto]:
+
{{Related|Improving performance/Boot process (Español)}}
 +
{{Related|Allow users to shutdown (Español)}}
 +
{{Related articles end}}
  
''«'''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 socket y [[D-Bus]] para la inicialización de daemons, permite el inicio de los daemons 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]].»''
+
De la [http://freedesktop.org/wiki/Software/systemd página web del proyecto]:
  
{{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].}}
+
: '' systemd '' es un conjunto de bloques básicos de compilación para un sistema Linux. Proporciona un gestor de sistemas y servicios que se ejecuta como PID 1 e inicia el resto del sistema. 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 demonios bajo demanda, realiza un seguimiento de los procesos con el uso de los [[cgroups|grupos de control]] de Linux, 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. systemd es compatible con los scripts de inicialización de SysV y LSB y funciona como un reemplazo de sysvinit. Otras partes incluyen un demonio de registro, utilidades para controlar la configuración básica del sistema, tales como el nombre del equipo, la fecha, la configuración regional, la lista de usuarios registrados y contenedores y máquinas virtuales en ejecución, cuentas del sistema, directorios y configuraciones de tiempo de ejecución y demonios para gestionar una configuración de red simple, sincronización horaria de la red, reenvío de registros y resolución de nombres.
  
Consulte también el [http://es.wikipedia.org/wiki/Systemd artículo de Wikipedia].
+
{{Nota|para una explicación detallada del motivo por el cual Arch cambió a ''systemd'', consulte esta [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 publicación del foro].}}
  
==Consideraciones previas antes de pasarse a systemd==
+
== Utilización básica de systemctl==
* 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==
+
La principal orden usada para conocer y controlar ''systemd'' es ''systemctl''. Algunos de los posibles usos son el examen del estado del sistema y la gestión del sistema o de los servicios. Consulte {{man|1|systemctl}} para conocer más detalles.
{{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}}
+
{{Sugerencia|
# 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]]).
+
* puede utilizar las siguientes órdenes ''systemctl'' con el parámetro {{ic|-H ''usario''@''host''}} para controlar una instancia de systemd en una máquina remota. Esto utilizará [[OpenSSH (Español)|SSH]] para conectarse a la instancia ''systemd'' remota;
# 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}}.
+
* lo usuarios de [[Plasma]] pueden instalar {{AUR|systemd-kcm}} como una interfaz gráfica para ''systemctl''. Después de instalar el módulo se agregará a ''Administración del sistema''.}}
# Asegúrese de que el nombre del host está configurado correctamente en systemd: {{ic|hostnamectl set-hostname myhostname}}.
 
# 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 ===
+
=== Analizar el estado del sistema ===
*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|optical}}, {{ic|audio}}, {{ic|scanner}}, etc.) para la mayoría de los casos con systemd. Los grupos pueden, incluso, causar alguna disfuncionalidad. Por ejemplo, el grupo de audio impedirá el cambio rápido de usuarios y permitirá que las aplicaciones bloqueen el software de mezcla. Cada inicio de sesión PAM proporciona una sesión logind, que, durante una sesión local, le dará permisos a través de [[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]].
 
*La eliminación del paquete {{Pkg|initscripts}} romperá la compatibilidad con {{ic|rc.conf}}. Tenga cuidado si tiene configurada una red estática con ellos o usa algunos demonios, que no han migrado aún a systemd. Vea la sección [[#Emulación de los initscripts|emular los initscripts]] para conocer más detalles sobre cómo pueden coexistir los dos sitemas.
 
* Si se montan dispositivos LVM en fstab el propio sistema se mantendrá en espera por ellos y arrojará ''time out'' («tiempo excedido»). Espere a que ''time out'' suceda e introduzca la contraseña de root en la consola de emergencia. A continuación, escriba {{ic |systemctl enable lvm}} para habilitar lvm en systemd. Después de otro reinicio los dispositivos LVM deberían estar disponibles.
 
  
==Configuración nativa==
+
Para mostrar el '''estado del sistema''' utilice:
  
{{Nota|Puede que tenga que crear estos archivos. Todos los archivos deben tener permisos '''644''' y propiedad de '''root:root'''.}}
+
$ systemctl status
  
=== Nombre del host ===
+
Para '''listar unidades en ejecución''':
  
El nombre del host (''«sistema anfitrión»'') está configurado en {{ic|/etc/hostname}}. El archivo no debe contener el dominio del sistema, si existe. Para configurar el nombre de host, escriba:
+
$ systemctl
  
# hostnamectl set-hostname '''elnombredemihost'''
+
o:
  
Consulte {{ic|man 5 hostname}} y {{ic|man 1 hostnamectl}} para más detalles.
+
$ systemctl list-units
  
He aquí un ejemplo del archivo:
+
Para '''listar unidades que han fallado''':
{{hc|/etc/hostname|
+
 
elnombredemihost
+
$ systemctl --failed
 +
 
 +
Los archivos de las unidades disponibles se pueden ver en {{ic|/usr/lib/systemd/system/}} y {{ic|/etc/systemd/system/}} (este último tiene prioridad). Puede ver un '''listado de las unidades instaladas''' con:
 +
 
 +
$ systemctl list-unit-files
 +
 
 +
=== Utilizar las unidades ===
 +
 
 +
Las unidades pueden ser, por ejemplo, services (''.service''), mount points (''.mount''), devices (''.device'') o sockets (''.socket'').
 +
 
 +
Cuando se usa ''systemctl'', por lo general, tiene que especificar el nombre completo de la unidad, incluyendo el sufijo, por ejemplo, {{ic|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, {{ic|netcfg}} y {{ic|netcfg.service}} se consideran equivalentes.
 +
* Los puntos de montaje se traducirán automáticamente en la correspondiente unidad ''.mount''. Por ejemplo, si especifica {{ic|/home}} será equivalente a {{ic|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 {{ic|/dev/sda2}} es equivalente a {{ic|dev-sda2.device}}.
 +
 
 +
Véase {{man|5|systemd.unit}} para más detalles.
 +
 
 +
{{Nota|algunos nombres de unidades contienen un signo {{ic|@}} (por ejemplo, {{ic|name@''string''.service}}): esto significa que son [http://0pointer.de/blog/projects/instances.html instancias] de una unidad ''plantilla'', cuyo nombre de archivo real no contiene la parte {{ic | '' string ''}} (por ejemplo, {{ic|name@.service}} ). {{ic|''string''}} se denomina al ''identificador de instancia'', y es similar a un argumento que se pasa a la unidad que sirve de plantilla cuando es llamada con el orden ''systemctl'': en el archivo de unidad se sustituirá el especificador {{ic|%i}}.
 +
 
 +
Para ser más precisos, ''antes'' de probar inicializar una instancia de unidad de plantilla {{ic|name@.suffix}}, ''systemd'' buscará una unidad con el nombre del archivo {{ic|name@string.suffix }} exacto, aunque por convención, tal «conflicto» ocurre raramente, es decir, la mayoría de los archivos de unidades que contienen un signo {{ic|@}} son plantillas. Además, si se llama a una unidad de plantilla sin un identificador de instancia, simplemente fallará, ya que el especificador {{ic|%i}} no puede ser sustituido.
 
}}
 
}}
  
=== Configurar el idioma ===
+
{{Sugerencia|la mayoría de las siguientes órdenes también funcionan si se especifican varias unidades, vea {{man|1|systemctl}} para más información.}}
  
El ajuste del idioma (''«locale»'') predeterminado del sistema se configura en {{ic|/etc/locale.conf}}. Para definir el idioma predeterminado, escriba:
+
'''Activa''' una unidad de inmediato:
  
  # localectl set-locale LANG="es_ES.UTF-8"
+
  # systemctl start ''unidad''
  
{{Nota|Antes establecer el idioma predeterminado, primero necesita habilitar uno de los ''locales'' disponibles para el sistema, eliminando el comentario delante de ellos en {{ic|/etc/locale.gen}} y, luego, ejecutar {{ic|locale-gen}} como root. La configuración regional del idioma establecida por {{ic|localectl}} será uno de los ''locales'' previamente '''descomentado''' en el archivo {{ic|/etc/locale.gen}}.}}
+
'''Detiene''' una unidad de inmediato:
  
Consulte {{ic|man 1 localectl}} y {{ic|man 5 locale.conf}} para más detalles.
+
# systemctl stop ''unidad''
  
* Para más información, consulte [[Locale (Español)|Locale]].
+
'''Reinicia''' la unidad:
  
He aquí un ejemplo del archivo:
+
# systemctl restart ''unidad''
  
{{hc|/etc/locale.conf|<nowiki>
+
Hace que una unidad '''recargue''' su configuración:
LANG=es_ES.UTF-8
 
</nowiki>}}
 
  
===Consola virtual ===
+
# systemctl reload ''unidad''
  
La configuración de la consola virtual (es decir, la distribución del teclado, la tipografía de la consola y el asignación de la consola) está definida en el archivo {{ic|/etc/vconsole.conf}}.
+
Muestra el '''estado''' de una unidad, incluso si se está ejecutando o no:
  
{{hc|/etc/vconsole.conf|<nowiki>
+
$ systemctl status ''unidad''
KEYMAP=es
 
FONT=Lat2-Terminus16
 
FONT_MAP=</nowiki>}}
 
  
{{Nota|Desde {{pkg|systemd}}-194, el ''kernel'' incorpora por defecto la tipografía y distribución del teclado para ''EE.UU.'', si las opciones {{ic|1=KEYMAP=}} y {{ic|1=FONT=}} están vacías o no se han establecido.}}
+
'''Comprueba''' si la unidad ya está activada o no:
  
Otra forma de establecer la distribución del teclado (''«keymap»'') es escribiendo:
+
$ systemctl is-enabled ''unidad''
  
# localectl set-keymap es
+
'''Activa''' una unidad para inicarse en el '''arranque''':
  
Esto tiene la ventaja de que también establece la misma distribución del teclado para su uso en X11.
+
# systemctl enable ''unidad''
  
Consulte {{ic|man 1 localectl}} y {{ic|man 5 vconsole.conf}} para más detalles.
+
'''Activa''' una unidad para inicarse en el '''arranque''' y lo '''inicia''' inmediatamente:
  
* Para obtener más información, consulte [[Fonts#Console fonts|console fonts]] y [[KEYMAP (Español)|keymaps]].
+
# systemctl enable --now ''unidad''
  
===Zona horaria===
+
'''Desactiva''' el inicio automático durante el arranque:
La zona horaria (''«timezone»'') se configura mediante la creación de un enlace simbólico adecuado de {{ic|/etc/localtime}}, que apunte a un archivo de información de zonas en {{ic|/usr/share/zoneinfo/}}. Para hacer esto de forma automática:
 
  
  # timedatectl set-timezone Europe/Madrid
+
  # systemctl disable ''unidad''
  
Véase {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} y {{ic|man 7 archlinux}} para obtener más detalles.
+
'''Enmascara''' una unidad para que sea imposible iniciarla (tanto de forma manual como de dependencia, lo que hace que el enmascaramiento sea peligroso):
  
Como alternativa, cree el enlace simbólico manualmente:
+
  # systemctl mask ''unidad''
  # ln -s ../usr/share/zoneinfo/Europe/Madrid /etc/localtime
 
  
=== Reloj del hardware ===
+
'''Desenmascara''' una unidad:
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.}}
+
# systemctl unmask ''unidad''
  
==== Reloj del hardware en localtime ====
+
Muestre la '''página del manual''' asociada a una unidad (esto debe ser compatible con el archivo de la unidad):
  
Si desea cambiar el horario del reloj del hardware (''«hardware clock»'') utilizando la hora local (''«localtime»'') -'''SERIAMENTE DESACONSEJADO'''-, escriba:
+
  $ systemctl help ''unidad''
  
  # timedatectl set-local-rtc true
+
'''Recarga''' la configuración de ''systemd'', buscando '''unidades nuevas o modificadas''':
  
Si desea que el reloj del hardware vuelva a estar ajustado a [[wikipedia:es:UTC|UTC]] (''Universal Time Coordinated''), escriba:
+
{{Nota|esto no le pide a las unidades modificadas que vuelvan a cargar sus propias configuraciones. Vea el ejemplo {{ic|reload}} de arriba.}}
  
  # timedatectl set-local-rtc false
+
  # systemctl daemon-reload
  
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).
+
=== Gestionar la energía ===
  
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.
+
[[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.
  
* Para más información, consulte [[Time (Español)|Time]].
+
Apagado y reinicio del sistema:
  
=== Módulos del kernel ===
+
$ systemctl reboot
  
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.
+
Apagado del sistema:
  
==== Cargar módulos extras en el arranque ====
+
$ systemctl poweroff
  
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:
+
Suspensión del sistema:
  
{{hc|/etc/modules-load.d/virtio-net.conf|
+
$ systemctl suspend
# Cargar virtio-net.ko en el arranque
 
virtio-net}}
 
  
Consulte {{ic|man 5 modules-load.d}} para obtener más detalles.
+
Poner el sistema en hibernación:
  
====Blacklisting====
+
$ systemctl hibernate
  
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.
+
Poner el sistema en estado de reposo híbrido &mdash;''«hybrid-sleep»'' &mdash; (o suspensión combinada &mdash;''«suspend-to-both»''&mdash;):
  
=== Montaje del sistema de archivos===
+
$ systemctl hybrid-sleep
  
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.
+
== Escribir archivos de unidad ==
  
Consulte {{ic|man 5 systemd.mount}} para más detalles.
+
La sintaxis de los [http://www.freedesktop.org/software/systemd/man/systemd.unit.html archivos de unidad] de ''systemd'' está inspirada en los archivos ''.desktop'' de la Especificación de Entrada del Escritorio XDG que a su vez están inspirados en los archivos ''.ini'' de Microsoft Windows. Los archivos de unidad se cargan desde varias ubicaciones (para ver la lista completa, ejecute {{ic|1=systemctl show --property=UnitPath}}),  pero los principales son (enumerados desde la prioridad más baja a la más alta):
  
====Montaje automático====
+
* {{ic|/usr/lib/systemd/system/}}: unidades proporcionadas por los paquetes instalados.
* 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 :
+
* {{ic|/etc/systemd/system/}}: unidades instaladas por el administrador del sistema.
  
noauto,x-systemd.automount
+
{{Nota|
 +
* Las rutas de carga son completamente diferentes cuando se ejecuta ''systemd'' en [[systemd/User#How it works|momdo usuario]].
 +
* Los nombres de las unidades del sistema solo pueden contener caracteres alfanuméricos ASCII, guiones bajos y puntos. Todos los demás caracteres deben reemplazarse por escapes «\x2d» de estilo C, o emplear su semántica predefinida ('@','-'). Consulte {{man|5|systemd.unit}} y {{man|1|systemd-escape}} para obtener más información.}}
  
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.
+
Mire las unidades instaladas por sus paquetes para obtener ejemplos, así como la [[http://www.freedesktop.org/software/systemd/man/systemd.service.html#Examples sección de ejemplo anotada] de {{man|5|systemd.service}}.
  
* 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.
+
{{Sugerencia|Los comentarios precedidos con {{ic|#}}, también se pueden usar en archivos de unidad, pero solo en líneas nuevas. No utilice los comentarios al final de la línea después de los parámetros de ''systemd'' o la unidad no se activará.}}
  
* 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:
+
=== Manejar las dependencias ===
{{hc|/etc/crypttab|data /dev/md0 /root/key noauto}}
 
  
==== LVM ====
+
Con ''systemd'' las dependencias  pueden ser resueltas diseñando la unidad correctamente. El caso más típico es que la unidad ''A'' requiere la unidad ''B'' para poder funcionar, por lo que esta última debe iniciarse antes que ''A''. En ese caso, agregue {{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.
  
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}}:
+
Las dependencias se colocan normalmente en los archivos .service y no en los [[#Targets]]. 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.
  
# systemctl enable lvm-monitoring
+
=== Tipos de servicios ===
  
Del mismo modo, si tiene un dispositivo LVM cifrado, montado posteriormente durante el arranque (por ejemplo de {{ic|/etc/crypttab}}), habilite {{ic|lvm-on-crypt.service}} (también proporcionado por el paquete {{pkg|lvm2}}):
+
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]}}.
  
# systemctl enable lvm-on-crypt
+
* {{ic|1=Type=simple}} (por defecto): ''systemd'' considera que el servicio debe iniciarse inmediatamente. El proceso no debe romperse. No utilice este tipo si otros servicios tienen que ser llamados por ese servicio, a menos que no sea activado por el socket.
 +
* {{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]].
 +
* {{ic|1=Type=idle}}: ''systemd'' retrasará la ejecución del binario del servicio hasta que se envíen todos los trabajos. Un comportamiento por cierto muy similar a {{ic|1=Type=simple}}.
  
===ACPI administración de la energía===
+
Consulte la página del manual [http://www.freedesktop.org/software/systemd/man/systemd.service.html#Type= systemd.service(5)]  para obtener una explicación más detallada de los valores {{ic|Type}}.
  
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}}:
+
=== Modificar los archivos de unidad suministrados ===
* {{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}}.
+
Para evitar conflictos con pacman, los archivos de unidad proporcionados por los paquetes no deben editarse directamente. Hay dos formas seguras de modificar una unidad sin tocar el archivo original: crear un nuevo archivo de unidad que [[#Reemplazar los archivos de unidad|sobrescriba la unidad original]] o crear [[#Archivos insertados|fragmentos para insertarlos]] que se aplican sobre la unidad original. Para ambos métodos, debe volver a cargar la unidad posteriormente para que los cambios surtan efectos. Esto se puede hacer editando la unidad con {{ic|systemctl edit}} (que recarga la unidad automáticamente) o recargando todas las unidades con:
  
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}}.
+
# systemctl daemon-reload
  
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.
+
{{Sugerencia|
 +
* Puede usar '' systemd-delta '' para ver qué archivos de la unidad se han sobrescrito o ampliado y qué se ha cambiado exactamente.
 +
* Utilice {{ic|systemctl cat ''unidad''}} para ver el contenido de un archivo de unidad y todos los fragmentos insertados asociados.
 +
}}
  
{{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]].}}
+
==== Reemplazar los archivos de unidad ====
  
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.
+
Para reemplazar el archivo de unidad {{ic|/usr/lib/systemd/system/''unit''}}, cree el archivo {{ic|/etc/systemd/system/''unit''}} y ''reactive'' la unidad para actualizar los enlaces simbólicos:
  
{{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. La nuevas versiones están implementando esta funcionalidad.}}
+
  # systemctl reenable ''unidad''
  
{{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.}}
+
Alternativamente, ejecute:
  
==== Sleep hooks ====
+
# systemctl edit --full ''unidad''
  
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.
+
Esto abre {{ic|/etc/systemd/system/''unit''}} en su editor (copiando la versión instalada si aún no existe) y la vuelve a cargar automáticamente cuando termina de editar.
  
===== Archivos de servicios para suspender/reanudar =====
+
{{Nota|las unidades de reemplazo seguirán usándose incluso si pacman actualiza las unidades originales en el futuro. Este método hace que el mantenimiento del sistema sea más difícil y, por lo tanto, se prefiere el siguiente enfoque.}}
  
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:
+
==== Archivos insertados ====
  
{{hc|/etc/systemd/system/suspend@.service|2=<nowiki>
+
Para crear fragmentos de archivos para insertar en el archivo de unidad {{ic|/usr/lib/systemd/system/''unit''}}, cree el directorio {{ic|/etc/systemd/system/''unit''.d/}} y coloque los archivos ''.conf '' allí para sobrescribir o agregar nuevas opciones. ''systemd'' analizará y aplicará estos archivos con preferencia a la unidad original.
[Unit]
 
Description=User suspend actions
 
Before=sleep.target
 
  
[Service]
+
La forma más fácil de hacer esto es ejecutar:
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]
+
# systemctl edit ''unidad''
WantedBy=sleep.target</nowiki>}}
 
  
{{hc|/etc/systemd/system/resume@.service|2=<nowiki>
+
Esto abre el archivo {{ic|/etc/systemd/system/''unit''.d/override.conf}} en su editor de texto (creándolo si es necesario) y vuelve a cargar automáticamente la unidad cuando haya terminado de editarla.
[Unit]
 
Description=User resume actions
 
After=suspend.target
 
  
[Service]
+
{{Nota|no todas las claves se pueden anular con archivos de inserción. Por ejemplo, para cambiar {{ic|1=Conflicts=}} [https://lists.freedesktop.org/archives/systemd-devel/2017-June/038976.html es necesario] un archivo de reemplazo.}}
User=%I
 
Type=simple
 
ExecStartPre=/usr/local/bin/ssh-connect.sh
 
ExecStart=/usr/bin/mysql -e 'slave start'
 
  
[Install]
+
==== Volver a la versión del proveedor ====
WantedBy=suspend.target</nowiki>}}
 
  
Para las acciones de root/sistema (se activa con {{ic|# systemctl enable root-suspend}}):
+
Para revertir cualquier cambio en una unidad realizada utilizando {{ic|systemctl edit}}, ejecute:
  
{{hc|/etc/systemd/system/root-suspend.service|2=<nowiki>
+
# systemctl revert ''unidad''
[Unit]
 
Description=Local system resume actions
 
After=suspend.target
 
  
[Service]
+
==== Ejemplos ====
Type=simple
 
ExecStart=/usr/bin/systemctl restart mnt-media.automount
 
  
[Install]
+
Por ejemplo, si simplemente desea agregar una dependencia adicional a una unidad, puede crear el siguiente archivo:
WantedBy=suspend.target</nowiki>}}
 
  
{{hc|/etc/systemd/system/root-resume.service|2=<nowiki>
+
{{hc|/etc/systemd/system/''unit''.d/customdependency.conf|2=
 
[Unit]
 
[Unit]
Description=Local system suspend actions
+
Requires=''dependencia nueva''
Before=sleep.target
+
After=''dependencia nueva''
 +
}}
 +
 
 +
Otro ejemplo, para reemplazar la directiva {{ic|ExecStart}} para una unidad que no sea del tipo {{ic|oneshot}}, cree el siguiente archivo:
  
 +
{{hc|/etc/systemd/system/''unit''.d/customexec.conf|2=
 
[Service]
 
[Service]
Type=simple
+
ExecStart=
ExecStart=-/usr/bin/pkill -9 sshfs
+
ExecStart=''orden nueva''
 +
}}
  
[Install]
+
Observe como {{ic|ExecStart}} debe quedar límpio antes de volver a reasignarse [https://bugzilla.redhat.com/show_bug.cgi?id=756787#c9]. Lo mismo se aplica a cada elemento que se puede especificar varias veces, por ejemplo {{ic|OnCalendar}} para los temporizadores.
WantedBy=sleep.target</nowiki>}}
 
  
Unos consejos útiles acerca de estos archivos de servicio (más información en {{ic|man systemd.service}}):
+
Un ejemplo más para reiniciar automáticamente un servicio:
* 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 válida.
 
* El mejor método para encontrar errores a fin de solucionar problemas con estos archivos de servicios es, por supuesto, con {{ic|journalctl}}.
 
  
===== Hooks en /usr/lib/systemd/system-sleep =====
+
{{hc|/etc/systemd/system/''unit''.d/restart.conf|2=
 +
[Service]
 +
Restart=always
 +
RestartSec=30
 +
}}
  
Systemd iniciará todos los archivos ejecutables ubicados en {{ic|/usr/lib/systemd/system-sleep/}}, y pasará dos argumentos a cada uno de ellos:
+
== Targets ==
  
* Argument 1: o bien {{ic|pre}} o {{ic|post}}, dependiendo de si la máquina se está durmiendo o despertando.
+
''systemd'' utiliza ''targets'' (''«objetivos»'') que sirven a un propósito similar a los [[wikipedia:es:Nivel de ejecución|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}}.
* 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.
+
=== Conocer los targets presentes ===
  
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:
+
La siguiente orden debe ser utilizada bajo ''systemd'', en lugar de {{ic|runlevel}}:
# 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.
+
$ systemctl list-units --type=target
  
He aquí un ejemplo de script personalizado:
+
=== Crear un target personalizado ===
  
{{hc|/usr/lib/systemd/system-sleep/example.sh|
+
Los niveles de ejecución (''«runlevels»'') que tenían un significado definido bajo sysvinit (es decir, 0, 1, 3, 5 y 6), tienen una correlación de 1:1 con un específico ''target'' de systemd. Desafortunadamente, no hay una buena manera de hacer lo mismo para los niveles de ejecución definidos por el usuario como son el 2 y el 4. Si se hace uso de estos últimos, se sugiere dar un nuevo nombre al ''target'' de ''systemd'' como {{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 activar.
#!/bin/sh
 
case $1/$2 in
 
  pre/*)
 
    echo "Going to $2..."
 
    ;;
 
  post/*)
 
    echo "Waking up from $2..."
 
    ;;
 
esac}}
 
  
Véanse {{ic|man 7 systemd.special}} y {{ic|man 8 systemd-sleep}} para obtener más información.
+
=== Correlación entre los niveles de ejecución de SysV y los targets de systemd ===
  
===Los archivos temporales===
+
{| class="wikitable"
 +
!Nivel de ejecución de SysV!!Target de systemd!!Notas
 +
|-
 +
| 0 || runlevel0.target, poweroff.target || Detiene el sistema.
 +
|-
 +
| 1, s, single || runlevel1.target, rescue.target || Modalidad de usuario único.
 +
|-
 +
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || Definidos por el usuario/específico del sistio. Preconfigurados a 3.
 +
|-
 +
| 3 || runlevel3.target, multi-user.target || Multiusuario, no gráfica. Los usuarios, por lo general, pueden acceder a través de múltiples consolas o a través de la red.
 +
|-
 +
| 5 || runlevel5.target, graphical.target || Multiusuario, gráfica. Por lo general, tiene todos los servicios del nivel de ejecución 3, además de un inicio de sesión gráfica.
 +
|-
 +
| 6 || runlevel6.target, reboot.target || Reinicia el sistema.
 +
|-
 +
| emergency || emergency.target || Consola de emergencia.
 +
|-
 +
|}
  
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.
+
=== Cambiar el target vigente ===
  
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:
+
En ''systemd'' los targets quedan expuestos a través de «target units». Se pueden cambiar de esta manera:
{{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:
+
  # systemctl isolate graphical.target
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
 
w /proc/acpi/wakeup - - - - USBE
 
}}
 
El método de los tmpfiles se recomienda en este caso en cuanto que systemd, en realidad, ya no admite {{ic|/etc/rc.local}}.
 
  
Consulte {{ic|man 5 tmpfiles.d}} para obtener más detalles.
+
Esto solo cambiará el target actual, y no tendrá ningún efecto sobre el siguiente arranque. Esto es equivalente a las órdenes {{ic|telinit 3}} o {{ic|telinit 5}} en Sysvinit.
  
===Unidades===  
+
=== Cambiar el target predeterminado para arrancar ===
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.
+
El target estándar es {{ic|default.target}}, que es un enlace simbólico para {{ic|graphical.target}}. Este se corresponde con el antiguo nivel de ejecución 5.  
  
==Transición de initscripts a systemd==
+
Para verificar el target actual con ''systemctl'', ejecute:
===Emulación de los initscripts ===
 
La integración con la configuración clásica de Arch es proporcionado por el paquete {{Pkg|initscripts}}. Cuando {{Pkg|initscripts}} se instala en paralelo con systemd, con el sistema corriendo en systemd, systemd hará lo siguiente:
 
  
# Analizar la matriz {{ic|DAEMONS}} de {{ic|/etc/rc.conf}} e iniciar la lista de demonios al arranque.
+
$ systemctl get-default
# Ejecutar {{ic|/etc/rc.local}} durante el arranque.
 
# Ejecutar {{ic|/etc/rc.local.shutdown}} durante el apagado.
 
  
La emulación de los initscripts simplemente pretende ser una medida de transición para facilitar a los usuarios el cambio a systemd, y '''eventualmente poder volver atrás'''. Systemd nativo no se basa en la configuración centralizada de {{ic|rc.conf}}, por lo que se recomienda el uso de los [[#Configuración nativa|archivos de configuración nativos de systemd]], los cuales tendrán prioridad sobre {{ic|/etc/rc.conf}}.
+
Para cambiar el target predeterminado para arrancar, cambie el enlace simbólico {{ic|default.target}}. Con ''systemctl'':
  
{{Nota|La forma recomendada para reemplazar {{ic|/etc/rc.local}} es escribir los archivos de servicios personalizados para cualquier cosa que desee ejecutar en el inicio del sistema. Consulte la [[##Escribir_los_archivos_.service_personalizados|sección]] correspondiente.}}
+
{{hc|1=# systemctl set-default multi-user.target|2=
 +
Removed /etc/systemd/system/default.target.
 +
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target.}}
  
{{Nota|Si desactivó {{keypress|Ctrl+Alt+Supr}} para reiniciar en {{ic|/etc/inittab}}, tendrá que volver a configurar este ajuste para systemd ejecutando {{ic|systemctl mask ctrl-alt-del.target}} como root.}}
+
Como alternativa, agregue uno de los siguientes [[kernel parameters (Español)|parámetros del kernel]] a su cargador de arranque:
  
=== Abandonar la línea DAEMONS ===
+
* {{ic|1=systemd.unit=multi-user.target}} (que corresponde aproximadamente al anterior nivel de ejecución 3),
 +
* {{ic|1=systemd.unit=rescue.target}} (que corresponde aproximadamente al anterior nivel de ejecución 1).
  
Para una configuración pura de systemd, debe eliminar completamente el archivo {{ic|/etc/rc.conf}} y habilitar los servicios únicamente mediante {{ic|systemctl}}. Para activar cada {{ic|<nombre_del_servicio>}}correlativo a los {{ic|DAEMONS}} de {{ic|/etc/rc.conf}}, ejecute:
+
=== Orden de los target por defecto ===
  
# systemctl enable <nombre_del_servicio>
+
Systemd elige el {{ic|default.target}} de acuerdo con el siguiente orden:
  
{{Sugerencia|Para conocer un listado de los demonios más comunes con sus equivalentes en initscripts y systemd, consulte [[Daemons List|esta tabla]].}}
+
# El parámetro del kernel se muestra arriba
 +
# Enlace simbólico de {{ic|/etc/systemd/system/default.target}}
 +
# Enlace simbólico de {{ic|/usr/lib/systemd/system/default.target}}
  
Si el {{ic|<nombre_del_servicio>.service}} no existe:
+
== Archivos temporales ==
* Lo más probable es que systemd utilice otro nombre. Por ejemplo,{{ic|cronie.service}} reemplaza el lanzamiento del demonio {{ic|crond}} y {{ic|alsa-restore.service}} reemplaza el lanzamiento del demonio {{ic|alsa}}. Otro ejemplo importante es el demonio {{ic|network}}, que es reemplazado por otro conjunto de archivos de servicio (consulte [[#Configuring Network_(Español)|Configuración de Red]] para más detalles.)
 
* Por otro lado, el servicio puede no estar disponible para systemd. En ese caso, necesitará mantener {{ic|rc.conf}} para iniciar dicho servicio durante el arranque.
 
  
{{Sugerencia|Puede mirar dentro de los paquetes que contienen los script de arranque de inicio de los demonios y los nombres de los servicios. Por ejemplo:
+
«''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.
# pacman -Ql cronie
 
[...]
 
cronie /etc/rc.d/crond                            #Demonio initscript listado en la matriz DAEMONS (no usado en una configuración «pura» de systemd)
 
[...]
 
cronie /usr/lib/systemd/system/cronie.service    #Servicio de systemd correspondiente al demonio
 
[...]
 
}}
 
  
* Por último, algunos servicios no necesitan ser explícitamente activados por el usuario. Por ejemplo, {{ic|dbus.service}} se activará automáticamente cuando {{ic|dbus-core}} está instalado. {{ic|alsa-store.service}} y {{ic|alsa-restore.service}} también vienen habilitados automáticamente por systemd. Revise la lista de servicios disponibles y su estado utilizando la orden {{ic|systemctl}}, como este: {{ic|systemctl status <nombre_del_servicio>}}.
+
Los archivos de configuración son proveídos 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:
  
== Uso básico de systemctl==
+
{{hc|/usr/lib/tmpfiles.d/samba.conf|
 +
D /run/samba 0755 root root}}
  
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.
+
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:
  
{{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.}}
+
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
 +
#    Path                  Mode UID  GID  Age Argument
 +
w    /proc/acpi/wakeup    -    -    -    -   USBE}}
  
{{Nota|{{ic|systemadm}} es el frontend gráfico oficial para {{ic|systemctl}}. Proporcionado por el paquete {{AUR|systemd-ui-git}} disponible en [[AUR]].}}
+
Consulte las páginas de los manuales {{man|8|systemd-tmpfiles}} y {{man|5|tmpfiles.d}} para obtener más detalles.
  
=== Analizar el estado del sistema ===
+
{{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 [[Kernel modules#Setting module options|archivo de configuraición en /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.}}
Listado de unidades activas:
 
  
{{bc|$ systemctl}}
+
== Temporizadores ==
  
o bien:
+
Un temporizador es un archivo de configuración de unidad cuyo nombre termina en ''.timer'' y codifica información sobre un temporizador controlado y supervisado por ''systemd'', para la activación basada en plazos de tiempo. Consulte [[systemd/Timers]].
  
{{bc|$ systemctl list-units}}
+
{{Nota|los temporizadores pueden reemplazar la funcionalidad de [[cron]] en gran medida. Consulte [[systemd/Timers#As a cron replacement]].}}
  
Listado de unidades que han tenido problemas:
+
== Montaje ==
  
{{bc|$ systemctl --failed}}
+
''systemd'' se encarga de montar las particiones y los sistemas de archivos especificados en {{ic|/etc/fstab}}. El script {{man|8|systemd-fstab-generator}} traduce todas las entradas presentes en {{ic|/etc/fstab}} en unidades de systemd, esto se realiza en el momento del arranque y cada vez que se vuelve a cargar la configuración del gestor del sistema.
  
Los archivos de las unidades disponibles se pueden ver en {{ic|/usr/lib/systemd/system/}} y {{ic|/etc/systemd/system/}} (este último tiene prioridad). Puede ver un listado de las unidades instaladas con:
+
''systemd'' extiende las habituales capacidades de [[fstab]] y ofrece opciones de montaje adicionales. Esto afecta a las dependencias de la unidad de montaje; por ejemplo, se puede garantizar que un montaje se realice solo una vez que la red esté activa o solo cuando se monte otra partición. La lista completa de las opciones de montaje específicas de ''systemd'', que generalmente llevan el prefijo {{ic|x-systemd.}}, se detalla en {{man|5|systemd.mount|FSTAB}}.
{{bc|$ systemctl list-unit-files}}
 
  
===Usar las unidades===
+
En [[fstab#Automount with systemd]] se proporciona un ejemplo de estas opciones de montaje en el contexto del ''automontaje'', pensando en aquellos recursos que se deben montar tan solo cuando se les requiere en lugar de automáticamente en el momento del arranque.
Las unidades pueden ser, por ejemplo, servicios ({{ic|.service}}), puntos de montaje ({{ic|.mount}}), dispositivos ({{ic|.device}}) o sockets ({{ic|.socket}}).
 
  
Cuando se usa {{ic|systemctl}}, por lo general, tiene que especificar el nombre completo de la unidad, incluyendo el sufijo, por ejemplo, {{ic|sshd.socket}}. Sin embargo, hay unos pocos atajos cuando se especifica la unidad en las siguientes órdenes {{ic|systemctl}}:
+
===Montaje automático de particiones GPT ===
  
* Si no se especifica el sufijo, systemctl asumirá que es {{ic|.service}}. Por ejemplo, {{ic|netcfg}} y {{ic|netcfg.service}} se consideran equivalentes.
+
En un disco particionado con [[Partitioning_(Español)#GUID_Partition_Table|GPT]], el script {{man|8|systemd-gpt-auto-generator}} montará particiones siguiendo la [https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ especificación de particiones detectables] , por lo tanto, las mismas se pueden omitir de {{ic|fstab}}.
* Los puntos de montaje se traducirán automáticamente en la correspondiente unidad {{ic|.mount}}. Por ejemplo, si especifica {{ic|/home}} será equivalente a {{ic|home.mount}}.
 
* Similar a los puntos de montaje, los dispositivos se traducen automáticamente en la correspondiente unidad {{ic|.device}}, por lo tanto, la especificación {{ic|/dev/sda2}} es equivalente a {{ic|dev-sda2.device}}.
 
  
Consulte {{ic|man systemd.unit}} para más detalles.
+
El montaje automático de una partición se puede desactivar cambiando el [[Wikipedia:GUID Partition Table#Partition type GUIDs|tipo GUID]] de la partición o configurando el atributo 63 "do not automount" para la partición en cuestión, véase [[gdisk#Prevent GPT partition automounting]].
  
Activa una unidad de inmediato:
+
== Journal ==
  
{{bc|# systemctl start <unidad>}}
+
''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:
  
Desactiva una unidad de inmediato:
+
# journalctl
  
{{bc|# systemctl stop <unidad>}}
+
En Arch Linux, el directorio  {{ic|/var/log/journal/}} es parte del paquete {{Pkg|systemd}}, y journal (cuando {{ic|1=Storage=}} está definido a {{ic|auto}} en {{ic|/etc/systemd/journald.conf}}) escribirá en {{ic|/var/log/journal/}}. Si usted o algún programa eliminan ese directorio, ''systemd'' '''no''' lo volverá a crear automáticamente y en su lugar escribirá sus registros en {{ic|/run/systemd/journal}} de una manera no persistente. Sin embargo, la carpeta se volverá a crear cuando establezca {{ic|1=Storage=persistent}} y [[#Utilizar las unidades|reinicie]] {{ic|systemd-journald.service}} (o reinicie el equipo).
  
Reinicia la unidad:
+
El journald de systemd clasifica los mensajes por [[#Nivel de prioridad]] y [[#Nivel del recurso]]. La clasificación del registro corresponde al protocolo clásico de [[wikipedia:es:Syslog|Syslog]] ([https://tools.ietf.org/html/rfc5424 RFC 5424]).
  
{{bc|# systemctl restart <unidad>}}
+
=== Nivel de prioridad ===
  
Hace que una unidad recargue su configuración:
+
Se utiliza el código de severidad de syslog (en systemd llamado prioridad) para marcar la importancia de un mensaje  [https://tools.ietf.org/html/rfc5424#section-6.2.1 RFC 5424 Section 6.2.1].
  
{{bc|# systemctl reload <unidad>}}
+
{| class="wikitable"
 +
|-
 +
! Valor !! Severidad !! Palabra clave  !! Descripción || Ejemplos
 +
|-
 +
| 0 || Emergencia || emerg || El sistema está inutilizable || Bug importante del kernel, núcleo de systemd volcado.<br>Este nivel no debe ser utilizado por las aplicaciones.
 +
|-
 +
| 1 || Alerta || alert || Debe corregirse inmediatamente || El subsistema vital parece no funcionar. Pérdida de datos. <br>{{ic|kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc|}}.
 +
|-
 +
| 2 || Crítico || crit || Condiciones criticas || Quiebra, volcado del núcleo. Tales como:<br>{{ic|systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core}}<br> Error en la aplicación principal del sistema, como X11.
 +
|-
 +
| 3 || Error || err || Condiciones de error || Se informa de error no grave:<br>{{ic|kernel: usb 1-3: 3:1: cannot get freq at ep 0x84}},<br>{{ic|systemd[1]: Failed unmounting /var.}},<br>{{ic|libvirtd[1720]: internal error: Failed to initialize a valid firewall backend}}).
 +
|-
 +
| 4 || Advertencia || warning || Puede indicar que se producirá un error si no se toman medidas. || Un sistema de archivos no root tiene solo 1GB libre.<br>{{ic|org.freedesktop. Notifications[1860]: (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale}}.
 +
|-
 +
| 5 || Aviso || notice || Eventos que son inusuales, pero que no presuponen un error. || {{ic|systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway}}. {{ic|gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged}}.
 +
|-
 +
| 6 || Informativo || info || Mensajes de operaciones normales que no requieren ninguna acción.  || {{ic|lvm[585]:  7 logical volume(s) in volume group "archvg" now active}}.
 +
|-
 +
| 7 || Depuración errores || debug || Información útil para los desarrolladores para depurar errores de la aplicación. || {{ic|kdeinit5[1900]: powerdevil: Scheduling inhibition from ":1.14" "firefox" with cookie 13 and reason "screen"}}.
 +
|}
  
Muestra el estado de una unidad, incluso si se está ejecutando o no:
+
Si no puede encontrar un mensaje en el nivel de prioridad esperado, puede buscar también un par de niveles por encima y por debajo: estas reglas son recomendaciones y el desarrollador de la aplicación afectada puede tener una percepción diferente de la importancia del problema con respecto a la suya.
  
{{bc|$ systemctl status <unidad>}}
+
=== Nivel del recurso ===
  
Comprueba si la unidad ya está habilitada o no:
+
Se utiliza un código de recursos de syslog para especificar el tipo de programa que está registrando el mensaje [https://tools.ietf.org/html/rfc5424#section-6.2.1 RFC 5424 Section 6.2.1].
  
{{bc|$ systemctl is-enabled <unidad>}}
+
{| class="wikitable"
 +
! Código del recurso !! Palabra clave !! Descripción !! Información
 +
|-
 +
| 0 || kern || mensajes del kernel
 +
|-
 +
| 1 || user || mensajes a nivel de usuario
 +
|-
 +
| 2 || mail || sistema de correo || El arcaico POSIX todavía se admite y se usa a veces (para más información {{man|1|mail}})
 +
|-
 +
| 3 || daemon || demonios del sistema || Todos los demonios, incluyendo systemd y sus subsistemas
 +
|-
 +
| 4 || auth || mensajes de seguridad/autorización || También tenga en cuenta los diferentes recursos del código 10
 +
|-
 +
| 5 || syslog || mensajes generados internamente por syslogd || Para las implementaciones de syslogd (no utilizadas por systemd, consulte el código 3)
 +
|-
 +
| 6 || lpr || subsistema de [wikipedia:es:Impresora de línea|impresora de línea]] (subsistema arcaico)
 +
|-
 +
| 7 || news || subsistema de noticias de la red (subsistema arcaico)
 +
|-
 +
| 8 || uucp || subsistema [[wikipedia:es:Copiador de Unix a Unix|UUCP]] (subsistema arcaico)
 +
|-
 +
| 9 || || demonio para el reloj del sistema || systemd-timesyncd
 +
|-
 +
| 10 || authpriv || mensajes de seguridad/autorización || También tenga en cuenta los diferentes recursos del código 4
 +
|-
 +
| 11 || ftp || subsistema [[wikipedia:es:Protocolo de transferencia de archivos|FTP]]
 +
|-
 +
| 12 || - || subsistema [[wikipedia:es:Network Time Protocol|NTP]]
 +
|-
 +
| 13 || - || auditoría de registro
 +
|-
 +
| 14 || - || alerta de registro
 +
|-
 +
| 15 || cron || demonio de programación
 +
|-
 +
| 16 || local0 || uso local 0  (local0)
 +
|-
 +
| 17 || local1 || uso local 1  (local1)
 +
|-
 +
| 18 || local2 || uso local 2  (local2)
 +
|-
 +
| 19 || local3 || uso local 3  (local3)
 +
|-
 +
| 20 || local4 || uso local 4  (local4)
 +
|-
 +
| 21 || local5 || uso local 5  (local5)
 +
|-
 +
| 22 || local6 || uso local 6  (local6)
 +
|-
 +
| 23 || local7 || uso local 7  (local7)
 +
|}
  
Habilita el inicio automático en el arranque:
+
Por lo tanto, son códigos útiles para observar: 0,1,3,4,9,10,15.
  
{{bc|# systemctl enable <unidad>}}
+
=== Filtrar la salida ===
  
{{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.
+
''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.
  
{{bc|# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/}}
+
{{Sugerencia|mientras journal se almacena en un formato binario, el contenido de los mensajes almacenados no se modifica. Esto significa que se puede visualizar en forma de ''strings'' («''cadenas''»), por ejemplo, para la recuperación en un entorno que no tiene instalado ''systemd''. Ejemplo de orden:
 +
{{bc|$ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal <nowiki>| grep -i</nowiki> ''message''}}
 +
}}
  
}}
+
Ejemplos:
  
Desactiva el inicio automático durante el arranque:
+
*Mostrar todos los mensajes del arranque: {{bc|# 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 {{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 {{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.
 +
* Mostrar todos los mensajes de fecha (y hora opcional): {{bc|1=# journalctl --since="2012-10-30 18:17:16"}}
 +
* Mostrar todos los mensajes desde hace 20 minutos: {{bc|1=# journalctl --since "20 min ago"}}
 +
* Seguir los mensajes nuevos: {{bc|# journalctl -f}}
 +
* Mostrar todos los mensajes por un ejecutable específico: {{bc|# journalctl /usr/lib/systemd/systemd}}
 +
* Mostrar todos los mensajes para un proceso específico: {{bc|1=# journalctl _PID=1}}
 +
* Mostrar todos los mensajes por una unidad específica: {{bc|# journalctl -u man-db.service}}
 +
* Mostrar el búfer del kernel {{bc|1=# journalctl -k}}
 +
* Mostrar solo mensajes de error, críticos y de prioridad de alerta {{bc|# journalctl -p err..alert}} También se pueden usar números, {{ic|journalctl -p 3..1}}. Si se utiliza un solo número/palabra clave, {{ic|journalctl -p 3}} —también se incluyen todos los niveles de prioridad más altos—.
 +
* Mostrar el equivalente de auth.log para filtrar en el código de instalación de syslog: {{bc|1=# journalctl SYSLOG_FACILITY=10}}
 +
* Si el directorio de journal (de manera predeterminada, ubicado en  {{ic|/var/log/journal}})  contiene una gran cantidad de datos de registro, entonces {{ic|journalctl}} puede tardar varios minutos en filtrar la salida. Puede acelerarlo significativamente usando la opción {{ic|--file}} para forzar a {{ic | journalctl}} a buscar solo en el journal más reciente: {{bc|# journalctl --file /var/log/journal/*/system.journal -f}}
  
{{bc|# systemctl disable <unidad>}}
+
Véase {{man|1|journalctl}}, {{man|7|systemd.journal-fields}} o esta [http://0pointer.de/blog/projects/journalctl.html entrada de blog] de Lennert para obtener más detalles.
  
Muestra la página del manual asociada con una unidad (esto tiene que ser apoyado por el archivo .unit):
+
{{Sugerencia|1=
 +
De forma predeterminada, ''journalctl'' trunca las líneas más largas que exceden del ancho de la pantalla, pero en algunos casos, puede ser mejor activar el ajuste en lugar de fracturarlas. Esto puede ser controlado por la [[Environment variables (Español)|variable de entorno]] {{ic|SYSTEMD_LESS}}, que contiene opciones pasadas a [[Core utilities#Essentials|less]]  (el paginador predeterminado) y, por defecto, a {{ic|FRSXMK}} (consulte {{man|1|less}} y {{man|1|journalctl}} para más detalles).
  
{{bc|$ systemctl help <unidad>}}
+
Al omitir la opción {{ic|S}}, la salida se ajustará en lugar de truncarla. Por ejemplo, inicie ''journalctl'' de la siguiente manera:
  
Recarga systemd, escaneando en busca de unidades nuevas o modificadas:
+
$ SYSTEMD_LESS=FRXMK journalctl
  
  # systemctl daemon-reload
+
Si desea establecer este comportamiento como predeterminado, [[Environment variables (Español)#Por usuario|exporte]] la variable desde {{ic|~/.bashrc}} o {{ic|~/.zshrc}}.
 +
}}
  
===Administración de la energía ===  
+
=== Límite del tamaño de journal ===
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:
+
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 pero limitado a 4 GiB. Por ejemplo, con {{ic|/var/log/journal}} alojado en una partición raíz de 20 GiB, esto permitiría almacenar hasta 2 GiB de datos en journal. En una de 50 GiB, tendría un máximo de 4 GiB.
  
{{bc|$ systemctl reboot}}
+
El tamaño máximo del journal permanente puede ser controlado descomentando y modificando la correspondiente línea:
  
Apagado del sistema:
+
{{hc|/etc/systemd/journald.conf|2=
 +
SystemMaxUse=50M
 +
}}
  
{{bc|$ systemctl poweroff}}
+
También es posible utilizar el mecanismo de sobrescribir la configuración con fragmentos insertados en lugar de editar el archivo de configuración global. En este caso, no olvide colocar el reemplazo debajo del encabezado de {{ic|[Journal]}}:
  
Apagado completo del sistema:
+
{{hc|/etc/systemd/journald.conf.d/00-journal-size.conf|2=
 +
[Journal]
 +
SystemMaxUse=50M
 +
}}
  
{{bc|$ systemctl halt}}
+
[[#Utilizar las unidades|Reinicie]] el servicio {{ic|systemd-journald.service}} después de cambiar esta configuración para aplicar inmediatamente el nuevo límite.
  
Suspensión del sistema:
+
Vea {{man|5|journald.conf}} para más información.
  
{{bc|$ systemctl suspend}}
+
=== Limpiar manualmente archivos journal ===
  
Hibernación del sistema:
+
Los archivos journal se pueden eliminar globalmente de {{ic|/var/log/journal/}} utilizando ''por ejemplo'' {{ic|rm}}, o se pueden recortar de acuerdo con varios criterios usando {{ic|journalctl}}. Ejemplos:
  
{{bc|$ systemctl hibernate}}
+
* Eliminar los archivos journal archivados hasta que el espacio en disco que utilizan esté por debajo de 100M: {{bc|1=# journalctl --vacuum-size=100M}}
 +
* Hacer que todos los archivos journal no contengan datos de más de 2 semanas. {{bc|1=# journalctl --vacuum-time=2weeks}}
  
Poner el sistema en estado hybrid-sleep (o suspend-to-both):
+
Vea {{man|1|journalctl}} para más información.
  
$ systemctl hybrid-sleep
+
=== Journald coexistiendo con syslog ===
  
==Iniciar un entorno de escritorio con systemd==
+
La compatibilidad con una implementación clásica, [[Syslog-ng|syslog]], no reconocida por journald, se puede proporcionar al permitir que ''systemd'' reenvíe todos los mensajes a través del socket {{ic|/run/systemd/journal/syslog}}. Para hacer que el demonio syslog funcione con journal, debe vincularse a este socket en lugar de a {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ anuncio oficial]).
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}}
+
El {{ic|journald.conf}} predeterminado para reenviar al socket es {{ic|1=ForwardToSyslog=no}} para evitar la sobrecarga del sistema, porque [[rsyslog]] o [[syslog-ng]] tiran de los mensajes de journal por [http://lists.freedesktop.org/archives/systemd-devel/2014-August/022295.html#journald sí mismo].
  
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:
+
Vea [[Syslog-ng#Overview]] y [[Syslog-ng#syslog-ng and systemd journal]], o [[rsyslog]] respectivamente, para obtener detalles sobre la configuración.
  
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}
+
=== Reenviar journald a /dev/tty12 ===
  
Solo tiene que eliminar el enlace simbólico y systemd utilizará el {{ic|default.target}} predefinido (es decir, {{ic|graphical.target}}).
+
Cree un [[#Modificar los archivos de unidad suministrados|directorio inclusivo]] {{ic|/etc/systemd/journald.conf.d}} y cree un archivo {{ic|fw-tty12.conf}} en él:
  
{{bc|# rm /etc/systemd/system/default.target}}
+
{{hc|1=/etc/systemd/journald.conf.d/fw-tty12.conf|2=
 +
[Journal]
 +
ForwardToConsole=yes
 +
TTYPath=/dev/tty12
 +
MaxLevelConsole=info
 +
}}
  
===Usar systemd-logind===
+
Depués [[#Utilizar las unidades|reinicie]] {{ic|systemd-journald.service}}.
{{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.}}
 
  
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.
+
=== Especificar un journal diferente para visulizar ===
  
$ loginctl show-session $XDG_SESSION_ID
+
Puede ser necesario verificar los registros de un sistema inoperativo, arrancado desde un sistema live para recuperar un sistema operativo. En tal caso, se puede montar el disco, por ejemplo en {{ic|/mnt}}, y especificar la ruta de journal a través de {{ic|-D}}/{{ic|--directory}}, así:
  
==Escribir los archivos .service personalizados==
+
  $ journalctl -D ''/mnt''/var/log/journal -xe
===Manejar las dependencias===
 
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.
+
== Consejos y trucos ==
  
===Type===
+
=== Ejecutar servicios después de que la conexión de red esté activa ===
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.
 
  
===Reemplazar las unidades suministradas===
+
Para demorar la ejecución de un servicio hasta depués de que la red esté funcionando, incluya las siguientes dependencias en el archivo ''.service'':
Las unidades en {{ic|/etc/systemd/system/}} tienen prioridad sobre las de {{ic|/usr/lib/systemd/system/}}.
 
Para mantener su propia versión de una unidad (que no será destruida después de una actualización), copie la antigua unidad de {{ic|/usr/lib /}} a {{ic|/etc/}} y haga los cambios allí. Alternativamente, puede utilizar {{ic|.include}} para analizar un archivo de servicio existente y sobrescribir o añadir nuevas opciones. Por ejemplo, si se desea simplemente agregar una dependencia adicional al servicio, puede utilizar:
 
{{hc|/etc/systemd/system/<nombre-del-servicio>.service|
 
<nowiki>
 
.include /usr/lib/systemd/system/<nombre-del-servicio>.service
 
  
 +
{{hc|/etc/systemd/system/''foo''.service|2=
 
[Unit]
 
[Unit]
Requires=<dependencia nueva>
+
...
After=<dependencia nueva>
+
'''Wants=network-online.target'''
</nowiki>}}
+
'''After=network-online.target'''
A continuación, ejecute las siguientes órdenes para que los cambios surtan efecto:
+
...
  # systemctl reenable <unidad>
+
}}
  # systemctl restart <unidad>
+
 
{{Sugerencia|Puede utilizar {{ic|systemd-delta}} para ver qué archivos de unidad han sido sobreescritos y cuáles exactamente han sido modificados.}}
+
El servicio de espera de red de la particular aplicación que gestiona la conexión la red también debe activarse para que {{ic|network-online.target}} refleje adecuadamente el estado de la red.
 +
* Para los que usan  [[NetworkManager]], [[enable (Español)|active]] {{ic|NetworkManager-wait-online.service}}.
 +
* Si se usa [[systemd-networkd]], {{ic|systemd-networkd-wait-online.service}} se activa automáticamente de forma predeterminada cada vez que {{ic|systemd-networkd.service}} está activado; compruebe que este es el caso con {{ic|systemctl is-enabled systemd-networkd-wait-online.service}}, lo cual hará que no se necesite ninguna otra acción.
 +
 
 +
Para obtener explicaciones más detalladas, consulte: [https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ ejecutar servicios después de que la red esté activa] en la wiki de systemd.
  
Como los archivos de unidades proporcionados se actualizarán de vez en cuando, utilice systemd-delta para el mantenimiento del sistema.
+
=== Activar las unidades instaladas por defecto ===
  
===Resaltar la sintaxis de las unidades de systemd con Vim===
+
Arch Linux se entrega con {{ic|/usr/lib/systemd/system-preset/99-default.preset}} que contiene {{ic|disable *}}. Esto hace que ''systemctl preset'' desactive todas las unidades de forma predeterminada, de modo que cuando se instala un nuevo paquete, el usuario debe activar la unidad manualmente.
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]].
 
  
==Targets==
+
Si este comportamiento no es deseado, simplemente cree un enlace simbólico de {{ic|/etc/systemd/system-preset/99-default.preset}} a {{ic|/dev/null}} para anular el archivo de configuración . Esto hará que ''systemctl preset'' active todas las unidades que se instalan, independientemente del tipo de unidad, a menos que se especifique otra cosa en otro archivo ubicado en uno de los directorios de configuración de ''systemctl preset''. Las unidades de usuario no se verán afectadas. Vea {{man|5|systemd.preset}} para más información.
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}}.
 
  
===Conocer los targets presentes===
+
{{Nota|activar todas las unidades por defecto puede causar problemas con los paquetes que contienen dos o más unidades mutuamente excluyentes. ''systemctl preset'' está diseñado para ser utilizado por distribuciones o administradores de sistemas. En el caso de que dos unidades en conflicto estén activadas, debe especificarse explícitamente cuál de ellas se debe desactivar en un archivo de configuración preestablecido, como se especifica en la página del manual de {{ic|systemd.preset}}.}}
La siguiente orden debe ser utilizada bajo systemd, en lugar del {{ic|runlevel}}:
 
{{bc|1=# systemctl list-units --type=target}}
 
  
===Crear un target personalizado ===  
+
=== Entornos seguros para probar aplicaciones===
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===
+
Un archivo de unidad se puede crear como un sandbox para aislar aplicaciones y sus procesos dentro de un entorno virtual reforzado. systemd aprovecha los [[wikipedia:es:Espacio de nombres|espacio de nombres]], las listas blancas/negras basadas en [[Capabilities]] y los [[cgroups|grupos de control]] para contener procesos a través de una extensa [https://www.freedesktop.org/software/systemd/man/systemd.exec.html configuración de entornos de ejecución].
{| border="1"
 
!Runlevel de SysV!!Target de systemd!!Notas
 
|-
 
| 0 || runlevel0.target, poweroff.target || Detiene el sistema.
 
|-
 
| 1, s, single || runlevel1.target, rescue.target || Modalidad de usuario único.
 
|-
 
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || Definidos por el usuario. Preconfigurados a 3.
 
|-
 
| 3 || runlevel3.target, multi-user.target || Multiusuario, no gráfica. Los usuarios, por lo general, pueden acceder a través de múltiples consolas o a través de la red.
 
|-
 
| 5 || runlevel5.target, graphical.target || Multiusuario, gráfica. Por lo general, tiene todos los servicios del nivel de ejecución 3, además de un inicio de sesión gráfica.
 
|-
 
| 6 || runlevel6.target, reboot.target || Reinicia el sistema.
 
|-
 
| emergency || emergency.target || Consola de emergencia.
 
|-
 
|}
 
  
===Cambiar el target presente===
+
El aprovisionamiento de un archivo de unidad systemd existente con la aplicación sandboxing, generalmente requiere de pruebas de ensayo y error acompañadas del uso generoso de {{Pkg|strace}}, [[wikipedia:Standard_streams#Standard_error_.28stderr.29|stderr]], registro de errores de [https://www.freedesktop.org/software/systemd/man/journalctl.html journalctl] y de salida de recursos. Es posible que desee buscar primero en la documentación anterior los test ya realizados a partir de los cuales realizar la pruebas.
En systemd los targets quedan expuestos a través de «target units». Se pueden cambiar de esta manera:
 
  
{{bc|# systemctl isolate graphical.target}}
+
Algunos ejemplos sobre cómo se puede implementar el sandboxing con systemd:
 +
* {{Ic|CapabilityBoundingSet}} define un conjunto en lista blanca de capacidades permitidas, pero también se puede usar para incluir en una lista negra una capacidad específica para una unidad.
 +
** La capacidad {{Ic|CAP_SYS_ADM}}, por ejemplo, que debería ser uno de los [https://lwn.net/Articles/486306/ objetivos de un sandbox seguro]: {{ic|1=CapabilityBoundingSet=~ CAP_SYS_ADM}}
  
Esto solo cambiará el target actual, y no tendrá ningún efecto sobre el siguiente arranque. Esto es equivalente a las órdenes {{ic|telinit 3}} o {{ic|telinit 5}} en Sysvinit.
+
== Solución de problemas ==
  
===Cambiar el target predeterminado para arrancar===
+
=== Investigar errores de systemd ===
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.}}
 
* {{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).
 
  
Como alternativa, se puede dejar el gestor de arranque inalterado y cambiar {{ic|default.target}}. Esto puede hacerse usando {{ic|systemctl}}:
+
Como ejemplo, vamos a investigar un error con el servicio {{ic|systemd-modules-load}}:
{{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:
+
'''1.''' Vamos a determinar los servicios de ''systemd'' que fallan al inicio:
[Install]
 
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.
 
  
== Journal==
+
{{hc|1=$ systemctl --state=failed|2=
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:
+
systemd-modules-load.service  loaded '''failed failed''' Load Kernel Modules}}
  
# journalctl
+
Otra forma es ver los mensajes en vivo del registro de ''systemd'':
  
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.
+
$ journalctl -fp err
  
===Filtrar la salida ===
+
'''2.''' Encontramos un problema con el servicio {{ic|systemd-modules-load}}. Indaguemos un poco más:
{{ic|journalctl}} le permite filtrar los resultados por campos específicos.
 
  
Ejemplos:
+
{{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: '''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''')
 +
}}
  
Mostrar todos los mensajes del arranque:
+
Si el {{ic|Process ID}} no está en la lista, simplemente reinicie el servicio fallido con {{ic|systemctl restart systemd-modules-load}}
 
# journalctl -b
 
  
Seguir los mensajes nuevos:
+
'''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):
  
# journalctl -f
+
{{hc|1=$ journalctl _PID=15630|2=
 +
-- 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''''
 +
}}
  
Mostrar todos los mensajes de un ejecutable específico:
+
'''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/}}:
  
# journalctl /usr/lib/systemd/systemd
+
{{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
 +
...
 +
}}
  
Mostrar todos los mensajes de un proceso específico:
+
'''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:
  
# journalctl _PID=1
+
{{hc|/etc/modules-load.d/blacklist.conf|
 +
'''#''' blacklist usblp
 +
'''#''' install usblp /bin/false
 +
}}
  
Mostrar todos los mensajes por una unidad específica:
+
'''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.
  
# journalctl -u netcfg
+
Si todo está bien, se puede verificar que el servicio se ha iniciado satisfactoriamente con:
  
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.
+
{{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'''.
 +
}}
  
===Límite del tamaño de journal===
+
=== Diagnosticar problemas de arranque ===
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}}
 
Consulte {{ic|man journald.conf}} para más información.
 
  
===Journald coexistiendo con syslog ===
+
''systemd''  tiene varias opciones para diagnosticar problemas con el proceso de arranque. Consulte [[boot debugging]] para obtener instrucciones y opciones más generales para capturar mensajes de inicio antes de que ''systemd'' se haga cargo del [[Arch boot process (Español)|proceso de arranque]]. Véase también ña [http://freedesktop.org/wiki/Software/systemd/Debugging/ documentación de depuración de errores de systemd].
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.
 
Para hacer que el demonio syslog funcione con journal, tiene que asociarlo a este socket en vez de a {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ anuncio oficial]). El paquete {{pkg|syslog-ng}} de los repositorios proporciona automáticamente la configuración necesaria.
 
{{bc|# systemctl enable syslog-ng}}
 
  
==Optimización==
+
=== Diagnosticar un servicio ===
  
 +
Si algún servicio ''systemd'' se comporta mal o si desea obtener más información sobre lo que está sucediendo, configure la [[Environment variables (Español)|variable de entorno]] {{ic|SYSTEMD_LOG_LEVEL}} a {{ic|debug}}. Por ejemplo, para ejecutar el demonio ''systemd-networkd'' en modo de depuración de errores:
  
{{merge|Improve Boot Performance|reason=Should be moved to the article covering this topic.}}
+
Agregue un [[#Archivos insertados|fragmento de archivo]] para el servicio agregando las dos líneas siguientes:
  
Véase [[Improve Boot Performance]].
+
[Service]
 +
Environment=SYSTEMD_LOG_LEVEL=debug
  
=== Analizar el proceso de arranque ===
+
O, de igual modo, establezca la variable de entorno manualmente:
==== Usar systemd-analyze ====
 
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:
+
# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
  
$ systemd-analyze
+
luego [[#Utilizar las unidades|reinicie]] ''systemd-networkd'' y observe jopurnal para el servicio con la opción {{ic|-f}}/{{ic|--follow}}.
  
{{Sugerencia|También será capaz de mostrar cuánto tiempo ha empleado initramfs, si se agrega el parámetro {{ic|timestamp}} a la matriz {{ic|HOOKS}} en {{ic|/etc/[[mkinitcpio (Español)|mkinitcpio]].conf}} y reconstruya, como root, initramfs, con la orden {{ic|mkinitcpio -p linux}}.}}
+
=== Apagar/reiniciar se hace terriblemente largo ===
  
Para ver un listado de las unidades iniciadas, ordenadas según el tiempo que necesitan para comenzar, escriba:
+
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/#shutdowncompleteseventually este artículo].
 
$ systemd-analyze blame
 
  
También puede crear un archivo SVG que describe el proceso de arranque gráficamente, similar a [[Bootchart]]:
+
=== Los procesos de corta duración parecen no registrar ninguna salida ===
  
  $ systemd-analyze plot > plot.svg
+
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 {{ic|_SYSTEMD_UNIT}} y {{ic|_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 {{ic|SCM_CREDENTIALS}}. En resumen, es un [https://github.com/systemd/systemd/issues/2913 bug]. Tenga en cuenta que los servicios que fallan de inmediato pueden no imprimir nada en journal según el diseño de systemd.
  
====Usar bootchart====
+
=== El tiempo de arranque aumenta con el tiempo ===
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 comandos 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
+
Después de usar {{ic|systemd-analyze}} varios usuarios advirtieron que su tiempo de arranque había aumentado significativamente en comparación con lo que solía ser. Después de usar {{ic|systemd-analyze blame}} se informa que [[NetworkManager (Español)]] toma un tiempo inusualmente grande para comenzar.
  
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.
+
El problema para algunos usuarios se debe a que {{ic|/var/log/journal}} es demasiado grande. Esto puede tener otros impactos en el rendimiento, como para {{ic|systemctl status}} o {{ic|journalctl}}. Como tal, la solución es eliminar todos los archivos dentro de la carpeta (lo ideal sería hacer una copia de seguridad en algún lugar, al menos temporalmente) y luego establecer un límite de tamaño del archivo journal como se describe en [[#Límite del tamaño de journal]].
  
===Readahead===
+
=== systemd-tmpfiles-setup.service no se inicia en el arranque ===
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
+
A partir de systemd 219, {{ic|/usr/lib/tmpfiles.d/systemd.conf}} especifica los atributos de [[wikipedia:es:Lista de control de acceso|ACL]] para los directorios en {{ic|/var/log/journal}} y, por lo tanto, requiere que el soporte de ACL sea activado para el sistema de archivos en el que reside journal.
  
Recuerde que para que readahead despliegue su trabajo, tendrá que reiniciar un par de veces.
+
Véase [[Access Control Lists#Enabling ACL]] para obtener instrucciones sobre cómo activar la ACL en el sistema de archivos que aloja {{ic|/var/log/journal}}.
  
==Solución de problemas ==
+
=== La versión de systemd impresa en el arranque no es la misma que la versión del paquete instalado ===
=== "Error: No space left on device" (''«Error: No queda espacio en el disco»'') al intentar iniciar/reiniciar un servicio ===
 
Nota: Puede que esta solución no sea adecuada, pero ha funcionado para algunos usuarios.
 
  
Véase este enlace: [http://support.crashplanpro.com/doku.php/recipe/increase_inotify_watches CrashPlan Support]
+
Debe [[Mkinitcpio (Español)#Creación de la imagen y activación|regenerar initramfs]] y las versiones deberían coincidir.
  
Agradecimientos a [http://forums.fedoraforum.org/showthread.php?t=283422 Fedora Forum].
+
{{Sugerencia|1=se puede usar un hook de pacman para regenerar automáticamente initramfs cada vez que se actualice {{pkg|systemd}}. Vea [https://bbs.archlinux.org/viewtopic.php?id=215411 este hilo del foro] y [[Pacman (Español)#Hooks]].}}
  
===Apagar/reiniciar se hace terriblemente largo===
+
=== Desactivar el modo de emergencia en la máquina remota ===
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 ===
+
Es posible que desee desactivar el modo de emergencia en una máquina remota, por ejemplo, una máquina virtual alojada en Azure o Google Cloud. Esto se debe a que, si se activa el modo de emergencia, la máquina no podrá conectarse a la red.
  
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.
+
# systemctl mask emergency.service
 +
# systemctl mask emergency.target
  
 
== Véase también ==
 
== Véase también ==
*[http://www.freedesktop.org/wiki/Software/systemd Sitio Web Oficial]
+
 
*[http://0pointer.de/public/systemd-man/ Manual systemd]
+
*[[Wikipedia:systemd|Wikipedia article]]
*[http://freedesktop.org/wiki/Software/systemd/Optimizations  Optimizaciones systemd]
+
*[https://www.freedesktop.org/wiki/Software/systemd systemd Official web site]
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]
+
**[https://www.freedesktop.org/wiki/Software/systemd/Optimizations systemd optimizations]
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Consejos y trucos]
+
**[https://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions systemd FAQ]
*[http://0pointer.de/public/systemd-ebook-psankar.pdf Systemd para administradores (PDF)]
+
**[https://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks systemd Tips and tricks]
*[http://fedoraproject.org/wiki/Systemd Acerca de systemd en Fedora Project]
+
*[https://www.freedesktop.org/software/systemd/man/ Manual pages]
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems Cómo depurar problemas en Systemd]
+
*Otras distribuciones
*[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''.
+
**[https://wiki.gentoo.org/wiki/Systemd Gentoo Wiki systemd page]
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]
+
**[https://fedoraproject.org/wiki/Systemd Fedora Project - About systemd]
*[http://0pointer.de/blog/projects/systemd-update.html status update]
+
**[https://fedoraproject.org/wiki/How_to_debug_Systemd_problems Fedora Project - How to debug systemd problems]
*[http://0pointer.de/blog/projects/systemd-update-2.html status update2]
+
**[https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora Project - SysVinit to systemd cheatsheet]
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]
+
**[[debian:systemd|Debian Wiki systemd page]]
*[http://0pointer.de/blog/projects/why.html Resumen más reciente]
+
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story], [http://0pointer.de/blog/projects/systemd-update.html update 1], [http://0pointer.de/blog/projects/systemd-update-2.html update 2], [http://0pointer.de/blog/projects/systemd-update-3.html update 3], [http://0pointer.de/blog/projects/why.html summary]
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]
+
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd for Administrators (PDF)]
 +
*[https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units How To Use Systemctl to Manage Systemd Services and Units ]
 +
*[https://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/ Session management with systemd-logind]
 +
*[[Emacs#Syntax highlighting for systemd Files|Emacs Syntax highlighting for Systemd files]]
 +
*[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] introductory article in ''The H Open'' magazine.

Latest revision as of 13:37, 9 December 2018

Estado de la traducción
Este artículo es una traducción de Systemd, revisada por última vez el 2018-12-09. Si advierte que la versión inglesa ha cambiado puede ayudar a actualizar la traducción, bien por usted mismo o bien avisando al equipo de traducción.

De la página web del proyecto:

systemd es un conjunto de bloques básicos de compilación para un sistema Linux. Proporciona un gestor de sistemas y servicios que se ejecuta como PID 1 e inicia el resto del sistema. 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 demonios bajo demanda, realiza un seguimiento de los procesos con el uso de los grupos de control de Linux, 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. systemd es compatible con los scripts de inicialización de SysV y LSB y funciona como un reemplazo de sysvinit. Otras partes incluyen un demonio de registro, utilidades para controlar la configuración básica del sistema, tales como el nombre del equipo, la fecha, la configuración regional, la lista de usuarios registrados y contenedores y máquinas virtuales en ejecución, cuentas del sistema, directorios y configuraciones de tiempo de ejecución y demonios para gestionar una configuración de red simple, sincronización horaria de la red, reenvío de registros y resolución de nombres.
Nota: para una explicación detallada del motivo por el cual Arch cambió a systemd, consulte esta publicación del foro.

Contents

Utilización básica de systemctl

La principal orden usada para conocer y controlar systemd es systemctl. Algunos de los posibles usos son el examen del estado del sistema y la gestión del sistema o de los servicios. Consulte systemctl(1) 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;
  • lo usuarios de Plasma pueden instalar systemd-kcmAUR como una interfaz gráfica para systemctl. Después de instalar el módulo se agregará a Administración del sistema.

Analizar el estado del sistema

Para mostrar el estado del sistema utilice:

$ systemctl status

Para listar unidades en ejecución:

$ systemctl

o:

$ systemctl list-units

Para listar unidades que han fallado:

$ systemctl --failed

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

$ systemctl list-unit-files

Utilizar las unidades

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

Cuando se usa systemctl, por lo general, tiene que especificar el nombre completo de la unidad, incluyendo el sufijo, por ejemplo, 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.

Véase systemd.unit(5) para más detalles.

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

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

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

Activa una unidad de inmediato:

# systemctl start unidad

Detiene una unidad de inmediato:

# systemctl stop unidad

Reinicia la unidad:

# systemctl restart unidad

Hace que una unidad recargue su configuración:

# systemctl reload unidad

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

$ systemctl status unidad

Comprueba si la unidad ya está activada o no:

$ systemctl is-enabled unidad

Activa una unidad para inicarse en el arranque:

# systemctl enable unidad

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

# systemctl enable --now unidad

Desactiva el inicio automático durante el arranque:

# systemctl disable unidad

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

# systemctl mask unidad

Desenmascara una unidad:

# systemctl unmask unidad

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

 $ systemctl help unidad

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

Nota: esto no le pide a las unidades modificadas que vuelvan a cargar sus propias configuraciones. Vea el ejemplo reload de arriba.
# systemctl daemon-reload

Gestionar la energía

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

Apagado y reinicio del sistema:

$ systemctl reboot

Apagado del sistema:

$ systemctl poweroff

Suspensión del sistema:

$ systemctl suspend

Poner el sistema en hibernación:

$ systemctl hibernate

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

$ systemctl hybrid-sleep

Escribir archivos de unidad

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

  • /usr/lib/systemd/system/: unidades proporcionadas por los paquetes instalados.
  • /etc/systemd/system/: unidades instaladas por el administrador del sistema.
Nota:
  • Las rutas de carga son completamente diferentes cuando se ejecuta systemd en momdo usuario.
  • Los nombres de las unidades del sistema solo pueden contener caracteres alfanuméricos ASCII, guiones bajos y puntos. Todos los demás caracteres deben reemplazarse por escapes «\x2d» de estilo C, o emplear su semántica predefinida ('@','-'). Consulte systemd.unit(5) y systemd-escape(1) para obtener más información.

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

Sugerencia: Los comentarios precedidos con #, también se pueden usar en archivos de unidad, pero solo en líneas nuevas. No utilice los comentarios al final de la línea después de los parámetros de systemd o la unidad no se activará.

Manejar las dependencias

Con systemd las dependencias pueden ser resueltas diseñando la unidad correctamente. El caso más típico es que la unidad A requiere la unidad B para poder funcionar, por lo que esta última debe iniciarse antes que A. En ese caso, agregue 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 #Targets. 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.

Tipos de servicios

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

  • Type=simple (por defecto): systemd considera que el servicio debe iniciarse inmediatamente. El proceso no debe romperse. No utilice este tipo si otros servicios tienen que ser llamados por ese servicio, a menos que no sea activado por el socket.
  • 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.
  • Type=idle: systemd retrasará la ejecución del binario del servicio hasta que se envíen todos los trabajos. Un comportamiento por cierto muy similar a Type=simple.

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

Modificar los archivos de unidad suministrados

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

# systemctl daemon-reload
Sugerencia:
  • Puede usar systemd-delta para ver qué archivos de la unidad se han sobrescrito o ampliado y qué se ha cambiado exactamente.
  • Utilice systemctl cat unidad para ver el contenido de un archivo de unidad y todos los fragmentos insertados asociados.

Reemplazar los archivos de unidad

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

# systemctl reenable unidad

Alternativamente, ejecute:

# systemctl edit --full unidad

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

Nota: las unidades de reemplazo seguirán usándose incluso si pacman actualiza las unidades originales en el futuro. Este método hace que el mantenimiento del sistema sea más difícil y, por lo tanto, se prefiere el siguiente enfoque.

Archivos insertados

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

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

# systemctl edit unidad

Esto abre el archivo /etc/systemd/system/unit.d/override.conf en su editor de texto (creándolo si es necesario) y vuelve a cargar automáticamente la unidad cuando haya terminado de editarla.

Nota: no todas las claves se pueden anular con archivos de inserción. Por ejemplo, para cambiar Conflicts= es necesario un archivo de reemplazo.

Volver a la versión del proveedor

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

# systemctl revert unidad

Ejemplos

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

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

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

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

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

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

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

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») que tenían un significado definido bajo sysvinit (es decir, 0, 1, 3, 5 y 6), tienen una correlación de 1:1 con un específico target de systemd. Desafortunadamente, no hay una buena manera de hacer lo mismo para los niveles de ejecución definidos por el usuario como son el 2 y el 4. Si se hace uso de estos últimos, se sugiere dar un nuevo nombre al target de systemd como /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 activar.

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

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

Cambiar el target vigente

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

# systemctl isolate graphical.target

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

Cambiar el target predeterminado para arrancar

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

Para verificar el target actual con systemctl, ejecute:

$ systemctl get-default

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

# systemctl set-default multi-user.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target.

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

  • systemd.unit=multi-user.target (que corresponde aproximadamente al anterior nivel de ejecución 3),
  • systemd.unit=rescue.target (que corresponde aproximadamente al anterior nivel de ejecución 1).

Orden de los target por defecto

Systemd elige el default.target de acuerdo con el siguiente orden:

  1. El parámetro del kernel se muestra arriba
  2. Enlace simbólico de /etc/systemd/system/default.target
  3. Enlace simbólico de /usr/lib/systemd/system/default.target

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 proveídos 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 /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
#    Path                  Mode UID  GID  Age Argument
w    /proc/acpi/wakeup     -    -    -    -   USBE

Consulte las páginas de los manuales systemd-tmpfiles(8) 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 configuraición en /etc/modprobe.d. De lo contrario, tendrá que escribir una regla udev para establecer el atributo apropiado tan pronto como el dispositivo lo reclame.

Temporizadores

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

Nota: los temporizadores pueden reemplazar la funcionalidad de cron en gran medida. Consulte systemd/Timers#As a cron replacement.

Montaje

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

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

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

Montaje automático de particiones GPT

En un disco particionado con GPT, el script systemd-gpt-auto-generator(8) montará particiones siguiendo la especificación de particiones detectables , por lo tanto, las mismas se pueden omitir de fstab.

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

Journal

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

En Arch Linux, el directorio /var/log/journal/ es parte del paquete systemd, y journal (cuando Storage= está definido a auto en /etc/systemd/journald.conf) escribirá en /var/log/journal/. Si usted o algún programa eliminan ese directorio, systemd no lo volverá a crear automáticamente y en su lugar escribirá sus registros en /run/systemd/journal de una manera no persistente. Sin embargo, la carpeta se volverá a crear cuando establezca Storage=persistent y reinicie systemd-journald.service (o reinicie el equipo).

El journald de systemd clasifica los mensajes por #Nivel de prioridad y #Nivel del recurso. La clasificación del registro corresponde al protocolo clásico de Syslog (RFC 5424).

Nivel de prioridad

Se utiliza el código de severidad de syslog (en systemd llamado prioridad) para marcar la importancia de un mensaje RFC 5424 Section 6.2.1.

Valor Severidad Palabra clave Descripción Ejemplos
0 Emergencia emerg El sistema está inutilizable Bug importante del kernel, núcleo de systemd volcado.
Este nivel no debe ser utilizado por las aplicaciones.
1 Alerta alert Debe corregirse inmediatamente El subsistema vital parece no funcionar. Pérdida de datos.
kernel: BUG: unable to handle kernel paging request at ffffc90403238ffc.
2 Crítico crit Condiciones criticas Quiebra, volcado del núcleo. Tales como:
systemd-coredump[25319]: Process 25310 (plugin-containe) of user 1000 dumped core
Error en la aplicación principal del sistema, como X11.
3 Error err Condiciones de error Se informa de error no grave:
kernel: usb 1-3: 3:1: cannot get freq at ep 0x84,
systemd[1]: Failed unmounting /var.,
libvirtd[1720]: internal error: Failed to initialize a valid firewall backend).
4 Advertencia warning Puede indicar que se producirá un error si no se toman medidas. Un sistema de archivos no root tiene solo 1GB libre.
org.freedesktop. Notifications[1860]: (process:5999): Gtk-WARNING **: Locale not supported by C library. Using the fallback 'C' locale.
5 Aviso notice Eventos que son inusuales, pero que no presuponen un error. systemd[1]: var.mount: Directory /var to mount over is not empty, mounting anyway. gcr-prompter[4997]: Gtk: GtkDialog mapped without a transient parent. This is discouraged.
6 Informativo info Mensajes de operaciones normales que no requieren ninguna acción. lvm[585]: 7 logical volume(s) in volume group "archvg" now active.
7 Depuración errores debug Información útil para los desarrolladores para depurar errores de la aplicación. kdeinit5[1900]: powerdevil: Scheduling inhibition from ":1.14" "firefox" with cookie 13 and reason "screen".

Si no puede encontrar un mensaje en el nivel de prioridad esperado, puede buscar también un par de niveles por encima y por debajo: estas reglas son recomendaciones y el desarrollador de la aplicación afectada puede tener una percepción diferente de la importancia del problema con respecto a la suya.

Nivel del recurso

Se utiliza un código de recursos de syslog para especificar el tipo de programa que está registrando el mensaje RFC 5424 Section 6.2.1.

Código del recurso Palabra clave Descripción Información
0 kern mensajes del kernel
1 user mensajes a nivel de usuario
2 mail sistema de correo El arcaico POSIX todavía se admite y se usa a veces (para más información mail(1))
3 daemon demonios del sistema Todos los demonios, incluyendo systemd y sus subsistemas
4 auth mensajes de seguridad/autorización También tenga en cuenta los diferentes recursos del código 10
5 syslog mensajes generados internamente por syslogd Para las implementaciones de syslogd (no utilizadas por systemd, consulte el código 3)
6 lpr impresora de línea]] (subsistema arcaico)
7 news subsistema de noticias de la red (subsistema arcaico)
8 uucp subsistema UUCP (subsistema arcaico)
9 demonio para el reloj del sistema systemd-timesyncd
10 authpriv mensajes de seguridad/autorización También tenga en cuenta los diferentes recursos del código 4
11 ftp subsistema FTP
12 - subsistema NTP
13 - auditoría de registro
14 - alerta de registro
15 cron demonio de programación
16 local0 uso local 0 (local0)
17 local1 uso local 1 (local1)
18 local2 uso local 2 (local2)
19 local3 uso local 3 (local3)
20 local4 uso local 4 (local4)
21 local5 uso local 5 (local5)
22 local6 uso local 6 (local6)
23 local7 uso local 7 (local7)

Por lo tanto, son códigos útiles para observar: 0,1,3,4,9,10,15.

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.

Sugerencia: mientras journal se almacena en un formato binario, el contenido de los mensajes almacenados no se modifica. Esto significa que se puede visualizar en forma de stringscadenas»), por ejemplo, para la recuperación en un entorno que no tiene instalado systemd. Ejemplo de orden:
$ strings /mnt/arch/var/log/journal/af4967d77fba44c6b093d0e9862f6ddd/system.journal | grep -i message

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 journalctl(1) 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.
  • Mostrar todos los mensajes de fecha (y hora opcional):
    # journalctl --since="2012-10-30 18:17:16"
  • Mostrar todos los mensajes desde hace 20 minutos:
    # journalctl --since "20 min ago"
  • Seguir los mensajes nuevos:
    # journalctl -f
  • Mostrar todos los mensajes por un ejecutable específico:
    # journalctl /usr/lib/systemd/systemd
  • Mostrar todos los mensajes para un proceso específico:
    # journalctl _PID=1
  • Mostrar todos los mensajes por una unidad específica:
    # journalctl -u man-db.service
  • Mostrar el búfer del kernel
    # journalctl -k
  • Mostrar solo mensajes de error, críticos y de prioridad de alerta
    # journalctl -p err..alert
    También se pueden usar números, journalctl -p 3..1. Si se utiliza un solo número/palabra clave, journalctl -p 3 —también se incluyen todos los niveles de prioridad más altos—.
  • Mostrar el equivalente de auth.log para filtrar en el código de instalación de syslog:
    # journalctl SYSLOG_FACILITY=10
  • Si el directorio de journal (de manera predeterminada, ubicado en /var/log/journal) contiene una gran cantidad de datos de registro, entonces journalctl puede tardar varios minutos en filtrar la salida. Puede acelerarlo significativamente usando la opción --file para forzar a journalctl a buscar solo en el journal más reciente:
    # journalctl --file /var/log/journal/*/system.journal -f

Véase journalctl(1), systemd.journal-fields(7) o esta entrada de blog de Lennert para obtener más detalles.

Sugerencia: De forma predeterminada, journalctl trunca las líneas más largas que exceden del ancho de la pantalla, pero en algunos casos, puede ser mejor activar el ajuste en lugar de fracturarlas. Esto puede ser controlado por la variable de entorno SYSTEMD_LESS, que contiene opciones pasadas a less (el paginador predeterminado) y, por defecto, a FRSXMK (consulte less(1) y journalctl(1) para más detalles).

Al omitir la opción S, la salida se ajustará en lugar de truncarla. Por ejemplo, inicie journalctl de la siguiente manera:

$ SYSTEMD_LESS=FRXMK journalctl
Si desea establecer este comportamiento como predeterminado, exporte la variable desde ~/.bashrc o ~/.zshrc.

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 pero limitado a 4 GiB. Por ejemplo, con /var/log/journal alojado en una partición raíz de 20 GiB, esto permitiría almacenar hasta 2 GiB de datos en journal. En una de 50 GiB, tendría un máximo de 4 GiB.

El tamaño máximo del journal permanente puede ser controlado descomentando y modificando la correspondiente línea:

/etc/systemd/journald.conf
SystemMaxUse=50M

También es posible utilizar el mecanismo de sobrescribir la configuración con fragmentos insertados en lugar de editar el archivo de configuración global. En este caso, no olvide colocar el reemplazo debajo del encabezado de [Journal]:

/etc/systemd/journald.conf.d/00-journal-size.conf
[Journal]
SystemMaxUse=50M

Reinicie el servicio systemd-journald.service después de cambiar esta configuración para aplicar inmediatamente el nuevo límite.

Vea journald.conf(5) para más información.

Limpiar manualmente archivos journal

Los archivos journal se pueden eliminar globalmente de /var/log/journal/ utilizando por ejemplo rm, o se pueden recortar de acuerdo con varios criterios usando journalctl. Ejemplos:

  • Eliminar los archivos journal archivados hasta que el espacio en disco que utilizan esté por debajo de 100M:
    # journalctl --vacuum-size=100M
  • Hacer que todos los archivos journal no contengan datos de más de 2 semanas.
    # journalctl --vacuum-time=2weeks

Vea journalctl(1) para más información.

Journald coexistiendo con syslog

La compatibilidad con una implementación clásica, syslog, no reconocida por journald, se puede proporcionar al permitir que systemd reenvíe todos los mensajes a través del socket /run/systemd/journal/syslog. Para hacer que el demonio syslog funcione con journal, debe vincularse a este socket en lugar de a /dev/log (anuncio oficial).

El journald.conf predeterminado para reenviar al socket es ForwardToSyslog=no para evitar la sobrecarga del sistema, porque rsyslog o syslog-ng tiran de los mensajes de journal por sí mismo.

Vea Syslog-ng#Overview y Syslog-ng#syslog-ng and systemd journal, o rsyslog respectivamente, para obtener detalles sobre la configuración.

Reenviar journald a /dev/tty12

Cree un directorio inclusivo /etc/systemd/journald.conf.d y cree un archivo fw-tty12.conf en él:

/etc/systemd/journald.conf.d/fw-tty12.conf
[Journal]
ForwardToConsole=yes
TTYPath=/dev/tty12
MaxLevelConsole=info

Depués reinicie systemd-journald.service.

Especificar un journal diferente para visulizar

Puede ser necesario verificar los registros de un sistema inoperativo, arrancado desde un sistema live para recuperar un sistema operativo. En tal caso, se puede montar el disco, por ejemplo en /mnt, y especificar la ruta de journal a través de -D/--directory, así:

$ journalctl -D /mnt/var/log/journal -xe

Consejos y trucos

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

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

/etc/systemd/system/foo.service
[Unit]
...
Wants=network-online.target
After=network-online.target
...

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

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

Para obtener explicaciones más detalladas, consulte: ejecutar servicios después de que la red esté activa en la wiki de systemd.

Activar las unidades instaladas por defecto

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

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

Nota: activar todas las unidades por defecto puede causar problemas con los paquetes que contienen dos o más unidades mutuamente excluyentes. systemctl preset está diseñado para ser utilizado por distribuciones o administradores de sistemas. En el caso de que dos unidades en conflicto estén activadas, debe especificarse explícitamente cuál de ellas se debe desactivar en un archivo de configuración preestablecido, como se especifica en la página del manual de systemd.preset.

Entornos seguros para probar aplicaciones

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

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

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

  • CapabilityBoundingSet define un conjunto en lista blanca de capacidades permitidas, pero también se puede usar para incluir en una lista negra una capacidad específica para una unidad.

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

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

$ journalctl -fp err

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)

Si el Process ID no está en la lista, simplemente reinicie el servicio fallido con systemctl restart systemd-modules-load

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 _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.

Diagnosticar problemas de arranque

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

Diagnosticar un servicio

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

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

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

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

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

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

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. En resumen, es un bug. Tenga en cuenta que los servicios que fallan de inmediato pueden no imprimir nada en journal según el diseño de systemd.

El tiempo de arranque aumenta con el tiempo

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

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

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

A partir de systemd 219, /usr/lib/tmpfiles.d/systemd.conf especifica los atributos de ACL para los directorios en /var/log/journal y, por lo tanto, requiere que el soporte de ACL sea activado para el sistema de archivos en el que reside journal.

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

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

Debe regenerar initramfs y las versiones deberían coincidir.

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

Desactivar el modo de emergencia en la máquina remota

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

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

Véase también