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

From ArchWiki
Jump to: navigation, search
(Usar los service file)
(flagged broken section links)
(Tag: wiki-scripts)
 
(279 intermediate revisions by 8 users not shown)
Line 2: Line 2:
 
[[Category:Daemons and system services (Español)]]
 
[[Category:Daemons and system services (Español)]]
 
[[Category:Boot process (Español)]]
 
[[Category:Boot process (Español)]]
 +
[[ar:Systemd]]
 +
[[de:Systemd]]
 +
[[el:Systemd]]
 
[[en:Systemd]]
 
[[en:Systemd]]
 +
[[fa:Systemd]]
 
[[fr:Systemd]]
 
[[fr:Systemd]]
 
[[it:Systemd]]
 
[[it:Systemd]]
 +
[[ja:Systemd]]
 +
[[pt:Systemd]]
 
[[ru:Systemd]]
 
[[ru:Systemd]]
[[zh-CN:Systemd]]
+
[[zh-cn:Systemd]]
{{Article summary start|Sumario}}
+
[[zh-tw:Systemd]]
{{Article summary text|Describe cómo instalar y configurar systemd.}}
+
{{Related articles start (Español)}}
{{Article summary heading|Relacionado}}
+
{{Related|systemd/User (Español)}}
{{Article summary wiki|Systemd/Services}}
+
{{Related|systemd/Timers}}
{{Article summary wiki|Init to systemd cheatsheet}}
+
{{Related|systemd FAQ (Español)}}
{{Article summary wiki|udev}} - systemd y udev han sido fusionados por upstream.
+
{{Related|init Rosetta (Español)}}
{{Article summary end}}
+
{{Related|Daemons List}}
 +
{{Related|udev (Español)}}
 +
{{Related|Improve boot performance}}
 +
{{Related articles end}}
 +
 
 
De la página web del [http://freedesktop.org/wiki/Software/systemd proyecto]:
 
De la página web del [http://freedesktop.org/wiki/Software/systemd proyecto]:
  
''"'''systemd''' es un gestor del sistema y de los servicios para Linux, compatible con los initscript SysV y LSB. Systemd proporciona una notable capacidad de paralelización, utiliza 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 servicio de control lógico basado en relaciones de dependencias. Puede funcionar como un reemplazo total de sysvinit."''
+
:''«'''systemd''' es un gestor del sistema y de los servicios para Linux, compatible con los initscript SysV y LSB. ''systemd'' proporciona una notable capacidad de paralelización, utiliza la activación de socket y [[D-Bus]] para iniciar los servicios, permite el inicio de los demonios bajo demanda, realiza un seguimiento de los procesos con el uso de los [[cgroups|grupos de control]] de Linux, apoya snapshotting y la restauración del estado del sistema, mantiene los puntos montaje y servicios de montaje automático e implementa un elaborado sistema de gestión de dependencias basado en un control lógico de los servicios.»''
  
{{Nota|Para una explicación detallada del motivo por el cual Arch está cambiando a systemd, consulte este [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 post].}}
+
{{Nota|Para conocer una explicación detallada del motivo por el cual Arch está cambiando a systemd, consulte este [https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 post].}}
  
Consulte también el [http://en.wikipedia.org/wiki/Systemd artículo de Wikipedia].
+
== Uso básico de systemctl==
  
==Consideraciones previas antes de pasarse a systemd==
+
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.
* Es muy recomendable cambiarse al nuevo sistema de configuración de los '''initscripts''' descrita en el [[rc.conf|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.
+
* [http://freedesktop.org/wiki/Software/systemd/ 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 [[#Journald coexistiendo con el demonio syslog clásico|sección relativa a journal]] a continuación.
+
* No se preocupe sobre si los planes de systemd incluyen reemplazar '''cron''', '''acpid''' o '''xinetd''' . Estas son cosas por las que no hay que preocuparse por el momento. Por ahora, se pueden seguir utilizando los demonios tradicionales para estas tareas.
+
  
==Instalación==
+
{{Sugerencia|Puede utilizar las siguientes órdenes {{ic|systemctl}} con el parámetro {{ic|-H ''usario''@''host''}} para controlar una instancia de systemd en una máquina remota. Esto utilizará [[SSH]] para conectarse a la instancia systemd remota.}}
Systemd puede trabajar codo con codo con el regulador {{pkg|initscripts}} de Arch Linux, y se puede habilitar/deshabilitar mediante la adición/extracción de {{ic|1=init=/bin/systemd}} de los [[kernel parameters|parámetros del kernel]].
+
  
=== Una instalación mixta systemd/sysvinit/initscripts ===
+
{{Nota|{{ic|systemadm}} es el frontend gráfico oficial para {{ic|systemctl}}. Proporcionado por el paquete {{AUR|systemd-ui-git}}{{Broken package link|{{aur-mirror|systemd-ui-git}}}} disponible en [[AUR]].}}
Es posible mantener systemd y Sysvinit instalados y usando los mismos archivos de configuración para volver hacia atrás entre ellos libremente:
+
  
# Quite el formato de configuración de initscripts ahora en desuso(debe haber avisos en el arranque) mediante los [[#Archivos de configuración nativos de systemd|archivos de configuración nativos de systemd]], y reinicie el sistema para comprobar que funcionan como era de esperar con initscripts.
+
=== Analizar el estado del sistema ===
# Instale {{Pkg|systemd}} de los [[Official Repositories|repositorios oficiales]].
+
# Añada {{ic|1=init=/bin/systemd}} a los [[Kernel parameters|parámetros del kernel]] de su bootloader.
+
# Reinicie.
+
  
Systemd iniciará los demonios listados en {{ic|/etc/rc.conf}} y ejecutará {{ic|/etc/rc.local}} y {{ic|/etc/rc.local.shutdown}} al arranque/apagado respectivamente. Si el antiguo soporte para los DAEMONS en {{ic|rc.conf}} o los scripts en {{ic|rc.local}} no es necesario, el correspondiente servicio los deshabilitará.
+
Listado de unidades activas:
 
+
{{Advertencia|En el caso de tener demonios en la matriz DAEMONS que cuentan con los equivalentes archivos de servicio nativos de systemd, estos últimos serán utilizados forma automática. Sin embargo, si el nombre del script rc y el del archivo de servicio systemd no coinciden, esto no funcionará y debe asegurarse de que sólo uno de los dos (preferiblemente el nativao está habilitado) está activado.}}
+
 
+
=== Una instalación mixta systemd/initscripts ===
+
Es posible reemplazar sysvinit con systemd, pero mantenga los initscripts para el caso de que algún scripts rc no tenga todavía el equivalente en systemd.
+
 
+
# Siga las instrucciones para una instalación mixta systemd/sysvinit/initscripts.
+
# [[#Usando_las_unidades|Activar los demonios]] formalmente enumerados en {{ic|/etc/rc.conf}} con {{ic|systemctl enable ''nombredeldemonio.'''service''' ''}}. Para conocer la correspondencia entre los demonios de {{ic|/etc/rc.conf}} con los servicios de systemd, consulte: [[Daemon#List_of_Daemons|lista de demonios]] y [[Systemd/Services|servicios]]. Los demonios que no cuentan con un servicio de systemd equivalente debe mantenerlos en la línea DAEMONS para que systemd pueda inicar los antiguos scripts rc.
+
# Instale {{Pkg|systemd-sysvcompat}}. Ésto entrará en conflicto con {{Pkg|sysvinit}}, y el prompt le pedirá que lo retire.
+
# Elimine las entradas {{ic|1=init=...}} en {{ic|/sbin/init}} siendo ahora un enlace simbólico a systemd.
+
# Reinicie.
+
 
+
La única diferencia entre esta modalidad y el mantenimiento de sysvinit es que todos los archivos binarios Sysvinit son reemplazados por enlaces simbólicos a systemctl. En cualquier caso, la funcionalidad no se modifica.
+
 
+
=== Una instalación systemd pura ===
+
Por último, es posible eliminar completamente initscripts y sysvinit y sólo utilizar systemd.
+
 
+
# Siga las instrucciones para una instalación mixta systemd/initscripts.
+
# Asegurese que no hay ningún demonio activado en la matriz DAEMONS en {{ic|rc.conf}} y que los archivos {{ic|/etc/rc.local}} y {{ic|/etc/rc.local.shutdown}} están vacios.
+
# Elimine el paquete initscripts de su sistema.
+
 
+
===Información complementaria ===
+
{{Tip|Si usted tiene {{ic|quiet}} en los parámetros de su kernel, es posible eliminarlo durante el primer inicio para poder identificar cualquier problema durante el arranque.}}
+
 
+
==Archivos de configuración nativos de systemd==
+
{{Nota|Puede que tenga que crear estos archivos}}
+
{{Pkg|systemd}} usará {{ic|/etc/rc.conf}} cuando esos archivos estén ausentes. Tenga en cuenta que ésto es una solución temporal, no a largo plazo. Se recomienda utilizar los archivos de configuración systemd en cualquier sistema, ya que los initscripts pueden utilizarlos.
+
 
+
===Hostname===
+
{{hc|/etc/hostname|mimaquina}}
+
 
+
===Consola y keymap ===
+
El archivo {{ic|/etc/vconsole.conf}} configura la consola virtual, es decir, asigna la distribución del teclado y fuentes de la consola.
+
 
+
{{hc|/etc/vconsole.conf|<nowiki>
+
KEYMAP=es
+
FONT=
+
FONT_MAP=</nowiki>}}
+
 
+
Para más información consulte: [[Fonts#Console_fonts|Fuentes de la consola]] y [[KEYMAP#Keyboard_layouts|Keymap]].
+
 
+
{{Tip|Para utilizar un kernel compilado con la fuente y la distribución del teclado en lugar del predeterminado con systemd 193 o superior, use:
+
{{hc|/etc/vconsole.conf|2=
+
KEYMAP=
+
FONT=}}
+
}}
+
 
+
===Locale (Configuración Regional)===
+
Consulte {{ic|man locale.conf}} para más opciones
+
{{hc|/etc/locale.conf|<nowiki>
+
LANG=es_ES.UTF-8
+
</nowiki>}}
+
Para más información,consulte [[Locale (Español)]].
+
===Timezone (zona horaria)===
+
Consulte {{ic|man 5 timezone}} para más opciones
+
# ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime
+
{{Nota|{{ic|/etc/localtime}} está en desuso desde systemd-190 y puede ser eliminado.}}
+
 
+
===Reloj del Hardware===
+
Systemd usará UTC por defecto para el reloj de hardware y ésta es la recomendada. 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 sin necesidad de utilizar {{ic|hwclock}}, el kernel siempre asume que el reloj del hardware indica el horario UTC. Esto significa que si el horario del sistema está en la hora local (localtime), cuando el primer sistema se configura incorrectamente luego es 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).
+
 
+
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]]. Si llega a tener problemas en el arranque dual con Windows, puede configurar el horario de la bios con su hora local. Contrariamente a la creencia popular, systemd lo soporta con:
+
 
+
{{hc|/etc/adjtime|<nowiki>
+
0.0 0.0 0.0
+
0
+
LOCAL</nowiki>}}
+
 
+
Los demás parámetros siguen siendo necesarios, pero son ignorados por systemd.
+
 
+
En general, se aconseja tener un servicio [[NTP|Network Time Protocol daemon]] funcionando para mantener el horario de la bios sincronizado con la hora del sistema.
+
 
+
===Configuración de los módulos del kernel que cargan al arranque===
+
 
+
systemd usa {{ic|/etc/modules-load.d/}} para configurar los módulos del kernel a cargar durante el inicio de una lista estática. Cada archivo de configuración se nomina en el siguiente formato {{ic|/etc/modules-load.d/<program>.conf}}. Los archivos de configuración sólo deben contener una lista de nombres de los módulos del kernel a cargar, separados por saltos de línea. Las líneas vacías y líneas cuya primer signo sea {{ic|#}} o {{ic|;}} se ignoran. Ejemplo:
+
{{hc|/etc/modules-load.d/virtio-net.conf|<nowiki>
+
# Cargar virtio-net.ko al arranque
+
virtio-net</nowiki>}}
+
Véase también [[Modprobe#Opciones]]
+
 
+
===Blacklist de los módulos del kernel===
+
 
+
blacklist (los módulos incluidos en la lista negra) funciona de la misma forma que con {{Pkg|initscripts}}, ya que en realidad está a cargo de {{Pkg|kmod}}. Consulte [[Kernel_modules#Blacklisting|Module Blacklisting]] para más detalles.
+
 
+
===Los archivos temporales===
+
 
+
Systemd-tmpfiles mantiene la configuración de los archivos 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 y 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/<program>.conf}}. Esto sobreescribirá cualquier archivo en {{ic|/usr/lib/tmpfiles.d/}} con el mismo nombre.
+
 
+
Los tmpfiles se suministran normalmente 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 algo del siguiente género:
+
{{hc|/usr/lib/tmpfiles.d/samba.conf|
+
D /var/run/samba 0755 root root
+
}}
+
 
+
Sin embargo, tmpfiles también puede ser usado para escribir los valores en ciertos archivos en el arranque. Por ejemplo, si utiliza {{ic|/etc/rc.local}} para desactivar el inicio del sistema a través de dispositivos USB con {{ic|echo USBE > /proc/acpi/wakeup}}, se puede utilizar alternativamente el siguiente tmpfile:
+
{{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 no admite {{ic|/etc/rc.local}}.
+
 
+
Consulte {{ic|man tmpfiles.d}} para más detalles.
+
 
+
=== Montajes de filesystem remotos===
+
 
+
Systemd automáticamente se asegura que el sistema de archivos remoto se monta de modo que [[NFS]] o [[Samba]] sólo se inicia después de que la red se ha iniciado bien. Sin embargo, los sistemas de archivos remotos especificados en {{ic|/etc/fstab}} deberían funcionar igualmente.
+
 
+
No obstante, usted puede que quiera usar [[#Automount|Automount]] para montajes de sistemas de archivos remotos para que los monte sólo cuando se está accediendo. Además se puede utilizar la opción {{ic|1=x-systemd.device-timeout=#}} en {{ic|/etc/fstab}} para especificar un tiempo de espera en caso de que el recurso de la red no esté disponible.
+
 
+
Consulte {{ic|man systemd.mount}} para más detalles.
+
 
+
===ACPI Power Management con systemd===
+
 
+
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}}:
+
* {{ic|HandlePowerKey}}: Apagar el sistema cuando el botón de encendido se pulsa
+
* {{ic|HandleSleepKey}}: Suspender el sistema cuando se pulsa la tecla sleep
+
* {{ic|HandleLidSwitch}}: Suspender el sistema 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}}.
+
 
+
Si estas opciones no están configuradas, systemd utilizará sus 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]], ésto 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, puede terminar en una situación en la que systemd suspende el sistema, luego, cuando se activa el administrador de energía lo suspende de nuevo.
+
 
+
{{Nota|Actualmente, el gestor de energía de las nuevas versiones de [[KDE]] es el único que posee los comandos necesarios "inhibidores". Hasta tanto los otros lo hagan, tendrá que configurar manualemnte las opciones {{ic|Handle}} a {{ic|ignore}} si desea gestioinar los eventos ACPI con [[GNOME]], [[Xfce]], [[acpid]] u otros programas. La nuevas versiones están implementando esta funcionalidad.}}
+
 
+
 
+
===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 haya creado no funcionarán. Sin embargo, systemd proporciona un mecanismo similar para ejecutar scripts personalizadas 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
+
* Argument 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.
+
 
+
La salida del script se registrará por {{ic|systemd-suspend.service}} o {{ic|systemd-hibernate.service}} para que pueda ver su propia salida en el [[Systemd_(Español)#El_Journal_de_Systemd|journal]].
+
 
+
Tenga en cuenta que también puede usar {{ic|sleep.target}}, {{ic|suspend.target}} o {{ic|hibernate.target}} para conectar la unidad al estado de suspensión en lugar de usar scripts
+
 
+
Consulte {{ic|man systemd.special}} y {{ic|man systemd-sleep}} para obtener más información.
+
 
+
==== Ejemplo ====
+
{{hc|/usr/lib/systemd/system-sleep/example.sh|<nowiki>
+
case "$1" in
+
  pre )
+
    echo going to $2
+
    ;;
+
  post )
+
    echo waking up from $2
+
    ;;
+
esac</nowiki>}}
+
 
+
===Unidad===
+
Un archivo de configuración de unidad contiene información sobre un servicio, un socket, un dispositivo, un punto de montaje, un punto de montaje automático, un archivo o partición swap, un target de arranque, una ruta de archivo de sistema o un control  temporizado y supervisado por systemd. La sintaxis está inspirada en "XDG Desktop Entry Specification" archivos  del tipo .desktop, inspirados a su vez en los archivos .ini de Microsoft Windows. Consulte {{ic|man systemd.unit}} para más información.
+
 
+
==Comandos systemd==
+
*{{ic|systemctl}}: se utiliza para controlar el estado del servicio y del sistema systemd.
+
*{{ic|systemd-cgls}}: muestra recursivamente el contenido de la jerarquía del grupo de control Linux seleccionado con un diagrama de árbol.
+
*{{ic|systemadm}}: una interfaz gráfica para systemd que permite un amplio control del sistema (disponible a través del paquete {{AUR|systemd-ui-git}} de [[AUR]]).
+
 
+
Consulte man pages para más detalles.
+
 
+
{{Tip|Puede utilizar todas los comandos siguientes {{ic|systemctl}} con el valor {{ic|-H <user>@<host>}} para controlar una instancia de systemd en una máquina remota. Use [[SSH]] para conectarse a la instancia remota de systemd.}}
+
 
+
=== Analizando el estado del sistema ===
+
Lista de unidades activas:
+
  
 
{{bc|$ systemctl}}
 
{{bc|$ systemctl}}
Line 213: Line 48:
 
{{bc|$ systemctl list-units}}
 
{{bc|$ systemctl list-units}}
  
Lista de unidades que han tenido problemas:
+
Listado de unidades que han tenido problemas:
  
 
{{bc|$ systemctl --failed}}
 
{{bc|$ systemctl --failed}}
  
Los archivos disponibles de la unidad se pueden ver en {{ic|/usr/lib/systemd/system/}} y {{ic|/etc/systemd/system/}} (este último tiene prioridad). Puede ver la lista de los archivos de unidad instalados con:
+
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:
 
{{bc|$ systemctl list-unit-files}}
 
{{bc|$ systemctl list-unit-files}}
  
===Usando las unidades===  
+
===Usar las unidades===
Las unidades pueden ser, por ejemplo, servicios ({{ic|.service}}), puntos de montaje ({{ic|.mount}}), dispositivos ({{ic|.device}}) o sockets ({{ic|.socket}}). Cuando usa {{ic|systemctl}}, por lo general, tiene que especificar el nombre completo del archivo de la unidad incluyendo el sufijo, por ejemplo, {{ic|sshd.socket}}. Sin embargo, hay unos pocos atajos que especifican la unidad en los siguientes comandos {{ic|systemctl}}:
+
 
* Si no se especifica el sufijo, systemctl asumirá que es {{ic|.service}}. Por ejemplo, {{ic|netcfg}} y {{ic|netcfg.service}} se consideran equivalentes. {{Nota|Actualmente esto no funciona con los comandos {{ic|enable}} y {{ic|disable}}.}}
+
Las unidades pueden ser, por ejemplo, servicios ({{ic|.service}}), puntos de montaje ({{ic|.mount}}), dispositivos ({{ic|.device}}) o sockets ({{ic|.socket}}).
* Los puntos de montaje se traducirá automáticamente en la correspondiente unidad {{ic|.mount}}. Por ejemplo, si especifica {{ic|/home}} será equivalente a {{ic|home.mount}}.
+
 
 +
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}}:
 +
 
 +
* Si no se especifica el sufijo, systemctl asumirá que es {{ic|.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 {{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}}.
 
* 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.
 
Consulte {{ic|man systemd.unit}} para más detalles.
 +
 +
{{Sugerencia|La mayoría de las siguientes órdenes también funcionan si se especifican varias unidades, vea {{ic|man systemctl}} para más información.}}
  
 
Activa una unidad de inmediato:
 
Activa una unidad de inmediato:
  
{{bc|# systemctl start <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:
+
Activa el inicio automático en el arranque:
  
{{bc|# systemctl enable <unit>}}
+
{{bc|# systemctl enable ''unidad''}}
  
{{Nota|Si los servicios no tienen una sección Install, por lo general significa que se les llama de forma automática por otros servicios. Pero si usted necesita instalarlo manualmente, utilice el comando siguiente, reemplazando "foo" con el nombre del servicio.
+
{{Nota|Si los servicios no tienen una sección {{ic|[Install]}} significa, por lo general, que se les llama de forma automática por otros servicios. Pero si necesita instalarlos manualmente, utilice la orden siguiente, reemplazando {{ic|foo}} con el nombre del servicio.
  
{{bc|# ln -s /usr/lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/}}
+
{{bc|# ln -s /usr/lib/systemd/system/''foo''.service /etc/systemd/system/graphical.target.wants/}}
  
 
}}
 
}}
Line 264: Line 105:
 
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 energía ===  
+
Recarga ''systemd'', escaneando en busca de unidades nuevas o modificadas:
Si usted está en una sesión local de ConsoleKit y ninguna otra sesión está activa, los siguientes comandos funcionarán sin privilegios de root. Si no es así (por ejemplo, debido a que otro usuario ha iniciado sesión en una tty), systemd automáticamente le requerirá la contraseña de root  
+
 
(consulte también [[#Reemplazar_ConsoleKit_con_systemd-logind|Reemplazar ConsoleKit con systemd-logind]]).
+
# systemctl daemon-reload
 +
 
 +
===Gestionar la energía ===  
 +
 
 +
[[polkit]] es necesario para gestionar la energía. Si se encuentra en una sesión local de {{ic|systemd-logind}} y ninguna otra sesión está activa, las órdenes siguientes funcionarán sin requerir privilegios de root. Si no es así (por ejemplo, debido a que otro usuario ha iniciado otra sesión tty), ''systemd'' automáticamente le requerirá la contraseña de root.
  
 
Apagado y reinicio del sistema:
 
Apagado y reinicio del sistema:
Line 281: Line 126:
  
 
{{bc|$ systemctl poweroff}}
 
{{bc|$ systemctl poweroff}}
 
Apagado completo del sistema:
 
 
{{bc|$ systemctl halt}}
 
  
 
Suspensión del sistema:
 
Suspensión del sistema:
Line 290: Line 131:
 
{{bc|$ systemctl suspend}}
 
{{bc|$ systemctl suspend}}
  
Hibernación del sistema:
+
Poner el sistema en hibernación:
  
 
{{bc|$ systemctl hibernate}}
 
{{bc|$ systemctl hibernate}}
  
==Runlevels/targets==
+
Poner el sistema en estado de reposo híbrido &mdash;''«hybrid-sleep»'' &mdash; (o suspensión combinada &mdash;''«suspend-to-both»''&mdash;):
Runlevels (niveles de ejecución) es un concepto superado en systemd. 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 el comando {{ic|telinit RUNLEVEL}}.
+
  
===Conocer el runlevel/targets presentes===
+
$ systemctl hybrid-sleep
Lo siguiente debe ser utilizado bajo systemd en lugar de {{ic|runlevel}}:
+
{{bc|1=# systemctl list-units --type=target}}
+
  
===Crear target personalizado ===
+
==Escribir archivos .service personalizados==
Los niveles de ejecución (runlevels) son asignados a un fin específico de la instalación de Fedora vanilla; 0, 1, 3, 5, y 6; tiene una asignación 1:1 con un específico ''target'' de systemd. Desafortunadamente, no hay buena manera de hacer lo mismo para los niveles de ejecución definidos por el usuario como el 2 y 4. Si usted hace uso de aquellos, 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 {{ic|/usr/lib/systemd/system/}} que desea habilitar.
+
  
===Tabla de Targets===
+
La sintaxis de los [[#Usar las unidades|archivos de unidad]] de ''systemd'' se inspira en los archivos .desktop de XDG Desktop Entry Specification, que, a su vez, están inspirados en los archivos .ini de Microsoft Windows.
{| border="1"
+
!SysV Runlevel!!Systemd Target!!Notas
+
|-
+
| 0 || runlevel0.target, poweroff.target || Detiene el sistema.
+
|-
+
| 1, s, single || runlevel1.target, rescue.target || Modo de usuario individual.
+
|-
+
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || Runlevels User-defined/Site-specific. Por defecto, idéntica 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 de nivel de ejecución 3, además de un inicio de sesión gráfica.
+
|-
+
| 6 || runlevel6.target, reboot.target || Reiniciar
+
|-
+
| emergency || emergency.target || Consola de emergencia
+
|-
+
|}
+
  
===Cambiar el runlevel presente===
+
===Manejar las dependencias===
En systemd los niveles de ejecución  están expuestos a través de "target units". Se puede cambiar de esta manera:
+
{{bc|# systemctl isolate graphical.target}}
+
Esto sólo cambiará el nivel de ejecución actual, y no tendrá ningún efecto sobre el siguiente arranque. Esto es equivalente a los comandos {{ic|telinit 3}} o {{ic|telinit 5}} en Sysvinit.
+
  
===Cambiar el runlevel/target predeterminado para arrancar===
+
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.
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 parámetros del kernel en el gestor de arranque:
+
* {{ic|1=systemd.unit=multi-user.target}} (que corresponde con el antiguio nivel de ejecución 3),
+
* {{ic|1=systemd.unit=rescue.target}} (que corresponde con el antiguo nivel de ejecución 1).
+
  
Alternativamente, usted puede dejar el gestor de arranque inalterado y cambiar {{ic|default.target}}. Esto puede hacerse usando {{ic|systemctl}}:
+
Las dependencias se colocan normalmente en los archivos .service y no en los .target. Por ejemplo, {{ic|network.target}} es llamado por cualquiera que sea el servicio que configure las interfaces de red, por lo tanto, la solicitud que hace después la propia unidad personalizada es suficiente, ya que {{ic|network.target}} se inicia de todos modos.
{{bc|# systemctl enable multi-user.target}}
+
  
El efecto de este comando se puede ver en la salida de {{ic | systemctl}}; crea un enlace simbólico al nuevo target prefedinido {{ic|/etc/systemd/system/default.target}}. Esto funciona sólo si:
+
===Type===
[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.
+
  
==Ejecución de DEs (Entornos de Escritorios) con systemd==
+
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.
===Usar el gestor de pantalla===
+
* {{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.
Para habilitar el inicio de sesión, ejecute el daemon de su [[Display Manager|gestor de pantalla]] correspondiente (por ejemplo, [[KDM]]). Por el momento, existen los {{ic|.service}} para [[GDM]], [[KDM]], [[Slim]], [[XDM]] y [[LXDM]].
+
* {{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]].
  
{{bc|# systemctl enable kdm.service}}
+
===Modificar los archivos de unidad suministrados===
  
Esto debería funcionar. Si no es así, podría ser que tuviera un {{ic|default.target}} configurado manualmente o de una instalación anterior:
+
Para editar un archivo de unidad proporcionado por un paquete, podemos crear un directorio llamado {{ic|/etc/systemd/system/''unit''.d/}} por ejemplo {{ic|/etc/systemd/system/httpd.service.d/}} y colocar los archivos {{ic|*.conf}} en dicho directorio para reemplazarlos o añadir nuevas opciones. ''systemd'' analizará estos archivos {{ic|*.conf}} y los aplicará antes que los de la unidad original.  Por ejemplo, si deseamos simplemente agregar una dependencia adicional a una unidad, podemos crear el siguiente archivo:
  
{{hc|# ls -l /etc/systemd/system/default.target|/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target}}
+
{{hc|/etc/systemd/system/''unit''.d/customdependency.conf|2=
 +
[Unit]
 +
Requires=''dependencia nueva''
 +
After=''dependencia nueva''}}
  
Sólo tiene que eliminar el enlace simbólico y systemd utilizará el {{ic|default.target}} predefinido (es decir, {{ic|graphical.target}}).
+
Siguiendo otro ejemplo, con el fin de reemplazar la directiva {{ic|ExecStart}} para una unidad que no es del tipo {{ic|oneshot}}, crearemos el siguiente archivo:
  
{{bc|# rm /etc/systemd/system/default.target}}
+
{{hc|/etc/systemd/system/''unit''.d/customexec.conf|2=
 +
[Service]
 +
ExecStart=
 +
ExecStart=''orden nueva''
 +
}}
  
===Usar los service file===
+
Otro último ejemplo, para reiniciar automáticamente un servicio:
{{Nota|Usando este método no se creará ninguna sesión de PAM para el propio usuario. Por lo tanto ConsoleKit (que le da acceso al apagado/reinicio de dispositivos de audio, etc) no funcionará correctamente. Para el método recomendado, véase: [[#Reemplazar_ConsoleKit_con_systemd-logind|Reemplazar ConsoleKit con systemd-logind]] y [[Automatic_login_to_virtual_console_(Español)#Con_Systemd|login automático para consola virtual]]}}
+
Si sólo está buscando una forma sencilla de empezar X directamente sin necesidad de un gestor de visualización, puede crear un archivo .service similar a éste:
+
 
+
{{hc|/etc/systemd/system/graphical.target.wants/xinit.service|<nowiki>
+
[Unit]
+
Description=Direct login to X
+
After=systemd-user-sessions.service
+
  
 +
{{hc|/etc/systemd/system/''unit''.d/restart.conf|2=
 
[Service]
 
[Service]
ExecStart=/bin/su <username> -l -c "/bin/bash --login -c xinit"
+
Restart=always
 +
RestartSec=30
 +
}}
  
[Install]
+
A continuación, ejecutaremos lo que sigue para que los cambios surtan efecto:
WantedBy=graphical.target
+
</nowiki>}}
+
  
== El Journal de Systemd==
+
# systemctl daemon-reload
Desde la versión 38 systemd tiene un sistema de registro (log) propio llamado journal.
+
# systemctl restart ''unidad''
  
Por defecto, hacer funcionar el demonio syslog ya no es necesario. Para leer el registro (log), utilice:
+
Por otro lado, podemos copiar el archivo de la antigua unidad desde {{ic|/usr/lib/systemd/system/}} a {{ic|/etc/systemd/system/}} y realizar los cambios allí. Un archivo de unidad ubicado en {{ic|/etc/systemd/system/}} siempre tiene preferencia sobre la misma unidad localizada en {{ic|/usr/lib/systemd/system/}}. Debemos tener en cuenta que cuando la unidad original localizada en {{ic|/usr/lib/}} ha cambiado debido a una actualización del paquete que lo suministra, estos cambios no se aplicarán automáticamente al archivo de unidad personalizada ubicado en {{ic|/etc/}}. De este modo, tendremos que volver a activar manualmente la unidad con la orden {{ic|systemctl reenable ''unidad''}}. Por consiguiente, se recomienda utilizar el método {{ic|*.conf}} descrito anteriormente.
{{bc|# journalctl}}
+
El sistema journal escribe en {{ic|/run/systemd/journal}}, lo que significa que los logs se pierden al reiniciar el sistema. Para evitar registros tan volátiles, se puede crear {{ic|/var/log/journal/}}:
+
{{bc|# mkdir /var/log/journal/}}
+
  
===Filtrado de salida ===
+
{{Sugerencia|Podemos utilizar la orden '''systemd-delta''' para ver qué archivos de la unidad han sido invalidados y cuáles han cambiado.}} Como los archivos de unidad suministrados se actualizarán de vez en cuando, es conveniente utilizar systemd-delta para tareas de mantenimiento del sistema.
{{ic|journalctl}} le permite filtrar los resultados por campos específicos.
+
  
Ejemplos:
+
===Resaltar la sintaxis de las unidades de systemd con Vim===
  
Mostrar todos los mensajes de un ejecutable específico:
+
El resaltado de sintaxis para las unidades de ''systemd'' con [[Vim]] se puede activar mediante la instalación de {{Pkg|vim-systemd}} desde los [[Official repositories (Español)|repositorios oficiales]].
{{bc|# journalctl /usr/lib/systemd/systemd}}
+
  
Mostrar todos los mensajes de un proceso específico:
+
==Targets==
{{bc|# journalctl /usr/lib/systemd/systemd}}
+
  
Mostrar todos los mensajes de una unidad específica:
+
''systemd'' utiliza ''targets'' (''«objetivos»'') que sirven a un propósito similar a los ''runlevels'' (''«niveles de ejecución»''), pero que tienen un comportamiento un poco diferente. Cada ''target'' se nomina, en lugar de numerarse, y está destinado a servir a un propósito específico con la posibilidad de realizar más de una acción al mismo tiempo. Algunos ''targets'' son activados heredando todos los servicios de otro ''target'' e implementando servicios adicionales. Como hay ''targets'' de ''systemd'' que imitan los runlevels de SystemVinit,  es, por tanto, posible pasar de un ''target'' a otro utilizando la orden {{ic|telinit RUNLEVEL}}.
{{bc|1=# journalctl _SYSTEMD_UNIT=netcfg.service}}
+
  
Consulte {{ic|man journalctl}} y {{ic|systemd.journal-fields}}  para obtener más detalles.
+
===Conocer los targets presentes===
  
===Límite del tamaño de journal=== 
+
La siguiente orden debe ser utilizada bajo ''systemd'', en lugar de {{ic|runlevel}}:
Si journal se ha creado como no volátil, su límite de tamaño se establece en un valor predeterminado de 10% del tamaño del sistema de archivo correspondiente. Por ejemplo, con {{ic|/var/log/journal}} alojado en una partición raíz de 50GiB ésto permitiría hasta 5GiB de datos de journal. El tamaño máximo del journal persistente puede ser controlado por {{ic|SystemMaxUse}} en {{ic|/etc/systemd/journald.conf}}, por lo que para limitarlo, por ejemplo, a 50MiB, descomente y edite la correspondiente línea a:
+
{{bc|1=# systemctl list-units --type=target}}
{{bc|1=SystemMaxUse=50M}}
+
Consulte {{ic|man journald.conf}} para más información.
+
  
===Journald coexistiendo con el demonio syslog clásico===
+
===Crear un target personalizado ===  
La compatibilidad con las implementaciones de syslog clásicos 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 unirse a este socket en vez del {{ic|/dev/log}} ([http://lwn.net/Articles/474968/ anuncio oficial]). Para syslog-ng, cambie la sección {{ic|source src}} de {{ic|/etc/syslog-ng/syslog-ng.conf}} de esta manera:
+
{{bc|<nowiki>
+
source src {
+
    unix-dgram("/run/systemd/journal/syslog");
+
    internal();
+
    file("/proc/kmsg");
+
};</nowiki>}}
+
 
+
y activar syslog-ng:
+
{{bc|# systemctl enable syslog-ng.service}}
+
 
+
==Network (Red)==
+
===Dinámico (DHCP) con dhcpcd===
+
Si sólo desea usar DHCP para la conexión de ethernet, se puede usar {{ic|dhcpcd@.service}} contenido en el paquete {{Pkg|systemd-arch-units}}. Para habilitar DHCP para {{ic|eth0}}, basta con utilizar:
+
# systemctl start dhcpcd@eth0.service
+
 
+
Puede activar el servicio para que se inicie automáticamente en el arranque con:
+
# systemctl enable dhcpcd@eth0.service
+
 
+
Algunas veces el servicio dhcpd se inicia antes que el módulo de la tarjeta de red ({{bug|30235}}), agregue manualmente el módulo de la propia tarjeta a {{ic|/etc/modules-load.d/****.conf}}. Ejemplo: cree el archivo {{ic|/etc/modules-load.d/r8169.conf}}, para una tarjeta Realtek:
+
 
+
# r8169
+
 
+
===Otras configuraciones===
+
Para las redes estáticas, wireless o configuraciones avanzadas como bridging puede utilizar [[Netcfg#systemd_support|netcfg]] or [[NetworkManager#Enable_NetworkManager_under_Native_systemd_system|NetworkManager]], que ambos proporcionan archivos de servicio de systemd.
+
{{Nota|Si tiene la intención de usar netcfg, networkmanager u otro software para administrar la red no debe iniciar ni activar dhcpcd como se ha visto en el apartado anterior.}}
+
 
+
Si necesita una configuración de red Ethernet en modo estático, pero no quiere usar [[netcfg]], hay un archivo de servicio personalizado disponible en la [[Systemd/Services#Network|página de Systemd/Services]].
+
 
+
==Integración con Arch==
+
===Emulación de los initscripts ===
+
 
+
La integración con la configuración clásica de Arch es proporcionado por el paquete {{Pkg|initscripts}}. Esto pretende ser simplemente una medida transitoria para facilitar el cambio de los usuarios a systemd.
+
 
+
{{Nota|{{ic|/etc/inittab}} no se utiliza en absoluto.}}
+
 
+
Si usted se encuentra deshabilitado {{keypress|Ctrl+Alt+Del}} para reiniciar en {{ic|/etc/inittab}}, debe volver a reconfigurar las opciones para systemd ejecutando {{ic|systemctl mask ctrl-alt-del.target}} como root.
+
 
+
====rc.conf====
+
Algunas de las variables en {{ic|/etc/rc.conf}} son soportadas. Para una configuración pura de systemd se recomienda el uso de los [[#Archivos_de_configuración_nativos_de_systemd|archivos de configuración nativos de systemd]], que tendrán prioridad sobre {{ic|/etc/rc.conf}}.
+
 
+
Variables compatibles:
+
* {{ic|LOCALE}}
+
* {{ic|KEYMAP}}
+
* {{ic|CONSOLEFONT}}
+
* {{ic|CONSOLEMAP}}
+
* {{ic|HOSTNAME}}
+
* {{ic|DAEMONS}}
+
  
Variables incompatibles con la configuración de systemd:
+
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.
* {{ic|TIMEZONE}}: haga un enlace simbolico {{ic|/etc/localtime}} al propio archivo con la información de su zona manualmente.
+
* {{ic|HARDWARECLOCK}}: Consulte [[#Reloj_del_Hardware|reloj del hardware]].
+
* {{ic|USELVM}}: use en su lugar {{ic|lvm.service}} proporcionado por {{Pkg|lvm2}}.
+
* {{ic|USECOLOR}}
+
* {{ic|MODULES}}
+
  
=== Conversión total a systemd puro===
+
===Tabla de targets===  
{{Nota|Este es el método preferido, donde el sistema no se basa más en la configuración centralizada de {{ic|rc.conf}}, sino que utiliza archivos de configuración nativos de systemd}}
+
  
Siga la configuración del sistema como se explica en [[#Archivos_de_configuración_nativos_de_systemd|archivos de configuración nativa de systemd]]. Cada archivo sustituye a una sección de {{ic|/etc/rc.conf}} como se muestra en esta tabla:
 
 
{| class="wikitable"
 
{| class="wikitable"
 +
!Runlevel de SysV!!Target de systemd!!Notas
 
|-
 
|-
! scope="col"| Configuración
+
| 0 || runlevel0.target, poweroff.target || Detiene el sistema.
! scope="col"| Archivos de configuración
+
! scope="col"| Antigua sección {{ic|/etc/rc.conf}}
+
 
|-
 
|-
| align="center"|Hostname
+
| 1, s, single || runlevel1.target, rescue.target || Modalidad de usuario único.
| align="left"|{{ic|/etc/hostname}}
+
{{ic|/etc/hosts}}
+
| align="center"|{{ic|NETWORKING}}
+
 
|-
 
|-
| Align = "center"|Console fonts and Keymap
+
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || Definidos por el usuario. Preconfigurados a 3.
| align="left"|{{ic|/etc/vconsole.conf}}
+
| align="center"|{{ic|LOCALIZATION}}
+
 
|-
 
|-
| align="center"|Locale
+
| 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.
| align="left"|{{ic|/etc/locale.conf}}
+
{{ic|/etc/locale.gen}}
+
| align="center"|{{ic|LOCALIZATION}}
+
 
|-
 
|-
| align="center"|Timezone
+
| 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.
| align="left"|{{ic|/etc/timezone}}
+
{{ic|/etc/localtime}}
+
| align="center"|{{ic|LOCALIZATION}}
+
 
|-
 
|-
| align="center"|Hardware clock
+
| 6 || runlevel6.target, reboot.target || Reinicia el sistema.
| align="left"|{{ic|/etc/adjtime}}
+
|-
| align="center"|{{ic|LOCALIZATION}}
+
| emergency || emergency.target || Consola de emergencia.
 
|-
 
|-
| align="center"|Kernel modules
 
| align="left"|{{ic|/etc/modules-load.d/}}
 
| align="center"|{{ic|HARDWARE}}
 
 
|}
 
|}
  
Para fines de transición, la sección '''DAEMONS''' {{ic|/etc/rc.conf}} sigue siendo compatible con systemd y se puede utilizar para iniciar los servicios en el arranque, incluso con una "pura" gestión de servicios de systemd  . Alternativamente, usted puede quitar el archivo {{ic|/etc/rc.conf}} por completo y habilitar los servicios en systemd. Para cada {{ic|<nombre_del_servicio>}} de la matriz '''DAEMONS''' de {{ic|/etc/rc.conf}}, escriba:
+
===Cambiar el target vigente===
# systemctl enable <nombre_del_servicio>.service
+
{{Tip|Para obtener una lista de demonios de uso común con sus initscripts y equivalentes en systemd, consulte [[Daemon#List_of_Daemons|esta tabla]].}}
+
  
Si {{ic|<nombre_del_servicio>.service}} no existe:
+
En ''systemd'' los targets quedan expuestos a través de «target units». Se pueden cambiar de esta manera:
* El archivo .service puede no estar disponible para systemd. En ese caso, usted tendrá que mantener {{ic|rc.conf}} para iniciar el servicio durante el arranque.
+
* systemd puede nombrar el servicio de manera diferente, 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 [[#Network_(Red)|Network]] para más detalles.)
+
{{Tip|Usted puede mirar dentro de un paquete que contiene los script de arranque el nombre del servicio. Por ejemplo:
+
# pacman -Ql cronie
+
[...]
+
cronie /etc/rc.d/crond                            #<-- daemon initscript listed in the DAEMONS array (unused in a "pure" systemd configuration)
+
[...]
+
cronie /usr/lib/systemd/system/cronie.service    #<-- corresponding systemd daemon service
+
[...]
+
}}
+
* systemd gestionará automáticamente la orden de inicio de estos demonios.
+
* Algunos servicios no necesitan ser explícitamente activado por el usuario. Por ejemplo, {{ic|dbus.service}} se activará automáticamente cuando {{ic|dbus-core}} está instalado. Revise la lista de servicios disponibles y su estado utilizando el comando {{ic|systemctl}} .
+
  
==Escribir los archivos .service personalizados==
+
{{bc|# systemctl isolate graphical.target}}
===Gestionar 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 antes que {{ic|A}} se haya iniciado. 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, agrega {{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 es especificado, las dos unidades se iniciarán en paralelo.
+
  
Las dependencias se colocan normalmente en los .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, iniciar después la propia unidad personalizada es suficiente, ya que {{ic|network.target}} se inicia de todos modos.
+
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.
  
===Type===
+
===Cambiar el target predeterminado para arrancar===
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 demonio debe iniciarse inmediatamente. El proceso no debe romperse. No utilice este tipo si otros servicios tienen que ser preparado con ese servicio, a menos que no sea activado por el socket.
+
* {{ic|1=Type=forking}}: systemd considera que el demonio debe ser iniciado antes que el proceso se rompa y el antecesor se haya terminado. Para los demonios clásicos usar 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 hacer un solo trabajo y luego concluir. 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 ha 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=dbus}}: El demonio se considera listo cuando el especificado {{ic|BusName}} que aparece en el sistema del bus es DBus.
+
  
===Reemplazar los archivos unit suministrados===
+
El target estándar es ''default.target'', que es un alias predefinido para ''graphical.target'' (que corresponde al antiguo nivel de ejecución 5). Para cambiar el target predeterminado en el arranque, añada uno de los siguientes [[kernel parameters|parámetros del kernel]] al gestor de arranque:
Los archivos unit en {{ic|/etc/systemd/system/}} tienen prioridad sobre los de {{ic|/usr/lib/systemd/system/}}.
+
{{Sugerencia|La extensión ''.target'' puede omitirse.}}
Para hacer su propia versión de una unidad (que no será destruido después de una actualización), copie el archivo unit antiguo de {{ic|/usr/lib /}} a {{ic|/etc/}} y hacer 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 usted desea simplemente agregar una dependencia adicional a servicio, puede utilizar:
+
* {{ic|1=systemd.unit=multi-user.target}} (que corresponde con el antiguo nivel de ejecución 3),
{{hc|/etc/systemd/system/<service-name>.service|
+
* {{ic|1=systemd.unit=rescue.target}} (que corresponde con el antiguo nivel de ejecución 1).
<nowiki>
+
.include /usr/lib/systemd/system/<service-name>.service
+
  
[Unit]
+
Como alternativa, se puede dejar el gestor de arranque inalterado y cambiar ''default.target''. Esto puede hacerse usando ''systemctl'':
Requires=<new dependency>
+
{{bc|# systemctl enable multi-user.target}}
After=<new dependency>
+
</nowiki>}}
+
A continuación, ejecute lo siguiente para que los cambios surtan efecto:
+
  # systemctl reenable <unit>
+
  # systemctl restart <unit>
+
{{Tip|Puede utilizar {{ic|systemd-delta}} para ver qué archivos unit han sido sobreescritos y cuáles exactamente han sido modificados.}}
+
  
===Resaltado de la sintaxis para los archivos de la unidad de systemd con Vim===
+
El efecto de esta orden se puede ver en la salida de '' systemctl''; se crea un enlace simbólico al nuevo target prefedinido en {{ic|/etc/systemd/system/default.target}}. Esto funciona solo si:
El resaltado de sintaxis para los archivos unit de systemd con [[Vim]] se puede activar mediante la instalación de {{AUR|vim-systemd}} de [[Arch User Repository|AUR]].
+
[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.
  
==FAQ==
+
==Archivos temporales==
Para obtener una lista actualizada de los problemas conocidos, consulte primero [http://cgit.freedesktop.org/systemd/tree/TODO TODO].
+
  
{{FAQ
+
«'''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.
|question=¿Por qué mis fuentes de consola son feas?
+
|answer=Si no hay fuente seleccionada en {{ic|/etc/vconsole.conf}} (o, alternativamente, en {{ic|/etc/rc.conf}}), entonces se usará una fuente estándar. La elección de la fuente se hace de acuerdo con una amplia gama de conjuntos de caracteres soportados. Establezca su fuente preferida para solucionar el problema.}}
+
+
{{FAQ
+
|question=¿Por qué recibo mensajes de registro en mi consola?
+
|answer=Debe establecer el nivel de registro por sí mismo. Originariamente, {{ic|/etc/rc.sysinit}} hacía éste por nosotros y establecía el nivel de registro de dmesg a {{ic|3}}, que fue un razonablemente ajuste del nivel de registro. Ahora puede añadir {{ic|1=loglevel=3}} o {{ic|quiet}} a los [[kernel parameters|parámetros del kernel]].}}
+
  
{{FAQ
+
Los archivos de configuración son proveidos normalmente junto con los archivos de servicio, y reciben su nombre en el estilo {{ic|/usr/lib/tmpfiles.d/''programa''.conf}}. Por ejemplo, el demonio [[Samba]]  espera que el directorio {{ic|/run/samba}} exista para obtener los permisos adecuados. Por tanto, el paquete {{Pkg|samba}} viene con esta configuración:
|question=¿Cómo puedo cambiar el número de gettys (consolas) que se ejecutan por defecto?
+
{{hc|/usr/lib/tmpfiles.d/samba.conf|
|answer=Para agregar otro getty (consola), basta con colocar otro enlace simbólico para crear instancias de otra getty en el directorio {{ic|/etc/systemd/system/getty.target.wants/}}:
+
D /var/run/samba 0755 root root
 +
}}
  
{{bc|<nowiki># ln -sf /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty9.service
+
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:
# systemctl daemon-reload
+
{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
# systemctl start getty@tty9.service</nowiki>}}
+
w /proc/acpi/wakeup - - - - USBE
 +
}}
  
Para quitar un getty (consola), simplemente elimina los enlaces simbólicos a la consola en el directorio {{ic|/etc/systemd/system/getty.target.wants/}}:
+
Consulte {{ic|systemd-tmpfiles}} y  {{ic|tmpfiles.d(5)}} para obtener más detalles.
  
{{bc|<nowiki># rm /etc/systemd/system/getty.target.wants/getty@tty5.service /etc/systemd/system/getty.target.wants/getty@tty6.service
+
{{nota|Este método puede no funcionar ajustando las opciones en {{ic|/sys}} desde el momento en que el servicio {{ic|systemd-tmpfiles-setup}} puede ejecutarse antes de que los módulos de los dispositivos adecuados se carguen. En este caso, se puede comprobar si el módulo tiene un parámetro para la opción que desea ajustar con {{ic|modinfo ''modulo''}} y establecer esta opción con un [[Modprobe.d#Configuration|archivo de configuración en /etc/modprobe.d]]{{Broken section link}}. De lo contrario, tendrá que escribir una [[Udev#About_udev_rules|regla udev]] para establecer el atributo apropiado tan pronto como el dispositivo lo reclame.}}
# systemctl daemon-reload
+
# systemctl stop getty@tty5.service getty@tty6.service</nowiki>}}
+
  
systemd no utiliza el archivo {{ic|/etc/inittab}}.
+
== Temporizadores ==
  
{{Nota|A partir de la versión 30 de systemd, sólo un getty se pondrá en marcha de forma predeterminada. Si cambia a otra tty, un getty se pondrá en marcha allí (toma el estilo socket-activation). Se puede forzar el inicio de consolas adicionales usando los métodos anteriores.}}}}
+
''systemd'' puede reemplazar la funcionalidad cron en gran medida. Para más información, consulte [[systemd/Timers]].
  
{{FAQ
+
== Journal==
|question=¿Cómo puedo obtener más información durante el arranque?
+
|answer=Si usted no ve ninguna salida en absoluto en la consola después de cargarse initram, esto significa que usted tiene parámetro {{ic|quiet}} en la línea de comandos del kernel. Lo mejor es quitarlo, por lo menos la primera vez que haya arrancado con systemd, para ver si todo es correcto. Luego, se podrá ver una lista en [ OK ] verde, o [ FAILED ] en rojo.
+
  
Todos los mensajes se registran en el log del sistema y si quiere averiguar sobre el estado de la ejecución del sistema use {{ic|$ systemctl}} o buscar en el registro de arranque con {{ic|journalctl}}.
+
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:
}}
+
  
{{FAQ
+
# journalctl
|question=¿Cómo puedo evitar la limpieza de la consola después del arranque?
+
 
|answer=Crea un archivo {{ic|getty@tty1.service}} copiando {{ic|/usr/lib/systemd/system/getty@.service}} en {{ic|/etc/systemd/system/getty.target.wants/getty@tty1.service}} y cambie {{ic|TTYVTDisallocate}} a {{ic|no}}.
+
Por defecto, (cuando {{ic|Storage&#61;}} está definido como {{ic|auto}} en {{ic|/etc/systemd/journald.conf}}), journal escribe en {{ic|/var/log/journal/}}. Si el directorio {{ic|/var/log/journal/}} no existe (por ejemplo, si lo ha eliminado usted o algún programa), systemd '''no''' lo crea de forma automática, sino que escribe los registros en {{ic|/run/systemd/journal}}. Esto significa que los registros se perderán al reiniciar.
 +
 
 +
{{Sugerencia|Si {{ic|/var/log/journal/}} reside en un sistema de archivos [[btrfs]] debería considerar la opción de desactivar [[Btrfs#Copy-On-Write_.28CoW.29|Copy-on-Write]] para el directorio:
 +
# chattr +C /var/log/journal
 
}}
 
}}
  
{{FAQ
+
===Filtrar la salida ===
|question=¿Qué opciones del kernel tengo que habilitar en el mio en caso de que no use el kernel oficial de Arch?
+
|answer=Kernels anteriores a 2.6.39 no son compatibles.
+
  
Esta es una lista parcial de las opciones requeridas/recomendadas, podría haber más:
+
{{ic|journalctl}} le permite filtrar los resultados por campos específicos. Tenga en cuenta que si hay muchos mensajes para mostrar o el filtrado que hay que hacer abarca mucho tiempo, la salida de esta orden puede retrasarse durante bastante tiempo.
  
{{bc|<nowiki>
+
Ejemplos:
CONFIG_AUDIT=y (recomendado)
+
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y (no es necesario, se puede romper sysvinit compat)
+
CONFIG_CGROUPS=y
+
CONFIG_IPV6=[y|m] (muy recomendable)
+
CONFIG_UEVENT_HELPER_PATH="" (si usted no usa un initramfs)
+
CONFIG_DEVTMPFS=y
+
CONFIG_DEVTMPFS_MOUNT=y (se recomienda, si usted no usa un initramfs)
+
CONFIG_RTC_DRV_CMOS=y (muy recomendable)
+
CONFIG_FANOTIFY=y (necesario para readahead)
+
CONFIG_AUTOFS4_FS=[y|m]
+
CONFIG_TMPFS_POSIX_ACL=y (se recomienda, si usted desea utilizar pam_systemd.so)
+
</nowiki>}}}}
+
  
{{FAQ
+
Mostrar todos los mensajes del arranque:
|question=¿Qué otras unidades dependen de una unidad?
+
|answer=Por ejemplo, si usted quiere averiguar qué servicios y target activa {{ic|multi-user.target}}, utilice algo como esto:
+
# journalctl -b
{{hc|$ systemctl show -p "Wants" multi-user.target|2=Wants=rc-local.service avahi-daemon.service rpcbind.service NetworkManager.service acpid.service dbus.service atd.service crond.service auditd.service ntpd.service udisks.service bluetooth.service cups.service wpa_supplicant.service getty.target modem-manager.service portreserve.service abrtd.service yum-updatesd.service upowerd.service test-first.service pcscd.service rsyslog.service haldaemon.service remote-fs.target plymouth-quit.service systemd-update-utmp-runlevel.service sendmail.service lvm2-monitor.service cpuspeed.service udev-post.service mdmonitor.service iscsid.service livesys.service livesys-late.service irqbalance.service iscsi.service}}
+
  
En lugar de {{ic|Wants}} pruebe con {{ic|WantedBy}}, {{ic|Requires}}, {{ic|RequiredBy}}, {{ic|Conflicts}}, {{ic|ConflictedBy}}, {{ic|Before}}, {{ic|After}} para los respectivos tipos de dependencias y a su inversa.}}
+
Sin embargo, a veces a uno le interesan no los mensajes actuales, sino los mensajes desde el arranque anterior (por ejemplo, si ocurrió un fallo del sistema irrecuperable). Esto es posible pasando el parámetro {{ic|-b}}: {{ic|journalctl -b -0}} muestra los mensajes del arranque actual, {{ic|journalctl -b -1}} muestra los mensajes del arranque anterior, {{ic|journalctl -b -2}} muestra los mensajes desde los dos últimos arranques y así sucesivamente. Véase {{ic|man 1 journalctl}} para una descripción completa, dado que los argumentos que se pueden pasar a la orden hacen que el filtrado pueda ser mucho más potente.
  
{{FAQ
+
Seguir los mensajes nuevos:
|question=Mi equipo se apaga, pero el power permanece encendido.
+
|answer=Use
+
systemctl poweroff
+
En lugar de systemctl halt}}
+
  
{{FAQ
+
# journalctl -f
|question=Después de migrar a systemd, ¿por qué no puedo montar fakeRAID?
+
|answer=Asegúrese de usar {{bc|# systemctl enable dmraid.service}}
+
}}
+
  
{{FAQ
+
Mostrar todos los mensajes de un ejecutable específico:
|question=¿Cómo puedo hacer un script que se ejecute durante el proceso de arranque?
+
|answer=Crear un nuevo archivo en {{ic|/etc/systemd/system}} (por ejemplo, ''myscript''.service.) Y agregue el siguiente contenido:
+
{{bc|<nowiki>
+
[Unit]
+
Description=My script
+
  
[Service]
+
# journalctl /usr/lib/systemd/systemd
ExecStart=/usr/bin/my-script
+
  
[Install]
+
Mostrar todos los mensajes de un proceso específico:
WantedBy=multi-user.target
+
</nowiki>}}
+
Then
+
{{bc|# systemctl enable ''myscript''.service}}
+
This example assumes you want your script to start up when the target multi-user is launched.
+
}}
+
  
{{FAQ
+
# journalctl _PID=1
|question=Estado del .service dice "active (exited)" en verde. (Por ejemplo iptables)
+
|answer=Esto es perfectamente normal.
+
En el caso de iptables es porque no hay ningún demonio para funcionar, que está controlada en el kernel. Por lo tanto, las salidas después de las reglas se han cargado.
+
  
Para comprobar si las reglas de iptables se han cargado correctamente:
+
Mostrar todos los mensajes por una unidad específica:
{{bc|iptables --list}}
+
}}
+
  
==Optimización==
+
# journalctl -u netcfg
===systemd-analyze===
+
Systemd proporciona una herramienta llamada {{ic|systemd-analyze}} que le permite analizar su proceso de arranque con el fin de mostrar los archivos de unidad que 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 kernel y del userspace, sólo tiene que utilizar:
+
Mostrar búfer circular del kernel:
{{bc|$ systemd-analyze}}
+
{{Tip|Si se agrega el parámetro {{ic|timestamp}} a la matriz {{ic|HOOKS}} en {{ic|/etc/mkinitcpio.conf}} y si reconstruye initramfs, también será capaz de mostrar cuánto tiempo ha empleado initramfs.}}
+
  
Para una lista del comienzo de los archivos de la unidad, ordenados según el tiempo que se necesita para comenzar:
+
# journalctl _TRANSPORT=kernel
{{bc|$ systemd-analyze blame}}
+
  
También puede crear un archivo SVG que describe el proceso de arranque gráficamente, similar a [[Bootchart]]:
+
Véase {{ic|man 1 journalctl}}, {{ic|man 7 systemd.journal-fields}} o esta [http://0pointer.de/blog/projects/journalctl.html entrada del blog] de Lennert para obtener más detalles.
{{bc|$ systemd-analyze plot > plot.svg}}
+
  
====Habilitar bootchart junto con systemd====
+
===Límite del tamaño de journal===
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. Sin embargo, el paquete {{AUR|bootchart2}} de [[AUR]] viene con un indocumentado servicio de systemd. Después de haber instalado bootchart2 hacer:
+
{{bc|# systemctl enable bootchart.service}}
+
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.
+
  
===Atajos Shell===
+
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:
La gestión de los demonios a través de systemd require un poco de texto para realizar tareas tales como el arranque, la parada, al activación, el control del estado, etc. Las funciones siguientes se pueden agregar a {{ic|~/.bashrc}} para ayudar a simplificar la interacción con systemd y mejorar la experiencia general.
+
{{bc|1=SystemMaxUse=50M}}
 +
Consulte {{ic|man journald.conf}} para más información.
  
 +
===Journald coexistiendo con syslog ===
  
{{bc|<nowiki>if ! systemd-notify --booted; then # not using systemd
+
La compatibilidad con las implementaciones del clásico syslog se proporciona a través de un
  alias start='sudo rc.d start'
+
socket: {{ic|/run/systemd/journal/syslog}}, por donde pasan todos los mensajes.
  alias restart='sudo rc.d restart'
+
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.
  alias stop='sudo rc.d stop'
+
{{bc|# systemctl enable syslog-ng}}
else
+
Podemos encontrar un buen tutorial de {{ic|journalctl}} [http://0pointer.de/blog/projects/journalctl.html aquí].
  alias start='sudo systemctl start'
+
  alias restart='sudo systemctl restart'
+
  alias stop='sudo systemctl stop'
+
  alias enable='sudo systemctl enable'
+
  alias status='sudo systemctl status'
+
  alias disable='sudo systemctl disable'
+
fi
+
</nowiki>}}
+
  
=== Disminuir el output ===
+
=== Reenviar journald a /dev/tty12 ===
Cambie {{ic|verbose}} a {{ic|quiet}} en la línea del kernel en GRUB. Para algunos sistemas, particularmente en que utilizan un SSD, el bajo rendimiento de la TTY es en realidad un cuello de botella, y la disminución de la salida (output) se traduce, al menos, en un arranque más rápido.
+
  
===Comienzo temprano===
+
En {{ic|/etc/systemd/journald.conf}} active lo siguiente:
Una característica central de systemd es la activación de de dbus y de socket, lo que provoca la activación de los servicios cuando se acceda por primera vez, y generalmente es positivo. Sin embargo, si usted sabe que un servicio (como console-kit) siempre se inicia durante el arranque, entonces el tiempo de arranque global podría reducirse arrancándolo lo posible. Esto se puede lograr (si el archivo de servicio está configurado para ello, que en la mayoría de los casos lo es) mediante la emisión de:
+
  
{{bc|# systemctl enable console-kit-daemon.service}}
+
ForwardToConsole=yes
 +
TTYPath=/dev/tty12
 +
MaxLevelConsole=info
  
Esto provocará el arranquede de console-kit tan pronto como sea posible, sin causar carreras con la activación del socket o  dbus.
+
Reinicie journald con {{ic|sudo systemctl restart systemd-journald}}.
  
===Automount===
+
== Solución de problemas ==
La configuración por defecto consulta con fsck y monta primero todos los sistemas de archivos antes de iniciar la mayoría de los demonios y servicios. Si usted tiene un gran partición  {{ic|/home}}, tal vez sería mejor permitir que los servicios que no dependen de {{ic|/home}} inicien, mientras {{ic|/home}} está controlada. Esto se puede lograr mediante la adición de las siguientes opciones para la entrada fstab de su {{ic | / home}} partición:
+
=== Investigar errores de systemd ===
  
noauto, x-systemd.automount
+
Como ejemplo, vamos a investigar un error con el servicio {{ic|systemd-modules-load}}:
  
Esto controlará y montará  {{ic|/home}} cuando se acceda por primera vez, y el kenel almacenará todos los accesos a los archivos de {{ic|/home}} hasta que esté listo.
+
'''1.''' Vamos a determinar los servicios de ''systemd'' que fallan al inicio:
 +
{{hc|1=$ systemctl --state=failed|2=
 +
systemd-modules-load.service  loaded '''failed failed'''  Load Kernel Modules
 +
}}
  
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 accede de forma automática y luego abrirlo con el archivo de claves especificada antes de montarlo. Ésto podría ahorrar unos segundos en el arranque si usted está usando un dispositivo RAID cifrado por ejemplo, porque systemd no tiene que esperar a que el dispositivo esté disponible. Por ejemplo:
+
'''2.''' Encontramos un problema con el servicio {{ic|systemd-modules-load}}. Indaguemos un poco más:
{{hc|/etc/crypttab|data /dev/md0 /root/key noauto}}
+
{{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''')
 +
}}
  
===Readahead===
+
'''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):
systemd viene con su propia implementación de readahead, esto debería, en principio, mejorar el tiempo de arranque. Sin embargo, dependiendo de su versión del kernel y el tipo de su disco duro, su experiencia puede variar (por ejemplo, podría ser más lento). Para activarlo, haga:
+
{{hc|1=$ journalctl -b _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''''
 +
}}
  
{{bc|<nowiki># systemctl enable systemd-readahead-collect.service systemd-readahead-replay.service</nowiki>}}
+
'''4.''' Vemos que algunos de los ajustes del módulo del kernel tienen valores erróneos. Por lo tanto, echemos un vistazo a estos valores en {{ic|/etc/modules-load.d/}}:
 +
{{hc|$ ls -Al /etc/modules-load.d/|
 +
...
 +
-rw-r--r--  1 root root    79  1. Dez 2012  blacklist.conf
 +
-rw-r--r--  1 root root    1  2. Mär 14:30 encrypt.conf
 +
-rw-r--r--  1 root root    3  5. Dez 2012  printing.conf
 +
-rw-r--r--  1 root root    6 14. Jul 11:01 realtek.conf
 +
-rw-r--r--  1 root root    65  2. Jun 23:01 virtualbox.conf
 +
...
 +
}}
  
Recuerde que para que readahead despliegue su trabajo, tendrá que reiniciar un par de veces.
+
'''5.''' El mensaje del error {{ic|Failed to find module 'blacklist usblp'}}  puede estar relacionado con un mal ajuste de {{ic|blacklist.conf}}. Podemos desactivarlo insertando un signo '''#''' delante de cada opción que hemos descubierto que falla por medio del paso 3:
 +
{{hc|/etc/modules-load.d/blacklist.conf|
 +
'''#''' blacklist usblp
 +
'''#''' install usblp /bin/false
 +
}}
  
=== Reemplazar ConsoleKit con systemd-logind ===
+
'''6.''' Ahora, intente iniciar {{ic|systemd-modules-load}}:
A partir de {{Pkg|polkit}} 0.107 (actualmente en repositorio [testing]), [[ConsoleKit]] puede ser completamente reemplazado por {{ic|systemd-logind}}. Sin embargo, actualmente no existe un gestor de pantallas en los repositorios de Arch Linux que soporte de forma nativa {{ic|systemd-logind}} sin la función aún de [[ConsoleKit]]. El método más fácil para ser capaz de eliminar [[ConsoleKit]] es  [[Automatic_login_to_virtual_console_(Español)#Con_systemd|conexión automática a una consola virtual]] e [[Start_X_at_Boot_(Español)|iniciar X desde aquí]]. Es importante que, como se menciona en dicho artículo, el servidor X se inicie en la misma consola virtual que inicia sesión, de lo contrario systemd no puede realizar un seguimiento de la sesión de usuario. A continuación, puede simplemente eliminar {{ic|ck-launch-session}} de su {{ic|~/.xinitrc}}.
+
$ 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.
  
Con el fin de comprobar el estado de la sesión de usuario, puede utilizar {{ic|loginctl}}Para ver si su sesión de usuario está configurada correctamente, compruebe si el comando siguiente contiene {{ic|1=Active=yes}}. Todas las acciones de {{Pkg|polkit}} como suspender el sistema o montar unidades externas con [[Udisks]]  deberían entonces funcionar automáticamente.
+
Si todo está bien, se puede verificar que el servicio se ha iniciado satisfactoriamente con:
 +
{{hc|$ systemctl status systemd-modules-load|2=
 +
systemd-modules-load.service - Load Kernel Modules
 +
  Loaded: '''loaded''' (/usr/lib/systemd/system/systemd-modules-load.service; static)
 +
  Active: '''active (exited)''' since So 2013-08-25 12:22:31 CEST; 34s ago
 +
    Docs: man:systemd-modules-load.service(8)
 +
          man:modules-load.d(5)
 +
  Process: 19005 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
 +
Aug 25 12:22:31 mypc systemd[1]: '''Started Load Kernel Modules'''.
 +
}}
  
$ loginctl show-session <session-id>
+
A menudo se puede resolver este tipo de problemas como se ha descrito arriba. Para indagar más, mire el epígrafe siguiente: «'''Diagnosticar problemas de arranque'''».
  
{{Note|Si utiliza [[NetworkManager]], hay que volver a compilar con el soporte systemd de [[ABS]] mediante el ajuste {{ic|1=--with-session-tracking=systemd}} en [[PKGBUILD]].}}
+
=== Diagnosticar problemas de arranque ===
 +
 
 +
Arranque con esos parámetros en la línea de órdenes del kernel:
 +
{{ic|<nowiki>systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M</nowiki>}}
 +
 
 +
[http://freedesktop.org/wiki/Software/systemd/Debugging Más información sobre depuración de errores]
  
==Solución de problemas ==
 
 
===Apagar/reiniciar se hace terriblemente largo===
 
===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 usted es afectado así, consulte [http://freedesktop.org/wiki/Software/systemd/Debugging#Shutdown_Completes_Eventually este artículo].
 
  
====SLiM y sesión xfce====
+
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].
Una instalación que puede producir una congelación de cierre es Xfce en relación con Slim: Apagar/reiniciar con xfce-sesión provoca que slim.service puede tardar alrededor de un minuto hasta que systemd fuerza el cierre.
+
Una solución es crear un slim.service modificado:
+
  
{{hc|/etc/systemd/system/slim.service|<nowiki>
+
=== Los procesos de corta duración parecen no registrar ninguna salida ===
[Unit]
+
Description=SLiM Simple Login Manager
+
After=systemd-user-sessions.service
+
  
[Service]
+
Si {{ic|systemctl -u foounit.service}} no muestra ninguna salida para un servicio de breve duración, compruebe el PID. Por ejemplo, si {{ic|systemd-modules-load.service}} falla, y {{ic|systemctl status systemd-modules-load}} muestra que es seguido con PID 123, entonces es posible ver la salida de journal para dicho PID, por ejemplo {{ic|journalctl -b _PID&#61;123}}. Los campos con metadatos para journal, como _SYSTEMD_UNIT y _COMM, se recogen en modo asíncrono y se basan en la carpeta {{ic|/proc}} para el proceso existente. La reparación de este proceso requiere la reparación del kernel para proporcionar estos datos por medio de una conexión socket, de forma similar a SCM_CREDENTIALS.
Type=forking
+
PIDFile=/var/lock/slim.lock
+
ExecStart=/usr/bin/slim -d
+
ExecStop=/bin/kill -9 $MAINPID
+
ExecStopPost=/bin/rm /var/lock/slim.lock
+
  
[Install]
+
=== Desactivar el volcado de sucesos de journal respecto de las aplicaciones ===
WantedBy=graphical.target</nowiki>}}
+
  
Esto hace que SLiM se termine usando SIGKILL. Puesto que el archivo de bloqueo también se elimina ésto no causa un problema.
+
Ejecute lo siguiente para sobrescribir la configuración de {{ic|/lib/sysctl.d/}}:
 +
# ln -s /dev/null /etc/sysctl.d/50-coredump.conf
 +
# sysctl kernel.core_pattern=core
  
===Si algunos servicios no se inician===
+
Esto desactivará el registro de coredumps en journal.
Si el archivo {{ic|/var/tmp}} es un enlace simbólico a {{ic|/tmp}}, provocará que algunos servicios fallen el arranque cuando se inicia systemd. En estos casos, el estado de los procesos (mediante {{ic|systemctl status <service>}}) será "226/NAMESPACE". Para superar este bloqueo, basta con quitar el propio enlace simbólico del archivo {{ic|/var/tmp}} y reinstalar el paquete {{pkg|filesystem}}.
+
 
 +
Tenga en cuenta que el RLIMIT_CORE por defecto es 0, lo que significa que tampoco hay archivos básicos que escribir.
 +
Si quiere que dichos archivos existan, necesita añadir el valor «unlimit» para el tamaño del archivo básico con la siguiente orden:
 +
$ ulimit -c unlimited
 +
 
 +
Véase [http://www.freedesktop.org/software/systemd/man/sysctl.d.html sysctl.d] y [https://www.kernel.org/doc/Documentation/sysctl/kernel.txt the documentation for /proc/sys/kernel] para obtener más información.
 +
 
 +
=== Mensaje de error al reiniciar o apagar ===
 +
==== cgroup : option or name mismatch, new: 0x0 "", old: 0x4 "systemd" ====
 +
Véase [https://bbs.archlinux.org/viewtopic.php?pid=1372562#p1372562 este hilo] para mayor explicación.
 +
==== watchdog watchdog0: watchdog did not stop! ====
 +
Véase [https://bbs.archlinux.org/viewtopic.php?pid=1372562#p1372562 este hilo] para mayor explicación.
  
 
== Véase también ==
 
== Véase también ==
 +
 
*[http://www.freedesktop.org/wiki/Software/systemd Sitio Web Oficial]
 
*[http://www.freedesktop.org/wiki/Software/systemd Sitio Web Oficial]
*[http://0pointer.de/public/systemd-man/ Manual systemd]
+
*[[Wikipedia:systemd|Artículo de Wikipedia]]
*[http://freedesktop.org/wiki/Software/systemd/Optimizations Optimizaciones systemd]
+
*[http://0pointer.de/public/systemd-man/ Páginas del manual]
 +
*[http://freedesktop.org/wiki/Software/systemd/Optimizations Optimizar systemd]
 
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]
 
*[http://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions FAQ]
 
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Consejos y trucos]
 
*[http://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks Consejos y trucos]
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd para administradores (PDF)]
+
*[http://0pointer.de/public/systemd-ebook-psankar.pdf systemd para Administradores (PDF)]
 
*[http://fedoraproject.org/wiki/Systemd Acerca de systemd en Fedora Project]
 
*[http://fedoraproject.org/wiki/Systemd Acerca de systemd en Fedora Project]
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems Cómo depurar problemas en Systemd]
+
*[http://fedoraproject.org/wiki/How_to_debug_Systemd_problems Cómo depurar problemas en systemd]
*[http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html Arrancando: Herramientas y consejos para systemd, una herramienta de inicio de Linux. In The H]
+
*[http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html Two] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html part] artículo introductorio de la revista ''The H Open''.
*[http://0pointer.de/blog/projects/systemd.html Lennart's blog story]
+
*[http://0pointer.de/blog/projects/systemd.html Historia del blog de Lennart]
*[http://0pointer.de/blog/projects/systemd-update.html status update]
+
*[http://0pointer.de/blog/projects/systemd-update.html Status update]
*[http://0pointer.de/blog/projects/systemd-update-2.html status update2]
+
*[http://0pointer.de/blog/projects/systemd-update-2.html Status update2]
*[http://0pointer.de/blog/projects/systemd-update-3.html status update3]
+
*[http://0pointer.de/blog/projects/systemd-update-3.html Status update3]
*[http://0pointer.de/blog/projects/why.html most recent summary]
+
*[http://0pointer.de/blog/projects/why.html Resumen más reciente]
 +
*[http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Fedora's SysVinit to systemd cheatsheet]
 +
*[[Allow users to shutdown|Configurar systemd para permitir apagar a los usuarios normales]]

Latest revision as of 17:04, 6 August 2016

De la página web del proyecto:

«systemd es un gestor del sistema y de los servicios para Linux, compatible con los initscript SysV y LSB. systemd proporciona una notable capacidad de paralelización, utiliza la activación de socket y D-Bus para iniciar los servicios, permite el inicio de los demonios bajo demanda, realiza un seguimiento de los procesos con el uso de los grupos de control de Linux, apoya snapshotting y la restauración del estado del sistema, mantiene los puntos montaje y servicios de montaje automático e implementa un elaborado sistema de gestión de dependencias basado en un control lógico de los servicios.»
Nota: Para conocer una explicación detallada del motivo por el cual Arch está cambiando a systemd, consulte este post.

Uso básico de systemctl

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

Sugerencia: Puede utilizar las siguientes órdenes systemctl con el parámetro -H usario@host para controlar una instancia de systemd en una máquina remota. Esto utilizará SSH para conectarse a la instancia systemd remota.
Nota: systemadm es el frontend gráfico oficial para systemctl. Proporcionado por el paquete systemd-ui-gitAUR[broken link: archived in aur-mirror] disponible en AUR.

Analizar el estado del sistema

Listado de unidades activas:

$ systemctl

o bien:

$ systemctl list-units

Listado de unidades que han tenido problemas:

$ systemctl --failed

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

$ systemctl list-unit-files

Usar las unidades

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

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

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

Consulte man systemd.unit para más detalles.

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

Activa una unidad de inmediato:

# systemctl start unidad

Desactiva una unidad de inmediato:

# systemctl stop unidad

Reinicia la unidad:

# systemctl restart unidad

Hace que una unidad recargue su configuración:

# systemctl reload unidad

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

$ systemctl status unidad

Comprueba si la unidad ya está habilitada o no:

$ systemctl is-enabled unidad

Activa el inicio automático en el arranque:

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

Desactiva el inicio automático durante el arranque:

# systemctl disable unidad

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

$ systemctl help unidad

Recarga systemd, escaneando en busca de unidades nuevas o modificadas:

# systemctl daemon-reload

Gestionar la energía

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

Apagado y reinicio del sistema:

$ systemctl reboot

Apagado del sistema:

$ systemctl poweroff

Suspensión del sistema:

$ systemctl suspend

Poner el sistema en hibernación:

$ systemctl hibernate

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

$ systemctl hybrid-sleep

Escribir archivos .service personalizados

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

Manejar las dependencias

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

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

Type

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

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

Modificar los archivos de unidad suministrados

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

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

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

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

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

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

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

# systemctl daemon-reload
# systemctl restart unidad

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

Sugerencia: Podemos utilizar la orden systemd-delta para ver qué archivos de la unidad han sido invalidados y cuáles han cambiado.
Como los archivos de unidad suministrados se actualizarán de vez en cuando, es conveniente utilizar systemd-delta para tareas de mantenimiento del sistema.

Resaltar la sintaxis de las unidades de systemd con Vim

El resaltado de sintaxis para las unidades de systemd con Vim se puede activar mediante la instalación de vim-systemd desde los repositorios oficiales.

Targets

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

Conocer los targets presentes

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

# systemctl list-units --type=target

Crear un target personalizado

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

Tabla de targets

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

Cambiar el target vigente

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

# systemctl isolate graphical.target

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

Cambiar el target predeterminado para arrancar

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

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

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

# systemctl enable multi-user.target

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

[Install]
Alias=default.target

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

Archivos temporales

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

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

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

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

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

Consulte systemd-tmpfiles y tmpfiles.d(5) para obtener más detalles.

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

Temporizadores

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

Journal

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

# journalctl

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

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

Filtrar la salida

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

Ejemplos:

Mostrar todos los mensajes del arranque:

# journalctl -b

Sin embargo, a veces a uno le interesan no los mensajes actuales, sino los mensajes desde el arranque anterior (por ejemplo, si ocurrió un fallo del sistema irrecuperable). Esto es posible pasando el parámetro -b: journalctl -b -0 muestra los mensajes del arranque actual, journalctl -b -1 muestra los mensajes del arranque anterior, journalctl -b -2 muestra los mensajes desde los dos últimos arranques y así sucesivamente. Véase man 1 journalctl para una descripción completa, dado que los argumentos que se pueden pasar a la orden hacen que el filtrado pueda ser mucho más potente.

Seguir los mensajes nuevos:

# journalctl -f

Mostrar todos los mensajes de un ejecutable específico:

# journalctl /usr/lib/systemd/systemd

Mostrar todos los mensajes de un proceso específico:

# journalctl _PID=1

Mostrar todos los mensajes por una unidad específica:

# journalctl -u netcfg

Mostrar búfer circular del kernel:

# journalctl _TRANSPORT=kernel

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

Límite del tamaño de journal

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

SystemMaxUse=50M

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

Journald coexistiendo con syslog

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

# systemctl enable syslog-ng

Podemos encontrar un buen tutorial de journalctl aquí.

Reenviar journald a /dev/tty12

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

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

Reinicie journald con sudo systemctl restart systemd-journald.

Solución de problemas

Investigar errores de systemd

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

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

$ systemctl --state=failed
systemd-modules-load.service   loaded failed failed  Load Kernel Modules

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

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

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

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

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

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

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

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

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

$ systemctl start systemd-modules-load.service

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

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

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

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

Diagnosticar problemas de arranque

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

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

Apagar/reiniciar se hace terriblemente largo

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

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

Si systemctl -u foounit.service no muestra ninguna salida para un servicio de breve duración, compruebe el PID. Por ejemplo, si systemd-modules-load.service falla, y systemctl status systemd-modules-load muestra que es seguido con PID 123, entonces es posible ver la salida de journal para dicho PID, por ejemplo journalctl -b _PID=123. Los campos con metadatos para journal, como _SYSTEMD_UNIT y _COMM, se recogen en modo asíncrono y se basan en la carpeta /proc para el proceso existente. La reparación de este proceso requiere la reparación del kernel para proporcionar estos datos por medio de una conexión socket, de forma similar a SCM_CREDENTIALS.

Desactivar el volcado de sucesos de journal respecto de las aplicaciones

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

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

Esto desactivará el registro de coredumps en journal.

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

$ ulimit -c unlimited

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

Mensaje de error al reiniciar o apagar

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

Véase este hilo para mayor explicación.

watchdog watchdog0: watchdog did not stop!

Véase este hilo para mayor explicación.

Véase también