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

From ArchWiki
Jump to: navigation, search
(ACPI gestión de energía: alternate translation)
(Actualizar:2012.11.18)
Line 29: Line 29:
 
* Tenga en cuenta el hecho de que systemd tiene un sistema '''journal''' que sustituye a '''syslog''', aunque todavía los dos pueden coexistir. Consulte la [[#Journald coexistiendo con syslog|sección relativa a journal]] a continuación.
 
* Tenga en cuenta el hecho de que systemd tiene un sistema '''journal''' que sustituye a '''syslog''', aunque todavía los dos pueden coexistir. Consulte la [[#Journald coexistiendo con syslog|sección relativa a journal]] a continuación.
 
* Aunque con systemd se puede reemplazar la funcionalidad de '''cron''', '''acpid''' o '''xinetd''', de momento no hay necesidad de abandonar el uso de los demonios tradicionales a menos que así lo desee.
 
* Aunque con systemd se puede reemplazar la funcionalidad de '''cron''', '''acpid''' o '''xinetd''', de momento no hay necesidad de abandonar el uso de los demonios tradicionales a menos que así lo desee.
 +
* Los initscripts interactivos no están funcionando con systemd. En particular, '''netcfg-menu''' [https://bugs.archlinux.org/task/31377 no puede] ser usado al inicio del sistema.
  
 
==Instalación==  
 
==Instalación==  
Line 43: Line 44:
 
*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.
 
*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|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:Access control list|POSIX ACLs]] para dispositivos de audio/vídeo, y permitirá ciertas operaciones, como el montaje de discos extraíbles, a través de [[udisks]].
 
* '''No''' es necesario añadir su usuario a los [[Users and Groups|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:Access control list|POSIX ACLs]] para dispositivos de audio/vídeo, y permitirá ciertas operaciones, como el montaje de discos extraíbles, a través de [[udisks]].
 
+
*La eliminación del paquete initscripts romperá la compatibilidad con rc.conf. Tenga cuidado si tiene configurada una red estática con ellos o usa algunos demonios, que no han migrado aún a systemd. Vea la sección [[#Emulación de los initscripts|emular los initscripts]] para conocer más detalles sobre cómo pueden coexistir los dos sitemas.  
{{Nota|Systemd-logind reemplaza a [[ConsoleKit]], el cual ha sido removido de los repositorios, de modo que un sistema arrancado con systemd debe ser completamente operativo. Consulte [https://www.archlinux.org/news/consolekit-replaced-by-logind/ aquí] para obtener más información.}}
+
  
 
==Configuración nativa==
 
==Configuración nativa==
Line 50: Line 50:
 
{{Nota|Puede que tenga que crear estos archivos. Todos los archivos deben tener permisos '''644''' y propiedad de '''root:root'''.}}
 
{{Nota|Puede que tenga que crear estos archivos. Todos los archivos deben tener permisos '''644''' y propiedad de '''root:root'''.}}
  
=== Hostname ===
+
=== Nombre del host ===
  
El nombre del host está configurado en {{ic|/etc/hostname}}. El archivo no debe contener el dominio del sistema, si existe. Para configurar el nombre de host, escriba:
+
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:
  
  # hostnamectl set-hostname '''myhostname'''
+
  # hostnamectl set-hostname '''elnombredemihost'''
  
 
Consulte {{ic|man 5 hostname}} y {{ic|man 1 hostnamectl}} para más detalles.
 
Consulte {{ic|man 5 hostname}} y {{ic|man 1 hostnamectl}} para más detalles.
Line 60: Line 60:
 
He aquí un ejemplo del archivo:
 
He aquí un ejemplo del archivo:
 
{{hc|/etc/hostname|
 
{{hc|/etc/hostname|
myhostname
+
elnombredemihost
 
}}
 
}}
  
=== Locale ===
+
=== Configurar el idioma ===
  
La configuración regional predeterminada del sistema está configurada en {{ic|/etc/locale.conf}}. Para configurar el idioma predeterminado, escriba:
+
El ajuste del idioma (''«locale»'') predeterminado del sistema se configura en {{ic|/etc/locale.conf}}. Para definir el idioma predeterminado, escriba:
  
 
  # localectl set-locale LANG="es_ES.UTF-8"
 
  # localectl set-locale LANG="es_ES.UTF-8"
  
{{Nota|Antes de configurar el idioma predeterminado, primero necesita habilitar los locales disponibles para el sistema eliminando el comentario de ellos en {{ic|/etc/locale.gen}} y luego ejecutar {{ic|locale-gen}} como root. La configuración regional establecida por {{ic|localectl}} debe ser uno de los locales '''descomentados''' en el archivo {{ic|/etc/locale.gen}}.}}
+
{{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}}.}}
  
 
Consulte {{ic|man 1 localectl}} y {{ic|man 5 locale.conf}} para más detalles.
 
Consulte {{ic|man 1 localectl}} y {{ic|man 5 locale.conf}} para más detalles.
  
* Para más información, consulte [[Locale (Español)]].
+
* Para más información, consulte [[Locale (Español)|Locale]].
  
 
He aquí un ejemplo del archivo:
 
He aquí un ejemplo del archivo:
Line 82: Line 82:
  
 
===Consola virtual ===
 
===Consola virtual ===
En el archivo {{ic|/etc/vconsole.conf}} se configura la consola virtual, es decir, establece la distribución del teclado, la tipografía de la consola y la distribución de la consola.
+
 
 +
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}}.
  
 
{{hc|/etc/vconsole.conf|<nowiki>
 
{{hc|/etc/vconsole.conf|<nowiki>
Line 89: Line 90:
 
FONT_MAP=</nowiki>}}
 
FONT_MAP=</nowiki>}}
  
{{Note|Desde {{pkg|systemd-194}}, el ''kernel'' incorpora por defecto la tipografía y distribución del teclado para ''us'', si las opciones {{ic|1=KEYMAP=}} y {{ic|1=FONT=}} están vacías o no se han establecido.}}
+
{{Nota|Desde {{pkg|systemd-194}}, el ''kernel'' incorpora por defecto la tipografía y distribución del teclado para ''us'', si las opciones {{ic|1=KEYMAP=}} y {{ic|1=FONT=}} están vacías o no se han establecido.}}
  
 
Otra forma de establecer la distribución del teclado (''«keymap»'') es escribiendo:
 
Otra forma de establecer la distribución del teclado (''«keymap»'') es escribiendo:
Line 99: Line 100:
 
Consulte {{ic|man 1 localectl}} y {{ic|man 5 vconsole.conf}} para más detalles.
 
Consulte {{ic|man 1 localectl}} y {{ic|man 5 vconsole.conf}} para más detalles.
  
* Para obtener más información, consulte [[Fonts#Console fonts|console fonts]] y [[KEYMAP|keymaps]].
+
* Para obtener más información, consulte [[Fonts#Console fonts|console fonts]] y [[KEYMAP (Español)|keymaps]].
  
 
===Zona horaria===
 
===Zona horaria===
La zona horaria 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:
+
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
 
  # timedatectl set-timezone Europe/Madrid
  
Vea {{ic|man 1 timedatectl}} y {{ic|man 5 localtime}} y {{ic|man 7 archlinux}} para obtener más detalles.
+
Véase {{ic|man 1 timedatectl}}, {{ic|man 5 localtime}} y {{ic|man 7 archlinux}} para obtener más detalles.
  
 
Como alternativa, cree el enlace simbólico manualmente:
 
Como alternativa, cree el enlace simbólico manualmente:
  # ln -s ../usr/share/zoneinfo/Europe/Madrid
+
  # ln -s ../usr/share/zoneinfo/Europe/Madrid /etc/localtime
  
=== Reloj de hardware ===
+
=== Reloj del hardware ===
Systemd usará '''UTC''' para el reloj de hardware por defecto.
+
Systemd usará '''UTC''' para el reloj del hardware por defecto.
  
{{Tip | 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 el reloj de hardware}}
+
{{Tip | 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 el reloj del hardware}}
  
==== Reloj de hardware en localtime ====
+
==== Reloj del hardware en localtime ====
  
Si desea cambiar el horario del reloj del hardware para utilizar la hora local ('''SERIAMENTE DESACONSEJADO''') escriba:
+
Si desea cambiar el horario del reloj del hardware (''«hardware clock»'') utilizando la hora local (''«localtime»'') -'''SERIAMENTE DESACONSEJADO'''-, escriba:
  
 
  # timedatectl set-local-rtc true
 
  # timedatectl set-local-rtc true
  
Si desea que el reloj del hardware vuelva a estar en UTC, escriba:
+
Si desea que el reloj del hardware vuelva a estar ajustado a [[wikipedia:es:UTC|UTC]] (''Universal Time Coordinated''), escriba:
  
 
  # timedatectl set-local-rtc false
 
  # timedatectl set-local-rtc false
  
Tenga en cuenta que si el reloj del hardware está configurado a localtime, tratar con el horario de verano es complicado. Si DST (horario de verano) 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 y mucho más sobre ésto]). Los kernels actuales obtienen el horario del sistema del horario del hardware directamente en el arranque, asumiendo que el reloj del hardware indica el horario UTC. Esto significa que si el horario del sistema está en la hora local, el primer sistema horario se configurará incorrectamente, y después será corregido sucesivamente en cada arranque. Esta es posiblemente la razón de ciertos bug raros (ir hacia atrás en el tiempo no suele ser una buena cosa).
+
Tenga en cuenta que si el reloj del hardware está configurado para usar la hora local (''localtime''), tratar con el horario de verano es complicado. Si el horario de verano ([[wikipedia:es:Horario_de_verano|DST]]: ''Daylight Saving Time'') entra en vigor cuando el ordenador está apagado, el reloj mostrará un horario equivocado en el próximo arranque ([http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html aquí algo más sobre esto]). Los kernels actuales obtienen el horario del sistema del reloj del hardware directamente en el arranque, asumiendo que el reloj del hardware indica el horario UTC. Esto significa que si el horario del hardware ([[wikipedia:es:Reloj_en_tiempo_real|RTC]]:Real Time Clock) está definido por la hora local (localtime, en lugar de UTC), el primer horario del sistema se configurará incorrectamente, y después será corregido sucesivamente en cada arranque. Esta es posiblemente la causa de ciertos errores extraños (ir hacia atrás en el tiempo no suele ser una buena cosa).
  
La razón para permitir que el horario del hardware esté en la hora local 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 el horario del hardware regulando la UTC con un [[Time#UTC_in_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.
+
La razón para permitir que la hora del reloj del hardware esté en localtime es habilitar un arranque dual con Windows ([http://blogs.msdn.com/b/oldnewthing/archive/2004/09/02/224672.aspx que utiliza ''localtime'']). Windows es capaz de gestionar la hora del reloj del hardware basándose en UTC con un [[Time (Español)#UTC_en_Windows|sencillo ajuste del registro]]. Por tanto, es recomendable que Windows gestione el uso de UTC, en lugar de hacer que linux use localtime. Si se usa UTC con Windows, recuerde también desactivar la opción de Windows ''«Internet Time Update»'', con el fin de evitar confusiones entre windows y el reloj del hardware, al intentar sincronizar con el horario de internet. Al contrario, debería dejar que Linux sincronice el horario del sistema con el horario de internet, activando el demonio [[Network Time Protocol daemon (Español)|NTP]], como se sugirió anteriormente.
  
* Para más información, consulte [[Time]].
+
* Para más información, consulte [[Time (Español)|Time]].
  
 
=== Módulos del kernel ===
 
=== Módulos del kernel ===
Line 141: Line 142:
  
 
{{hc|/etc/modules-load.d/virtio-net.conf|
 
{{hc|/etc/modules-load.d/virtio-net.conf|
# Carga virtio-net.ko en el arranque
+
# Cargar virtio-net.ko en el arranque
 
virtio-net}}
 
virtio-net}}
  
Line 148: Line 149:
 
====Blacklisting====
 
====Blacklisting====
  
Los módulos incluidos en blacklist (la lista negra) tienen el mismo comportamiento que con {{Pkg|initscripts}}, ya que en realidad están a cargo de {{Pkg|kmod}}. Consulte [[Kernel_modules_(Español)#Blacklisting|Módulos en Blacklist]] para más detalles.
+
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.
  
=== Montajes de filesystem===
+
=== Montaje del sistema de archivos===
  
La configuración por defecto (de fsck) comprueba automáticamente y monta los sistemas de archivos antes de iniciar los servicios que necesitan que aquellos estén montados. Por ejemplo, systemd  se asegura automáticamente de que el montaje de los sistemas de archivos remotos como [[NFS]] o [[Samba]] sólo 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.
+
La configuración por defecto (de fsck) comprueba automáticamente y monta los sistemas de archivos antes de iniciar los servicios que necesitan que aquellos estén montados. Por ejemplo, systemd  se asegura automáticamente de que el montaje de los sistemas de archivos remotos como [[NFS]] o [[Samba]] solo se inicie después de que la red  ha sido creada. Por lo tanto, el montaje de los sistemas de archivos, tanto locales como remotos, especificados en {{ic|/etc/fstab}} deberían funcionar igualmente.
  
 
Consulte {{ic|man 5 systemd.mount}} para más detalles.
 
Consulte {{ic|man 5 systemd.mount}} para más detalles.
  
====Automount====
+
====Montaje automático====
 
* Si tiene una partición {{ic|/home}} grande, tal vez sería mejor permitir que los servicios que no dependen de {{ic|/home}} se inicien, mientras {{ic|/home}} es comprobada. Esto se puede lograr mediante la adición de las siguientes opciones en la entrada de la partición {{ic|/home}} en fstab :
 
* Si tiene una partición {{ic|/home}} grande, tal vez sería mejor permitir que los servicios que no dependen de {{ic|/home}} se inicien, mientras {{ic|/home}} es comprobada. Esto se puede lograr mediante la adición de las siguientes opciones en la entrada de la partición {{ic|/home}} en fstab :
  
 
  noauto,x-systemd.automount
 
  noauto,x-systemd.automount
  
Esto comprobará el sistema de archivos y montará {{ic|/home}} cuando se acceda a la misma por primera vez, y el kenel demorará todos los accesos a los archivos de {{ic|/home}}, almacenándolos en un buffer, hasta que la partición esté lista.
+
Esto comprobará el sistema de archivos y montará {{ic|/home}} cuando se acceda a la misma por primera vez, y el kenel demorará todos los accesos a los archivos de {{ic|/home}}, almacenándolos en un búfer, hasta que la partición esté lista.
  
* Lo mismo se aplica a los montajes del sistema de archivos remoto. Si  quiere que se monte sólo 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.
+
* Lo mismo se aplica a los montajes del sistema de archivos remoto. Si  quiere que se monte solo cuando se acceda, tendrá que usar el parámetro {{ic|noauto,x-systemd.automount}}. Además, puede utilizar la opción {{ic|1=x-systemd.device-timeout=#}} para especificar un tiempo de espera para el caso de que el recurso de red no esté disponible.
  
 
* Si tiene sistemas de archivos cifrados con keyfiles, también puede añadir el parámetro {{ic|noauto}} para las entradas correspondientes de {{ic|/etc/crypttab}}. Systemd no abrirá el dispositivo cifrado en el arranque, sino que esperará hasta que realmente se acceda al mismo y entonces lo abrirá automáticamente con el archivo de claves (''«keyfiles»'') especificado antes de montarlo. Esto podría ahorrar unos segundos en el arranque si se está usando, por ejemplo, un dispositivo RAID cifrado, porque systemd no tiene que esperar a que el dispositivo esté disponible. Por ejemplo:
 
* 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:
Line 170: Line 171:
 
==== LVM ====
 
==== LVM ====
  
Si tiene un volumen LVM que no se activa a través de [[Mkinitcpio|initramfs]], habilite {{ic|lvm.service}} (proporcionado por el paquete {{pkg|lvm2}}):
+
Si tiene un volumen LVM (''«Logical Volume Manager»'') que no se activa a través de [[Mkinitcpio (Español)|initramfs]], habilite {{ic|lvm.service}} (proporcionado por el paquete {{pkg|lvm2}}):
  
 
  # systemctl enable lvm
 
  # systemctl enable lvm
Line 180: Line 181:
 
===ACPI administración de la energía===
 
===ACPI administración de la energía===
  
Systemd puede manejar algunos eventos ACPI relacionados con la energía. Esto se configura a través de las siguientes opciones en {{ic|/etc/systemd/logind.conf}}:
+
Systemd puede manejar algunos eventos [[wikipedia:es:Advanced Configuration and Power Interface|ACPI]] (''«Interfaz Avanzada de Configuración y Energía»'') relacionados con la energía. Esto se configura a través de las siguientes opciones en {{ic|/etc/systemd/logind.conf}}:
 
* {{ic|HandlePowerKey}}: especifica qué acción se invoca cuando el botón de encendido se pulsa
 
* {{ic|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|HandleSuspendKey}}: especifica qué acción se invoca cuando se pulsa el botón de suspensión.
Line 186: Line 187:
 
* {{ic|HandleLidSwitch}}: especifica qué acción se invoca cuando la tapa del portátil es cerrada
 
* {{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 {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}} o {{ic|kexec}}.
+
La acción especificada puede ser una cualquiera de las siguientes: {{ic|ignore}}, {{ic|poweroff}}, {{ic|reboot}}, {{ic|halt}}, {{ic|suspend}}, {{ic|hibernate}} o {{ic|kexec}}.
  
 
Si estas opciones no están configuradas, systemd utilizará los valores predeterminados: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, y {{ic|1=HandleLidSwitch=suspend}}.
 
Si estas opciones no están configuradas, systemd utilizará los valores predeterminados: {{ic|1=HandlePowerKey=poweroff}}, {{ic|1=HandleSuspendKey=suspend}}, {{ic|1=HandleHibernateKey=hibernate}}, y {{ic|1=HandleLidSwitch=suspend}}.
  
En los sistemas que funcionan sin configuración gráfica o sólo un simple gestor de ventanas como [[i3]] o [[awesome]], esto puede reemplazar al demonio [[acpid]] que se utiliza generalmente para gestionar estos eventos ACPI.
+
En los sistemas que funcionan sin configuración gráfica o solo un simple gestor de ventanas como [[i3]] o [[awesome]], esto puede reemplazar al demonio [[acpid]] que se utiliza generalmente para gestionar estos eventos ACPI.
  
En la versión actual de systemd, las opciones {{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 DE. 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.
+
En la versión actual de systemd, las opciones {{ic|Handle}}  se aplican a todo el sistema, a menos que sean «inhibidas» (desactivadas temporalmente) por un programa, como un gestor de energía de un entorno de escritorio. Si estos inhibidores no son usados, se puede terminar en una situación en la que systemd suspenda el sistema, para luego, cuando se active el administrador de energía, este lo suspenda de nuevo.
  
{{Advertencia|Actualmente, el gestor de energía en las nuevas versiones de [[KDE]] es el único que posee 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 [[GNOME]], [[Xfce]], [[acpid]] u otros programas. La nuevas versiones están implementando esta funcionalidad.}}
+
{{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.}}
  
{{Nota|Systemd también puede utilizar otros 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.}}
+
{{Nota|Systemd también puede utilizar otros [[wikipedia:es:Front-end_y_back-end|backends]] para suspender (como [[Uswsusp]] o [[TuxOnIce]]), en conjunción con el backend por defecto del ''kernel'', con el fin de poner el equipo en estado de suspensión o hibernación.}}
  
 
====Sleep hooks====
 
====Sleep hooks====
 
Systemd no utiliza [[pm-utils]] para poner la máquina en reposo cuando se utiliza {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}. Por lo tanto, todos los hooks [[pm-utils]], incluyendo cualesquiera [[Pm-utils#Creating_your_own_hooks|hooks personalizados]] que se hayan creado, no funcionarán. Sin embargo, systemd proporciona un mecanismo similar para ejecutar scripts personalizados para estos eventos. Systemd iniciará todos los ejecutables ubicados en {{ic|/usr/lib/systemd/system-sleep/}} y pasará dos argumentos para cada uno de ellos:
 
Systemd no utiliza [[pm-utils]] para poner la máquina en reposo cuando se utiliza {{ic|systemctl suspend}} o {{ic|systemctl hibernate}}. Por lo tanto, todos los hooks [[pm-utils]], incluyendo cualesquiera [[Pm-utils#Creating_your_own_hooks|hooks personalizados]] que se hayan creado, no funcionarán. Sin embargo, systemd proporciona un mecanismo similar para ejecutar scripts personalizados para estos eventos. Systemd iniciará todos los ejecutables ubicados en {{ic|/usr/lib/systemd/system-sleep/}} y pasará dos argumentos para cada uno de ellos:
  
* Argument 1: o {{ic|pre}} o {{ic|post}}, dependiendo de si la máquina se está durmiendo o despertando
+
* Argumento 1: o {{ic|pre}} o {{ic|post}}, dependiendo de si la máquina se está durmiendo o despertando
* Argument 2: o {{ic|suspend}} o {{ic|hibernate}}, dependiendo de lo que se ha invocado
+
* Argumento 2: o {{ic|suspend}} o {{ic|hibernate}}, dependiendo de lo que se ha invocado
  
 
A diferencia de [[pm-utils]], systemd va a ejecutar estos scripts en paralelo y no uno tras el otro.
 
A diferencia de [[pm-utils]], systemd va a ejecutar estos scripts en paralelo y no uno tras el otro.
Line 214: Line 215:
 
He aquí un ejemplo de script personalizado:
 
He aquí un ejemplo de script personalizado:
  
{{hc|/usr/lib/systemd/system-sleep/example.sh|<nowiki>
+
{{hc|/usr/lib/systemd/system-sleep/ejemplo.sh|<nowiki>
 
case "$1" in
 
case "$1" in
 
   pre )
 
   pre )
Line 277: Line 278:
 
  # pacman -Ql cronie
 
  # pacman -Ql cronie
 
  [...]
 
  [...]
  cronie /etc/rc.d/crond                            #Daemon initscript listed in the DAEMONS array (unused in a "pure" systemd configuration)
+
  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    #Corresponding systemd daemon service
+
  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 el comando {{ic|systemctl}}, como este: {{ic|systemctl status <nombre_del_servicio>}}.
+
* 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>}}.
  
 
== Uso básico de systemctl==
 
== Uso básico de systemctl==
Line 322: Line 323:
 
Activa una unidad de inmediato:
 
Activa una unidad de inmediato:
  
{{bc|# systemctl start <unit>}}
+
{{bc|# systemctl start <unidad>}}
  
 
Desactiva una unidad de inmediato:
 
Desactiva una unidad de inmediato:
  
{{bc|# systemctl stop <unit>}}
+
{{bc|# systemctl stop <unidad>}}
  
 
Reinicia la unidad:
 
Reinicia la unidad:
  
{{bc|# systemctl restart <unit>}}
+
{{bc|# systemctl restart <unidad>}}
  
 
Hace que una unidad recargue su configuración:
 
Hace que una unidad recargue su configuración:
  
{{bc|# systemctl reload <unit>}}
+
{{bc|# systemctl reload <unidad>}}
  
 
Muestra el estado de una unidad, incluso si se está ejecutando o no:
 
Muestra el estado de una unidad, incluso si se está ejecutando o no:
  
{{bc|$ systemctl status <unit>}}
+
{{bc|$ systemctl status <unidad>}}
  
 
Comprueba si la unidad ya está habilitada o no:
 
Comprueba si la unidad ya está habilitada o no:
  
{{bc|$ systemctl is-enabled <unit>}}
+
{{bc|$ systemctl is-enabled <unidad>}}
  
 
Habilita el inicio automático en el arranque:
 
Habilita el inicio automático en el arranque:
  
{{bc|# systemctl enable <unit>}}
+
{{bc|# systemctl enable <unidad>}}
  
 
{{Nota|Si los servicios no tienen una sección {{ic|Install}} significa, por lo general, que se les llama de forma automática por otros servicios. Pero si necesita instalarlos manualmente, utilice la orden siguiente, reemplazando {{ic|foo}} con el nombre del servicio.
 
{{Nota|Si los servicios no tienen una sección {{ic|Install}} significa, por lo general, que se les llama de forma automática por otros servicios. Pero si necesita instalarlos manualmente, utilice la orden siguiente, reemplazando {{ic|foo}} con el nombre del servicio.
Line 356: Line 357:
 
Desactiva el inicio automático durante el arranque:
 
Desactiva el inicio automático durante el arranque:
  
{{bc|# systemctl disable <unit>}}
+
{{bc|# systemctl disable <unidad>}}
  
 
Muestra la página del manual asociada con una unidad (esto tiene que ser apoyado por el archivo .unit):
 
Muestra la página del manual asociada con una unidad (esto tiene que ser apoyado por el archivo .unit):
  
{{bc|$ systemctl help <unit>}}
+
{{bc|$ systemctl help <unidad>}}
  
 
===Administración de la energía ===  
 
===Administración de la energía ===  
Line 394: Line 395:
 
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}
 
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}
  
Sólo tiene que eliminar el enlace simbólico y systemd utilizará el {{ic|default.target}} predefinido (es decir, {{ic|graphical.target}}).
+
Solo tiene que eliminar el enlace simbólico y systemd utilizará el {{ic|default.target}} predefinido (es decir, {{ic|graphical.target}}).
  
 
{{bc|# rm /etc/systemd/system/default.target}}
 
{{bc|# rm /etc/systemd/system/default.target}}
  
 
===Usar systemd-logind===
 
===Usar systemd-logind===
{{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.}}
+
{{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.
 
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.
Line 416: Line 417:
 
* {{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=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=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. Ésto requiere del código específico proporcionado por {{ic|libsystemd-daemon.so}}.
+
* {{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 bus del sistema DBus.
+
* {{ic|1=Type=dbus}}: El servicio se considera listo cuando el {{ic|BusName}} especificado que aparece en el sistema bus es DBus.
  
 
===Reemplazar los archivos de unidad suministrados===
 
===Reemplazar los archivos de unidad suministrados===
Line 424: Line 425:
 
{{hc|/etc/systemd/system/<service-name>.service|
 
{{hc|/etc/systemd/system/<service-name>.service|
 
<nowiki>
 
<nowiki>
.include /usr/lib/systemd/system/<service-name>.service
+
.include /usr/lib/systemd/system/<nombre-del-servicio>.service
  
 
[Unit]
 
[Unit]
Line 431: Line 432:
 
</nowiki>}}
 
</nowiki>}}
 
A continuación, ejecute las siguientes órdenes para que los cambios surtan efecto:
 
A continuación, ejecute las siguientes órdenes para que los cambios surtan efecto:
   # systemctl reenable <unit>
+
   # systemctl reenable <unidad>
   # systemctl restart <unit>
+
   # systemctl restart <unidad>
 
{{Tip|Puede utilizar {{ic|systemd-delta}} para ver qué archivos de unidad han sido sobreescritos y cuáles exactamente han sido modificados.}}
 
{{Tip|Puede utilizar {{ic|systemd-delta}} para ver qué archivos de unidad han sido sobreescritos y cuáles exactamente han sido modificados.}}
  
Line 439: Line 440:
  
 
==Targets==
 
==Targets==
Systemd utiliza ''targets'' que sirven a un propósito similar a los runlevels, pero que tienen un comportamiento un poco diferente. Cada ''target'' se nomina en lugar de numerarlo y está destinado a servir a un propósito específico con la posibilidad de tener más de una acción al mismo tiempo. Algunos ''targets'' son activados heredando todos los servicios de otro ''target'' e implementandolo de servicios adicionales. Como hay ''targets'' que imitan los niveles de ejecución de SystemVinit,  es, por tanto, posible pasar de un ''target'' a otro utilizando la orden {{ic|telinit RUNLEVEL}}.
+
Systemd utiliza ''targets'' (''«objetivos»'') que sirven a un propósito similar a los ''runlevels'' (''«niveles de ejecución»''), pero que tienen un comportamiento un poco diferente. Cada ''target'' se nomina, en lugar de numerarse, y está destinado a servir a un propósito específico con la posibilidad de realizar más de una acción al mismo tiempo. Algunos ''targets'' son activados heredando todos los servicios de otro ''target'' e implementando servicios adicionales. Como hay ''targets'' 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===
 
===Conocer los targets presentes===
La siguiente orden debe ser utilizada bajo systemd en lugar del {{ic|runlevel}}:
+
La siguiente orden debe ser utilizada bajo systemd, en lugar del {{ic|runlevel}}:
 
{{bc|1=# systemctl list-units --type=target}}
 
{{bc|1=# systemctl list-units --type=target}}
  
 
===Crear un target personalizado ===  
 
===Crear un target personalizado ===  
Los niveles de ejecución (runlevels) son asignados a un fin específico de la instalación vanilla de Fedora; 0, 1, 3, 5, y 6; tiene una asignación 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 2 y 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.
+
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===  
 
===Tabla de Targets===  
Line 469: Line 470:
  
 
===Cambiar el target presente===
 
===Cambiar el target presente===
En systemd los targets están expuestos a través de «target units». Se pueden cambiar de esta manera:
+
En systemd los targets quedan expuestos a través de «target units». Se pueden cambiar de esta manera:
  
 
{{bc|# systemctl isolate graphical.target}}
 
{{bc|# systemctl isolate graphical.target}}
  
Esto sólo 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.
+
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.
  
 
===Cambiar el target predeterminado para arrancar===
 
===Cambiar el target predeterminado para arrancar===
El target estándar es {{ic|default.target}}, que es un alias por defecto 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:
+
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:
 
{{Tip|La extensión {{ic|.target}} puede omitirse.}}
 
{{Tip|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=multi-user.target}} (que corresponde con el antiguo nivel de ejecución 3),
Line 484: Line 485:
 
{{bc|# systemctl enable multi-user.target}}
 
{{bc|# systemctl enable multi-user.target}}
  
El efecto de esta orden se puede ver en la salida de {{ic | systemctl}}; se crea un enlace simbólico al nuevo target prefedinido en {{ic|/etc/systemd/system/default.target}}. Esto funciona sólo si:
+
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:
 
  [Install]
 
  [Install]
 
  Alias=default.target
 
  Alias=default.target
Line 490: Line 491:
  
 
== Journal==
 
== Journal==
Desde la versión 38, systemd tiene un sistema de registro (''«log»'') propio llamado journal. Por tanto, ya no es necesario hacer funcionar el demonio syslog. Para leer el registro (log), utilice:
+
Desde la versión 38, systemd tiene un sistema de registro (''«log»'') propio llamado journal. Por tanto, ya no es necesario hacer funcionar el demonio syslog. Para leer el registro, utilice:
  
 
  # journalctl
 
  # journalctl
Line 500: Line 501:
  
 
Ejemplos:
 
Ejemplos:
 +
 +
Mostrar todos los mensajes del arranque:
 +
 +
# journalctl -b
 +
 +
Seguir los mensajes nuevos:
 +
 +
# journalctl -f
  
 
Mostrar todos los mensajes de un ejecutable específico:
 
Mostrar todos los mensajes de un ejecutable específico:
 +
 
  # journalctl /usr/lib/systemd/systemd
 
  # journalctl /usr/lib/systemd/systemd
  
 
Mostrar todos los mensajes de un proceso específico:
 
Mostrar todos los mensajes de un proceso específico:
 +
 
  # journalctl _PID=1
 
  # journalctl _PID=1
  
Mostrar todos los mensajes de una unidad específica:
+
Mostrar todos los mensajes por una unidad específica:
  # journalctl _SYSTEMD_UNIT=netcfg.service
+
 
 +
  # journalctl -u netcfg
 +
 
 +
Véase {{ic|man journalctl}}, {{ic|systemd.journal-fields}} o esta [http://0pointer.de/blog/projects/journalctl.html entrada del blog] de Lennert para obtener más detalles.
  
Consulte {{ic|man journalctl}} y {{ic|systemd.journal-fields}}  para obtener más detalles.
 
  
 
===Límite del tamaño de journal===   
 
===Límite del tamaño de journal===   
Line 534: Line 547:
 
{{Tip|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 reconstruye, como root, initramfs, con la orden {{ic|mkinitcpio -p linux}}.}}
 
{{Tip|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 reconstruye, como root, initramfs, con la orden {{ic|mkinitcpio -p linux}}.}}
  
Para ver un listado de las unidades iniciadas, ordenadas según el tiempo que necesitan para comenzar:
+
Para ver un listado de las unidades iniciadas, ordenadas según el tiempo que necesitan para comenzar, escriba:
 
   
 
   
 
  $ systemd-analyze blame
 
  $ systemd-analyze blame
Line 543: Line 556:
  
 
====Usar bootchart====
 
====Usar bootchart====
Puede utilizar una versión de bootchart 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:
+
Puede utilizar una versión de bootchart (''«trazado gráfico del arranque»'') para visualizar la secuencia de arranque. Puesto que no es posible poner un segundo ''init'' en la línea de 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
 
  # systemctl enable bootchart
  
Consulte la [https://github.com/mmeeks/bootchart documentación bootchart] para obtener más información sobre el uso de esta versión de bootchart.
+
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.
  
 
===Readahead===
 
===Readahead===
Systemd viene con su propia implementación de readahead, 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:
+
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
 
  # systemctl enable systemd-readahead-collect systemd-readahead-replay
Line 557: Line 570:
  
 
=== Anticipar el inicio de los servicios ===  
 
=== Anticipar el inicio de los servicios ===  
Una característica central de systemd es la activación de [[D-Bus]] y del socket Esto provoca la activación de los servicios cuando se accede a ellos por primera vez, y generalmente esta forma de proceder es positiva. Sin embargo, si se sabe que un servicio (como [[UPower]]) siempre se inicia durante el arranque, entonces el tiempo de arranque global podría reducirse iniciando el servicio lo antes posible. Esto se puede lograr (si el archivo del servicio está configurado para ello, que en la mayoría de los casos lo está) mediante la ejecución de:
+
Una característica central de systemd es la activación de [[D-Bus (Español)|D-Bus]] y del socket. Esto provoca la activación de los servicios cuando se accede a ellos por primera vez, y, generalmente, esta forma de proceder es positiva. Sin embargo, si se sabe que un servicio (como [[UPower]]) siempre se inicia durante el arranque, entonces el tiempo de arranque global podría reducirse iniciando el servicio lo antes posible. Esto se puede lograr (si el archivo del servicio está configurado para ello, que en la mayoría de los casos lo está) mediante la ejecución de:
  
 
  # systemctl enable upower
 
  # systemctl enable upower
Line 563: Line 576:
 
Esto provocará el arranque de UPower tan pronto como sea posible, sin causar carreras con la activación del socket o de D-Bus.
 
Esto provocará el arranque de UPower tan pronto como sea posible, sin causar carreras con la activación del socket o de D-Bus.
  
=== Disminuir el output durante el arranque===
+
=== Disminuir la salida (de información) durante el arranque===
Cambie {{ic|verbose}} a {{ic|quiet}} en la línea del kernel del gestor de arranque. Para algunos sistemas, particularmente los que utilizan un SSD, el bajo rendimiento de la TTY es en realidad un cuello de botella, por lo que la disminución de la salida (''«output»'') se traduce, al menos, en un arranque más rápido.
+
Cambie {{ic|verbose}} a {{ic|quiet}} en la línea del kernel del gestor de arranque. Para algunos sistemas, particularmente los que utilizan un SSD, el bajo rendimiento de la TTY es, en realidad, un cuello de botella, por lo que la disminución de la salida (''«output»'') se traduce, al menos, en un arranque más rápido.
  
 
==Solución de problemas ==
 
==Solución de problemas ==

Revision as of 22:45, 18 November 2012

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary wiki Template:Article summary end De la página web del proyecto:

«systemd es un gestor del sistema y de los servicios para Linux, compatible con los initscript SysV y LSB. systemd proporciona una notable capacidad de paralelización, utiliza 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 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

Nota: Para conocer una explicación detallada del motivo por el cual Arch está cambiando a systemd, consulte este post.

Consulte también el artículo de Wikipedia.

Contents

Consideraciones previas antes de pasarse a systemd

  • Es muy recomendable cambiarse al nuevo sistema de configuración de los initscripts descrita en el artículo relativo a rc.conf. Una vez que haya establecido esta configuración, habrá hecho la mayor parte del trabajo necesario para hacer el cambio a systemd.
  • Es recomendable la lectura de la documentación sobre systemd.
  • Tenga en cuenta el hecho de que systemd tiene un sistema journal que sustituye a syslog, aunque todavía los dos pueden coexistir. Consulte la sección relativa a journal a continuación.
  • Aunque con systemd se puede reemplazar la funcionalidad de cron, acpid o xinetd, de momento no hay necesidad de abandonar el uso de los demonios tradicionales a menos que así lo desee.
  • Los initscripts interactivos no están funcionando con systemd. En particular, netcfg-menu no puede ser usado al inicio del sistema.

Instalación

Nota: systemd y systemd-sysvcompat son utilizados de forma predeterminada en los nuevos soportes de instalación desde el 2012-10-13.

El presente apartado está dirigido a las instalaciones de Arch Linux que siguen basándose en sysvinit e initscripts y que aún no han migrado a systemd.

  1. Instale systemd y añada a la línea de órdenes del kernel lo siguiente: init=/usr/lib/systemd/systemd
  2. Una vez hecho, puede habilitar los servicios deseados mediente el uso de systemctl enable <nombre_del_servicio> (los cuales equivalen aproximadamente a lo incluido en la matriz DAEMONS).
  3. Reinicie el sistema y compruebe que systemd está realmente activo mediante la orden siguiente: $ cat /proc/1/comm. Esta debería devolver la salida: systemd.
  4. Proceda a eliminar initscripts y sysvinit del sistema e instale systemd-sysvcompat.
  5. Por último, retire el parámetro init=/usr/lib/systemd/systemd en cuanto que ya no es necesario.

Información complementaria

  • Se si utiliza quiet en los parámetros del kernel, es posible removerlo durante el primer incio de systemd para identificar eventuales problemas durante el arranque.
  • No es necesario añadir su usuario a los grupos (optical, audio, scanner, etc.) para la mayoría de los casos con systemd. Los grupos pueden, incluso, causar alguna disfuncionalidad. Por ejemplo, el grupo de audio impedirá el cambio rápido de usuarios y permitirá que las aplicaciones bloqueen el software de mezcla. Cada inicio de sesión PAM proporciona una sesión logind, que, durante una sesión local, le dará permisos a través de POSIX ACLs para dispositivos de audio/vídeo, y permitirá ciertas operaciones, como el montaje de discos extraíbles, a través de udisks.
  • La eliminación del paquete initscripts romperá la compatibilidad con rc.conf. Tenga cuidado si tiene configurada una red estática con ellos o usa algunos demonios, que no han migrado aún a systemd. Vea la sección emular los initscripts para conocer más detalles sobre cómo pueden coexistir los dos sitemas.

Configuración nativa

Nota: Puede que tenga que crear estos archivos. Todos los archivos deben tener permisos 644 y propiedad de root:root.

Nombre del host

El nombre del host («sistema anfitrión») está configurado en /etc/hostname. El archivo no debe contener el dominio del sistema, si existe. Para configurar el nombre de host, escriba:

# hostnamectl set-hostname elnombredemihost

Consulte man 5 hostname y man 1 hostnamectl para más detalles.

He aquí un ejemplo del archivo:

/etc/hostname
elnombredemihost

Configurar el idioma

El ajuste del idioma («locale») predeterminado del sistema se configura en /etc/locale.conf. Para definir el idioma predeterminado, escriba:

# localectl set-locale LANG="es_ES.UTF-8"
Nota: Antes establecer el idioma predeterminado, primero necesita habilitar uno de los locales disponibles para el sistema, eliminando el comentario delante de ellos en /etc/locale.gen y, luego, ejecutar locale-gen como root. La configuración regional del idioma establecida por localectl será uno de los locales previamente descomentado en el archivo /etc/locale.gen.

Consulte man 1 localectl y man 5 locale.conf para más detalles.

  • Para más información, consulte Locale.

He aquí un ejemplo del archivo:

/etc/locale.conf
LANG=es_ES.UTF-8

Consola virtual

La configuración de la consola virtual (es decir, la distribución del teclado, la tipografía de la consola y el asignación de la consola) está definida en el archivo /etc/vconsole.conf.

/etc/vconsole.conf
KEYMAP=es
FONT=Lat2-Terminus16
FONT_MAP=
Nota: Desde systemd-194, el kernel incorpora por defecto la tipografía y distribución del teclado para us, si las opciones KEYMAP= y FONT= están vacías o no se han establecido.

Otra forma de establecer la distribución del teclado («keymap») es escribiendo:

# localectl set-keymap es

Esto tiene la ventaja de que también establece la misma distribución del teclado para su uso en X11.

Consulte man 1 localectl y man 5 vconsole.conf para más detalles.

Zona horaria

La zona horaria («timezone») se configura mediante la creación de un enlace simbólico adecuado de /etc/localtime, que apunte a un archivo de información de zonas en /usr/share/zoneinfo/. Para hacer esto de forma automática:

# timedatectl set-timezone Europe/Madrid

Véase man 1 timedatectl, man 5 localtime y man 7 archlinux para obtener más detalles.

Como alternativa, cree el enlace simbólico manualmente:

# ln -s ../usr/share/zoneinfo/Europe/Madrid /etc/localtime

Reloj del hardware

Systemd usará UTC para el reloj del hardware por defecto.

Tip: Se aconseja tener un demonio Network Time Protocol activo para mantener la hora del sistema sincronizada con la hora de Internet y con el reloj del hardware

Reloj del hardware en localtime

Si desea cambiar el horario del reloj del hardware («hardware clock») utilizando la hora local («localtime») -SERIAMENTE DESACONSEJADO-, escriba:

# timedatectl set-local-rtc true

Si desea que el reloj del hardware vuelva a estar ajustado a UTC (Universal Time Coordinated), escriba:

# timedatectl set-local-rtc false

Tenga en cuenta que si el reloj del hardware está configurado para usar la hora local (localtime), tratar con el horario de verano es complicado. Si el horario de verano (DST: Daylight Saving Time) entra en vigor cuando el ordenador está apagado, el reloj mostrará un horario equivocado en el próximo arranque (aquí algo más sobre esto). Los kernels actuales obtienen el horario del sistema del reloj del hardware directamente en el arranque, asumiendo que el reloj del hardware indica el horario UTC. Esto significa que si el horario del hardware (RTC:Real Time Clock) está definido por la hora local (localtime, en lugar de UTC), el primer horario del sistema se configurará incorrectamente, y después será corregido sucesivamente en cada arranque. Esta es posiblemente la causa de ciertos errores extraños (ir hacia atrás en el tiempo no suele ser una buena cosa).

La razón para permitir que la hora del reloj del hardware esté en localtime es habilitar un arranque dual con Windows (que utiliza localtime). Windows es capaz de gestionar la hora del reloj del hardware basándose en UTC con un sencillo ajuste del registro. Por tanto, es recomendable que Windows gestione el uso de UTC, en lugar de hacer que linux use localtime. Si se usa UTC con Windows, recuerde también desactivar la opción de Windows «Internet Time Update», con el fin de evitar confusiones entre windows y el reloj del hardware, al intentar sincronizar con el horario de internet. Al contrario, debería dejar que Linux sincronice el horario del sistema con el horario de internet, activando el demonio NTP, como se sugirió anteriormente.

  • Para más información, consulte Time.

Módulos del kernel

Hoy en día, la carga de todos los módulos necesarios se realiza automáticamente por udev, de modo que, si no quiere/necesita utilizar ningún módulo fuera del kernel, no hay necesidad de poner los módulos para que se carguen en el arranque en ningún archivo de configuración. Sin embargo, hay casos en que es posible que desee cargar un módulo adicional durante el proceso de arranque, o poner algunos en blacklist para que el equipo funcione correctamente.

Cargar módulos extras en el arranque

Los módulos adicionales al kernel que se deseen cargar durante el arranque se configuran en archivos como una lista estática ubicados en la carpeta /etc/modules-load.d/. Cada archivo de configuración es nombrado siguiendo el formato: /etc/modules-load.d/<programa>.conf. Los archivos de configuración contienen simplemente una lista de los nombres de los módulos del kernel a cargar, separados por saltos de línea. Las líneas vacías y las líneas cuyo primer signo sea # o ; se ignoran. Por ejemplo:

/etc/modules-load.d/virtio-net.conf
# Cargar virtio-net.ko en el arranque
virtio-net

Consulte man 5 modules-load.d para obtener más detalles.

Blacklisting

Los módulos incluidos en blacklist («la lista negra») tienen el mismo comportamiento que con initscripts, ya que en realidad están a cargo de kmod. Consulte Módulos en Blacklist para más detalles.

Montaje del sistema de archivos

La configuración por defecto (de fsck) comprueba automáticamente y monta los sistemas de archivos antes de iniciar los servicios que necesitan que aquellos estén montados. Por ejemplo, systemd se asegura automáticamente de que el montaje de los sistemas de archivos remotos como NFS o Samba solo se inicie después de que la red ha sido creada. Por lo tanto, el montaje de los sistemas de archivos, tanto locales como remotos, especificados en /etc/fstab deberían funcionar igualmente.

Consulte man 5 systemd.mount para más detalles.

Montaje automático

  • Si tiene una partición /home grande, tal vez sería mejor permitir que los servicios que no dependen de /home se inicien, mientras /home es comprobada. Esto se puede lograr mediante la adición de las siguientes opciones en la entrada de la partición /home en fstab :
noauto,x-systemd.automount

Esto comprobará el sistema de archivos y montará /home cuando se acceda a la misma por primera vez, y el kenel demorará todos los accesos a los archivos de /home, almacenándolos en un búfer, hasta que la partición esté lista.

  • Lo mismo se aplica a los montajes del sistema de archivos remoto. Si quiere que se monte solo cuando se acceda, tendrá que usar el parámetro noauto,x-systemd.automount. Además, puede utilizar la opción x-systemd.device-timeout=# para especificar un tiempo de espera para el caso de que el recurso de red no esté disponible.
  • Si tiene sistemas de archivos cifrados con keyfiles, también puede añadir el parámetro noauto para las entradas correspondientes de /etc/crypttab. Systemd no abrirá el dispositivo cifrado en el arranque, sino que esperará hasta que realmente se acceda al mismo y entonces lo abrirá automáticamente con el archivo de claves («keyfiles») especificado antes de montarlo. Esto podría ahorrar unos segundos en el arranque si se está usando, por ejemplo, un dispositivo RAID cifrado, porque systemd no tiene que esperar a que el dispositivo esté disponible. Por ejemplo:
/etc/crypttab
data /dev/md0 /root/key noauto

LVM

Si tiene un volumen LVM («Logical Volume Manager») que no se activa a través de initramfs, habilite lvm.service (proporcionado por el paquete lvm2):

# systemctl enable lvm

Del mismo modo, si tiene un dispositivo LVM cifrado, montado posteriormente durante el arranque (por ejemplo de /etc/crypttab), habilite lvm-on-crypt.service (también proporcionado por el paquete lvm2):

# systemctl enable lvm-on-crypt

ACPI administración de la energía

Systemd puede manejar algunos eventos ACPI («Interfaz Avanzada de Configuración y Energía») relacionados con la energía. Esto se configura a través de las siguientes opciones en /etc/systemd/logind.conf:

  • HandlePowerKey: especifica qué acción se invoca cuando el botón de encendido se pulsa
  • HandleSuspendKey: especifica qué acción se invoca cuando se pulsa el botón de suspensión.
  • HandleHibernateKey: especifica qué acción se invoca cuando se pulsa el botón de hibernación.
  • HandleLidSwitch: especifica qué acción se invoca cuando la tapa del portátil es cerrada

La acción especificada puede ser una cualquiera de las siguientes: ignore, poweroff, reboot, halt, suspend, hibernate o kexec.

Si estas opciones no están configuradas, systemd utilizará los valores predeterminados: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, y HandleLidSwitch=suspend.

En los sistemas que funcionan sin configuración gráfica o solo un simple gestor de ventanas como i3 o awesome, esto puede reemplazar al demonio acpid que se utiliza generalmente para gestionar estos eventos ACPI.

En la versión actual de systemd, las opciones Handle se aplican a todo el sistema, a menos que sean «inhibidas» (desactivadas temporalmente) por un programa, como un gestor de energía de un entorno de escritorio. Si estos inhibidores no son usados, se puede terminar en una situación en la que systemd suspenda el sistema, para luego, cuando se active el administrador de energía, este lo suspenda de nuevo.

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 Handle a ignore si desea gestionar los eventos ACPI con Xfce, acpid u otros programas. La nuevas versiones están implementando esta funcionalidad.
Nota: Systemd también puede utilizar otros backends para suspender (como Uswsusp o TuxOnIce), en conjunción con el backend por defecto del kernel, con el fin de poner el equipo en estado de suspensión o hibernación.

Sleep hooks

Systemd no utiliza pm-utils para poner la máquina en reposo cuando se utiliza systemctl suspend o systemctl hibernate. Por lo tanto, todos los hooks pm-utils, incluyendo cualesquiera hooks personalizados que se hayan creado, no funcionarán. Sin embargo, systemd proporciona un mecanismo similar para ejecutar scripts personalizados para estos eventos. Systemd iniciará todos los ejecutables ubicados en /usr/lib/systemd/system-sleep/ y pasará dos argumentos para cada uno de ellos:

  • Argumento 1: o pre o post, dependiendo de si la máquina se está durmiendo o despertando
  • Argumento 2: o suspend o hibernate, dependiendo de lo que se ha invocado

A diferencia de pm-utils, systemd va a ejecutar estos scripts en paralelo y no uno tras el otro.

La salida de cada script personalizado se registrará por systemd-suspend.service o systemd-hibernate.service para que pueda ver su propia salida en journal:

# journalctl -b -u systemd-suspend

Tenga en cuenta que también puede usar sleep.target, suspend.target o hibernate.target para conectar la unidad al estado de suspensión en lugar de usar los scripts personalizados.

He aquí un ejemplo de script personalizado:

/usr/lib/systemd/system-sleep/ejemplo.sh
case "$1" in
  pre )
    echo going to $2
    ;;
  post )
    echo waking up from $2
    ;;
esac

Consulte man 7 systemd.special y man 8 systemd-sleep para obtener más información.

Los archivos temporales

Systemd-tmpfiles utiliza archivos de configuración en /usr/lib/tmpfiles.d/ y /etc/tmpfiles.d/ para describir la creación, limpieza y eliminación de archivos y directorios temporales y volátiles que normalmente residen en directorios como /run o /tmp. Cada archivo de configuración toma el nombre con el formato /etc/tmpfiles.d/<programa>.conf. Esto sobreescribirá cualquier archivo en /usr/lib/tmpfiles.d/ con el mismo nombre.

Los tmpfiles se suministran normalmente junto con los archivos de servicios para crear directorios que se espera que existan para ciertos daemons. Por ejemplo, el demonio Samba espera que el directorio /var/run/samba exista para obtener los permisos adecuados. El tmpfile correspondiente es similar a esto:

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

Sin embargo, los tmpfiles también pueden ser usados para escribir en el arranque valores en ciertos archivos. Por ejemplo, si usa /etc/rc.local para dehabilitar la reactivación del sistema («wakeup») a través de dispositivos USB con echo USBE > /proc/acpi/wakeup, se puede utilizar, en su lugar, el siguiente tmpfile:

/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE

El método de los tmpfiles se recomienda en este caso en cuanto que systemd, en realidad, ya no admite /etc/rc.local.

Consulte man 5 tmpfiles.d para obtener más detalles.

Unidades

Un archivo de configuración de una unidad contiene información sobre un servicio, un socket, un dispositivo, un punto de montaje, un punto de automontaje, un archivo o partición swap, un objetivo de arranque, una ruta del archivo de sistema o un temporizador controlado y supervisado por systemd. La sintaxis de los archivos del tipo .desktop está basada en los estándares de «XDG Desktop Entry Specification», inspirados, a su vez, en los archivos .ini de Microsoft Windows.

Consulte man 5 systemd.unit para obtener más información.

Transición de initscripts a systemd

Emulación de los initscripts

La integración con la configuración clásica de Arch es proporcionado por el paquete initscripts. Cuando initscripts se instala en paralelo con systemd, con el sistema corriendo en systemd, systemd hará lo siguiente:

  1. Analizar la matriz DAEMONS de /etc/rc.conf e iniciar la lista de demonios al arranque.
  2. Ejecutar /etc/rc.local durante el arranque.
  3. Ejecutar /etc/rc.local.shutdown durante el apagado.

La emulación de los initscripts simplemente pretende ser una medida de transición para facilitar a los usuarios el cambio a systemd, y eventualmente poder volver atrás. Systemd nativo no se basa en la configuración centralizada de rc.conf, por lo que se recomienda el uso de los archivos de configuración nativos de systemd, los cuales tendrán prioridad sobre /etc/rc.conf.

Nota: La forma recomendada para reemplazar /etc/rc.local es escribir los archivos de servicios personalizados para cualquier cosa que desee ejecutar en el inicio del sistema. Consulte la sección correspondiente.
Nota: Si desactivó Template:Keypress para reiniciar en /etc/inittab, tendrá que volver a configurar este ajuste para systemd ejecutando systemctl mask ctrl-alt-del.target como root.

Abandonar la línea DAEMONS

Para una configuración pura de systemd, debe eliminar completamente el archivo /etc/rc.conf y habilitar los servicios únicamente mediante systemctl. Para activar cada <nombre_del_servicio>correlativo a los DAEMONS de /etc/rc.conf, ejecute:

# systemctl enable <nombre_del_servicio>
Tip: Para conocer un listado de los demonios más comunes con sus equivalentes en initscripts y systemd, consulte esta tabla.

Si el <nombre_del_servicio>.service no existe:

  • Lo más probable es que systemd utilice otro nombre. Por ejemplo,cronie.service reemplaza el lanzamiento del demonio crond y alsa-restore.service reemplaza el lanzamiento del demonio alsa. Otro ejemplo importante es el demonio network, que es reemplazado por otro conjunto de archivos de servicio (consulte Configuración de Red para más detalles.)
  • Por otro lado, el servicio puede no estar disponible para systemd. En ese caso, necesitará mantener rc.conf para iniciar dicho servicio durante el arranque.
Tip: 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:
# 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, dbus.service se activará automáticamente cuando dbus-core está instalado. alsa-store.service y alsa-restore.service también vienen habilitados automáticamente por systemd. Revise la lista de servicios disponibles y su estado utilizando la orden systemctl, como este: systemctl status <nombre_del_servicio>.

Uso básico de systemctl

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

Tip: Puede utilizar las siguientes órdenes systemctl con el parámetro -H <user>@<host> para controlar una instancia de systemd en una máquina remota. Esto utilizará SSH para conectarse a la instancia systemd remota.
Nota: systemadm es el frontend gráfico oficial para systemctl. Proporcionado por el paquete systemd-ui-gitAUR disponible en AUR.

Analizar el estado del sistema

Listado de unidades activas:

$ systemctl

o bien:

$ systemctl list-units

Listado de unidades que han tenido problemas:

$ systemctl --failed

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

$ systemctl list-unit-files

Usar las unidades

Las unidades pueden ser, por ejemplo, servicios (.service), puntos de montaje (.mount), dispositivos (.device) o sockets (.socket).

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

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

Consulte man systemd.unit para más detalles.

Activa una unidad de inmediato:

# systemctl start <unidad>

Desactiva una unidad de inmediato:

# systemctl stop <unidad>

Reinicia la unidad:

# systemctl restart <unidad>

Hace que una unidad recargue su configuración:

# systemctl reload <unidad>

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

$ systemctl status <unidad>

Comprueba si la unidad ya está habilitada o no:

$ systemctl is-enabled <unidad>

Habilita el inicio automático en el arranque:

# systemctl enable <unidad>
Nota: Si los servicios no tienen una sección Install significa, por lo general, que se les llama de forma automática por otros servicios. Pero si necesita instalarlos manualmente, utilice la orden siguiente, reemplazando foo con el nombre del servicio.
# ln -s /usr/lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/

Desactiva el inicio automático durante el arranque:

# systemctl disable <unidad>

Muestra la página del manual asociada con una unidad (esto tiene que ser apoyado por el archivo .unit):

$ systemctl help <unidad>

Administración de la energía

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

Apagado y reinicio del sistema:

$ systemctl reboot

Apagado del sistema:

$ systemctl poweroff

Apagado completo del sistema:

$ systemctl halt

Suspensión del sistema:

$ systemctl suspend

Hibernación del sistema:

$ systemctl hibernate

Iniciar un entorno de escritorio con systemd

Para habilitar el inicio de sesión gráfico, ejecute el demonio de su gestor de pantalla correspondiente (por ejemplo, KDM). Por el momento, existen los archivos de servicio para GDM, KDM, SLiM, XDM, LXDM y LightDM.

# systemctl enable kdm

Esto debería funcionar. Si no es así, podría ocurrir que tuviera un default.target configurado manualmente o de una instalación anterior:

# ls -l /etc/systemd/system/default.target
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

Solo tiene que eliminar el enlace simbólico y systemd utilizará el default.target predefinido (es decir, graphical.target).

# rm /etc/systemd/system/default.target

Usar systemd-logind

Nota: A partir de 2012-10-30, ConsoleKit ha sido reemplazado por 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 loginctl. Todas las acciones de PolicyKit, como suspender el sistema o el montaje de discos duros externos, deberían funcionar.

$ loginctl show-session $XDG_SESSION_ID

Escribir los archivos .service personalizados

Manejar las dependencias

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

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

Type

Existen diferentes tipos de arranque a tener en cuenta cuando se escribe un archivo de servicio personalizado. Esto se configura mediante el parámetro Type= en la sección [Service]. Consulte man systemd.service para una explicación más detallada.

  • Type=simple: systemd considera que el servicio debe iniciarse inmediatamente. El proceso no debe romperse. No utilice este tipo si otros servicios tienen que ser llamados por ese servicio, a menos que no sea activado por el socket.
  • Type=forking: systemd considera que el servicio debe ser iniciado antes que el proceso se rompa y el antecesor se haya terminado. Para los demonios clásicos use este tipo a menos que sepa que no es necesario, ya que la mayoría de los demonios usan doble bifurcación para indicar que están listos. Debe especificar también PIDFile= para que systemd puede realizar un seguimiento del proceso principal.
  • Type=oneshot: Esto es útil para los scripts que hacen un solo trabajo y luego concluyen. Es posible que desee también establecer RemainAfterExit= 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 que aparece en el sistema bus es DBus.

Reemplazar los archivos de unidad suministrados

Las unidades en /etc/systemd/system/ tienen prioridad sobre las de /usr/lib/systemd/system/. Para mantener su propia versión de una unidad (que no será destruida después de una actualización), copie la antigua unidad de /usr/lib / a /etc/ y haga los cambios allí. Alternativamente, puede utilizar .include para analizar un archivo de servicio existente y sobrescribir o añadir nuevas opciones. Por ejemplo, si se desea simplemente agregar una dependencia adicional al servicio, puede utilizar:

/etc/systemd/system/<service-name>.service

.include /usr/lib/systemd/system/<nombre-del-servicio>.service

[Unit]
Requires=<new dependency>
After=<new dependency>

A continuación, ejecute las siguientes órdenes para que los cambios surtan efecto:

 # systemctl reenable <unidad>
 # systemctl restart <unidad>
Tip: Puede utilizar systemd-delta para ver qué archivos de unidad han sido sobreescritos y cuáles exactamente han sido modificados.

Resaltar la sintaxis de las unidades de systemd con Vim

El resaltado de sintaxis para las unidades de systemd con Vim se puede activar mediante la instalación de vim-systemdAUR de AUR.

Targets

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

Conocer los targets presentes

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

# systemctl list-units --type=target

Crear un target personalizado

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

Tabla de Targets

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

Cambiar el target presente

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

# systemctl isolate graphical.target

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

Cambiar el target predeterminado para arrancar

El target estándar es default.target, que es un alias predefinido para graphical.target (que corresponde al antiguo nivel de ejecución 5). Para cambiar el target predeterminado en el arranque, añada uno de los siguientes parámetros del kernel al gestor de arranque:

Tip: La extensión .target puede omitirse.
  • systemd.unit=multi-user.target (que corresponde con el antiguo nivel de ejecución 3),
  • systemd.unit=rescue.target (que corresponde con el antiguo nivel de ejecución 1).

Como alternativa, se puede dejar el gestor de arranque inalterado y cambiar default.target. Esto puede hacerse usando systemctl:

# systemctl enable multi-user.target

El efecto de esta orden se puede ver en la salida de systemctl; se crea un enlace simbólico al nuevo target prefedinido en /etc/systemd/system/default.target. Esto funciona solo si:

[Install]
Alias=default.target

reside en el archivo de configuración del target. En la actualidad, tanto multi-user.target como graphical.target lo tienen.

Journal

Desde la versión 38, systemd tiene un sistema de registro («log») propio llamado journal. Por tanto, ya no es necesario hacer funcionar el demonio syslog. Para leer el registro, utilice:

# journalctl

Por defecto (cuando Storage= está definido como auto en /etc/systemd/journald.conf), journal escribe en /var/log/journal/. Si el directorio /var/log/journal/ no existe (por ejemplo, si lo ha eliminado usted o algún programa), systemd no lo crea de forma automática, sino que escribe los registros en /run/systemd/journal. Esto significa que los registros se perderán al reiniciar.

Filtrar la salida

journalctl le permite filtrar los resultados por campos específicos.

Ejemplos:

Mostrar todos los mensajes del arranque:

# journalctl -b

Seguir los mensajes nuevos:

# journalctl -f

Mostrar todos los mensajes de un ejecutable específico:

# journalctl /usr/lib/systemd/systemd

Mostrar todos los mensajes de un proceso específico:

# journalctl _PID=1

Mostrar todos los mensajes por una unidad específica:

# journalctl -u netcfg

Véase man journalctl, systemd.journal-fields o esta entrada del blog de Lennert para obtener más detalles.


Límite del tamaño de journal

Si journal se ha creado como permanente (no volátil), el límite de su tamaño se establece con un valor predeterminado correspondiente al 10% del tamaño del sistema de archivos. Por ejemplo, con /var/log/journal alojado en una partición raíz de 50 GiB, esto permitiría almacenar hasta 5 GiB de datos en journal. El tamaño máximo del journal permanente puede ser controlado por SystemMaxUse en /etc/systemd/journald.conf, por lo que, para limitarlo, por ejemplo, a 50 MiB, descomente y modifique la correspondiente línea a:

SystemMaxUse=50M

Consulte man journald.conf para más información.

Journald coexistiendo con syslog

La compatibilidad con las implementaciones del clásico syslog se proporciona a través de un socket: /run/systemd/journal/syslog, por donde pasan todos los mensajes. Para hacer que el demonio syslog funcione con journal, tiene que asociarlo a este socket en vez de a /dev/log (anuncio oficial). El paquete syslog-ng de los repositorios proporciona automáticamente la configuración necesaria.

# systemctl enable syslog-ng

Optimización

Analizar el proceso de arranque

Usar systemd-analyze

Systemd proporciona una herramienta llamada systemd-analyze que le permite analizar el proceso de arranque con el fin de mostrar qué unidades están causando ralentización en el proceso de arranque. Posteriormente, puede optimizar el sistema en consecuencia. Tiene que instalar python2-dbus y python2-cairo para usarlo.

Para ver cuánto tiempo ha empleado el arranque del espacio del kernel y del espacio del usuario, solo tiene que utilizar:

$ systemd-analyze
Tip: También será capaz de mostrar cuánto tiempo ha empleado initramfs, si se agrega el parámetro timestamp a la matriz HOOKS en /etc/mkinitcpio.conf y reconstruye, como root, initramfs, con la orden mkinitcpio -p linux.

Para ver un listado de las unidades iniciadas, ordenadas según el tiempo que necesitan para comenzar, escriba:

$ systemd-analyze blame

También puede crear un archivo SVG que describe el proceso de arranque gráficamente, similar a Bootchart:

$ systemd-analyze plot > plot.svg

Usar bootchart

Puede utilizar una versión de bootchart («trazado gráfico del arranque») para visualizar la secuencia de arranque. Puesto que no es posible poner un segundo init en la línea de comandos del kernel, no será posible utilizar cualquiera de las configuraciones estándar de bootchart. Todavía, el paquete bootchart2AUR de AUR viene con un indocumentado servicio de systemd. Después de haber instalado bootchart2, escriba:

# systemctl enable bootchart

Consulte la documentación de bootchart para obtener más información sobre el uso de esta versión de bootchart.

Readahead

Systemd viene con su propia implementación de readahead («lectura previa»), esto debería, en principio, mejorar el tiempo de arranque. Sin embargo, dependiendo de la versión del kernel y del tipo de disco duro, el tiempo puede variar (por ejemplo, podría ser más lento). Para activarlo, escriba:

# systemctl enable systemd-readahead-collect systemd-readahead-replay

Recuerde que para que readahead despliegue su trabajo, tendrá que reiniciar un par de veces.

Anticipar el inicio de los servicios

Una característica central de systemd es la activación de D-Bus y del socket. Esto provoca la activación de los servicios cuando se accede a ellos por primera vez, y, generalmente, esta forma de proceder es positiva. Sin embargo, si se sabe que un servicio (como UPower) siempre se inicia durante el arranque, entonces el tiempo de arranque global podría reducirse iniciando el servicio lo antes posible. Esto se puede lograr (si el archivo del servicio está configurado para ello, que en la mayoría de los casos lo está) mediante la ejecución de:

# systemctl enable upower

Esto provocará el arranque de UPower tan pronto como sea posible, sin causar carreras con la activación del socket o de D-Bus.

Disminuir la salida (de información) durante el arranque

Cambie verbose a quiet en la línea del kernel del gestor de arranque. Para algunos sistemas, particularmente los que utilizan un SSD, el bajo rendimiento de la TTY es, en realidad, un cuello de botella, por lo que la disminución de la salida («output») se traduce, al menos, en un arranque más rápido.

Solución de problemas

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.

Véase también