systemd (Español)

From ArchWiki
Revision as of 15:25, 7 October 2012 by Pedro (Talk | contribs) (Actualización: 2012-10-07)

Jump to: navigation, search

Sumario help replacing me
Describe cómo instalar y configurar systemd.
Relacionado
Systemd/Services
Init to systemd cheatsheet
udev - systemd y udev han sido fusionados por upstream.

De la página web del proyecto:

"systemd es un gestor del sistema y de los servicios para Linux, compatible con los initscript SysV y LSB. Systemd proporciona una notable capacidad de paralelización, utiliza socket y D-Bus para la inicialización de daemons, permite el inicio de los daemons bajo demanda, realiza un seguimiento de los procesos con el uso de los grupos de control de Linux, apoya snapshotting y la restauración del estado del sistema, mantiene los puntos montaje y servicios de montaje automático e implementa un elaborado servicio de control lógico basado en relaciones de dependencias. Puede funcionar como un reemplazo total de sysvinit."

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

Consulte también el artículo de Wikipedia.

Contents

Consideraciones previas antes de pasarse a systemd

  • Es muy recomendable cambiarse al nuevo sistema de configuración de los initscripts descrita en el artículo relativo a rc.conf. Una vez que haya establecido esta configuración, habrá hecho la mayor parte del trabajo necesario para hacer el cambio a systemd.
  • Documentación sobre systemd.
  • Tenga en cuenta el hecho de que systemd tiene un sistema journal que sustituye a syslog, aunque todavía los dos pueden coexistir. Consulte la sección relativa a journal a continuación.
  • 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

Systemd puede trabajar codo con codo con el regulador initscripts de Arch Linux, y se puede habilitar/deshabilitar mediante la adición/extracción de init=/bin/systemd de los parámetros del kernel.

Una instalación mixta systemd/sysvinit/initscripts

Es posible mantener systemd y Sysvinit instalados y usando los mismos archivos de configuración para volver hacia atrás entre ellos libremente:

  1. 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, y reinicie el sistema para comprobar que funcionan como era de esperar con initscripts.
  2. Instale systemd de los repositorios oficiales.
  3. Añada init=/bin/systemd a los parámetros del kernel de su bootloader.
  4. Reinicie.

Systemd iniciará los demonios listados en /etc/rc.conf y ejecutará /etc/rc.local y /etc/rc.local.shutdown al arranque/apagado respectivamente. Si el antiguo soporte para los DAEMONS en rc.conf o los scripts en rc.local no es necesario, el correspondiente servicio los deshabilitará.

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.

  1. Siga las instrucciones para una instalación mixta systemd/sysvinit/initscripts.
  2. Activar los demonios formalmente enumerados en /etc/rc.conf con systemctl enable nombredeldemonio.service . Para conocer la correspondencia entre los demonios de /etc/rc.conf con los servicios de systemd, consulte: lista de demonios y 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.
  3. Instale systemd-sysvcompat. Ésto entrará en conflicto con sysvinit, y el prompt le pedirá que lo retire.
  4. Elimine las entradas init=... en /sbin/init siendo ahora un enlace simbólico a systemd.
  5. 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.

  1. Siga las instrucciones para una instalación mista systemd/initscripts.
  2. Asegurese que no hay ningún demonio activado en la matriz DAEMONS en rc.conf y que /etc/rc.local y /etc/rc.local.shutdown están vacios.
  3. Elimine el paquete initscripts de su sistema.

Información complementaria

Tip: Si usted tiene 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

systemd usará /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

/etc/hostname
mimaquina

Consola y keymap

El archivo /etc/vconsole.conf configura la consola virtual, es decir, asigna la distribución del teclado y fuentes de la consola.

/etc/vconsole.conf
KEYMAP=es
FONT=
FONT_MAP=

Para más información consulte: Fuentes de la consola y 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:
/etc/vconsole.conf
KEYMAP=
FONT=

Locale (Configuración Regional)

Consulte man locale.conf para más opciones

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

Para más información,consulte Locale (Español).

Timezone (zona horaria)

Consulte man 5 timezone para más opciones

# ln -sf /usr/share/zoneinfo/Europe/Madrid /etc/localtime
Nota: /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 (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 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 (que utiliza localtime). Windows es capaz de gestionar el horario del hardware regulando la UTC con un 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:

/etc/adjtime
 
0.0 0.0 0.0
0
LOCAL

Los demás parámetros siguen siendo necesarios, pero son ignorados por systemd.

En general, se aconseja tener un servicio 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 /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 /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 # o ; se ignoran. Ejemplo:

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

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 initscripts, ya que en realidad está a cargo de kmod. Consulte Module Blacklisting para más detalles.

Los archivos temporales

Systemd-tmpfiles mantiene la configuración de los archivos en /usr/lib/tmpfiles.d/ y /etc/tmpfiles.d/ para describir la creación, limpieza y eliminación de archivos y directorios temporales y volátiles y que normalmente residen en directorios como /run o /tmp. Cada archivo de configuración toma el nombre con el formato /etc/tmpfiles.d/<program>.conf. Esto sobreescribirá cualquier archivo en /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 /var/run/samba exista para obtener los permisos adecuados. El tmpfile correspondiente es algo del siguiente género:

/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 /etc/rc.local para desactivar el inicio del sistema a través de dispositivos USB con echo USBE > /proc/acpi/wakeup, se puede utilizar alternativamente el siguiente tmpfile:

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

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

Consulte 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 /etc/fstab deberían funcionar igualmente.

No obstante, usted puede que quiera usar 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 x-systemd.device-timeout=# en /etc/fstab para especificar un tiempo de espera en caso de que el recurso de la red no esté disponible.

Consulte 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 /etc/systemd/logind.conf:

  • HandlePowerKey: Apagar el sistema cuando el botón de encendido se pulsa
  • HandleSleepKey: Suspender el sistema cuando se pulsa la tecla sleep
  • HandleLidSwitch: Suspender el sistema cuando la tapa del portátil es cerrada

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

Si estas opciones no están configuradas, systemd utilizará sus valores predeterminados: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, y 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 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 Handle a 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 systemctl suspend o systemctl hibernate. Por lo tanto, todos los hooks pm-utils, incluyendo cualesquiera 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 /usr/lib/systemd/system-sleep/ y pasará dos argumentos para cada uno de ellos:

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

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

La salida del script se registrará por systemd-suspend.service o systemd-hibernate.service para que pueda ver su propia salida en el journal.

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

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

Ejemplo

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

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 man systemd.unit para más información.

Comandos systemd

  • systemctl: se utiliza para controlar el estado del servicio y del sistema systemd.
  • systemd-cgls: muestra recursivamente el contenido de la jerarquía del grupo de control Linux seleccionado con un diagrama de árbol.
  • systemadm: una interfaz gráfica para systemd que permite un amplio control del sistema (disponible a través del paquete systemd-ui-gitAUR de AUR).

Consulte man pages para más detalles.

Tip: Puede utilizar todas los comandos siguientes systemctl con el valor -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:

$ systemctl

o bien:

$ systemctl list-units

Lista de unidades que han tenido problemas:

$ systemctl --failed

Los archivos disponibles de la unidad se pueden ver en /usr/lib/systemd/system/ y /etc/systemd/system/ (este último tiene prioridad). Puede ver la lista de los archivos de unidad instalados con:

$ systemctl list-unit-files

Usando las unidades

Las unidades pueden ser, por ejemplo, servicios (.service), puntos de montaje (.mount), dispositivos (.device) o sockets (.socket). Cuando usa systemctl, por lo general, tiene que especificar el nombre completo del archivo de la unidad incluyendo el sufijo, por ejemplo, sshd.socket. Sin embargo, hay unos pocos atajos que especifican la unidad en los siguientes comandos systemctl:

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

Consulte man systemd.unit para más detalles.

Activa una unidad de inmediato:

# systemctl start <unit>

Desactiva una unidad de inmediato:

# systemctl stop <unit>

Reinicia la unidad:

# systemctl restart <unit>

Hace que una unidad recargue su configuración:

# systemctl reload <unit>

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

$ systemctl status <unit>

Comprueba si la unidad ya está habilitada o no:

$ systemctl is-enabled <unit>

Habilita el inicio automático en el arranque:

# systemctl enable <unit>
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.
# ln -s /usr/lib/systemd/system/foo.service /etc/systemd/system/graphical.target.wants/

Desactiva el inicio automático durante el arranque:

# systemctl disable <unit>

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

$ systemctl help <unit>

Administración de energía

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). Apagado y reinicio del sistema:

$ systemctl reboot

Apagado del sistema:

$ systemctl poweroff

Apagado completo del sistema:

$ systemctl halt

Suspensión del sistema:

$ systemctl suspend

Hibernación del sistema:

$ systemctl hibernate

Runlevels/targets

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

Conocer el runlevel/targets presentes

Lo siguiente debe ser utilizado bajo systemd en lugar de runlevel:

# systemctl list-units --type=target

Crear target personalizado

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 /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 /usr/lib/systemd/system/ que desea habilitar.

Tabla de Targets

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

En systemd los niveles de ejecución están expuestos a través de "target units". Se puede cambiar de esta manera:

# 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 telinit 3 o telinit 5 en Sysvinit.

Cambiar el runlevel/target predeterminado para arrancar

El target estándar es default.target, que es un alias por defecto 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 en el gestor de arranque:

  • systemd.unit=multi-user.target (que corresponde con el antiguio nivel de ejecución 3),
  • 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 default.target. Esto puede hacerse usando systemctl:

# systemctl enable multi-user.target

El efecto de este comando se puede ver en la salida de systemctl; crea un enlace simbólico al nuevo target prefedinido /etc/systemd/system/default.target. Esto funciona sólo 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.

Ejecución de DEs (Entornos de Escritorios) con systemd

Usar el gestor de pantalla

Para habilitar el inicio de sesión, ejecute el daemon de su gestor de pantalla correspondiente (por ejemplo, KDM). Por el momento, existen los .service para GDM, KDM, Slim, XDM y LXDM.

# systemctl enable kdm.service

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

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

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

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

Usar los service file

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:. Automatic_login_to_virtual_console#With_systemd

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:

/etc/systemd/system/graphical.target.wants/xinit.service
[Unit]
Description=Direct login to X
After=systemd-user-sessions.service

[Service]
ExecStart=/bin/su <username> -l -c "/bin/bash --login -c xinit"

[Install]
WantedBy=graphical.target

El Journal de Systemd

Desde la versión 38 systemd tiene un sistema de registro (log) propio llamado journal.

Por defecto, hacer funcionar el demonio syslog ya no es necesario. Para leer el registro (log), utilice:

# journalctl

El sistema journal escribe en /run/systemd/journal, lo que significa que los logs se pierden al reiniciar el sistema. Para evitar registros tan volátiles, se puede crear /var/log/journal/:

# mkdir /var/log/journal/

Filtrado de salida

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

Ejemplos:

Mostrar todos los mensajes de un ejecutable específico:

# journalctl /usr/lib/systemd/systemd

Mostrar todos los mensajes de un proceso específico:

# journalctl /usr/lib/systemd/systemd

Mostrar todos los mensajes de una unidad específica:

# journalctl _SYSTEMD_UNIT=netcfg.service

Consulte man journalctl y systemd.journal-fields para obtener más detalles.

Límite del tamaño de journal

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 /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 SystemMaxUse en /etc/systemd/journald.conf, por lo que para limitarlo, por ejemplo, a 50MiB, descomente y edite la correspondiente línea a:

SystemMaxUse=50M

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

Journald coexistiendo con el demonio syslog clásico

La compatibilidad con las implementaciones de syslog clásicos 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 unirse a este socket en vez del /dev/log (anuncio oficial). Para syslog-ng, cambie la sección source src de /etc/syslog-ng/syslog-ng.conf de esta manera:

source src {
    unix-dgram("/run/systemd/journal/syslog");
    internal();
    file("/proc/kmsg");
};

y activar syslog-ng:

# 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 dhcpcd@.service contenido en el paquete systemd-arch-units. Para habilitar DHCP para 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 (FS#30235), agregue manualmente el módulo de la propia tarjeta a /etc/modules-load.d/****.conf. Ejemplo: cree el archivo /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 or 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 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 initscripts. Esto pretende ser simplemente una medida transitoria para facilitar el cambio de los usuarios a systemd.

Nota: /etc/inittab no se utiliza en absoluto.

Si usted se encuentra deshabilitado Template:Keypress para reiniciar en /etc/inittab, debe volver a reconfigurar las opciones para systemd ejecutando systemctl mask ctrl-alt-del.target como root.

rc.conf

Algunas de las variables en /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, que tendrán prioridad sobre /etc/rc.conf.

Variables compatibles:

  • LOCALE
  • KEYMAP
  • CONSOLEFONT
  • CONSOLEMAP
  • HOSTNAME
  • DAEMONS

Variables incompatibles con la configuración de systemd:

  • TIMEZONE: haga un enlace simbolico /etc/localtime al propio archivo con la información de su zona manualmente.
  • HARDWARECLOCK: Consulte reloj del hardware.
  • USELVM: use en su lugar lvm.service proporcionado por lvm2.
  • USECOLOR
  • MODULES

Conversión total a systemd puro

Nota: Este es el método preferido, donde el sistema no se basa más en la configuración centralizada de 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 nativa de systemd. Cada archivo sustituye a una sección de /etc/rc.conf como se muestra en esta tabla:

Configuración Archivos de configuración Antigua sección /etc/rc.conf
Hostname /etc/hostname

/etc/hosts

NETWORKING
Console fonts and Keymap /etc/vconsole.conf LOCALIZATION
Locale /etc/locale.conf

/etc/locale.gen

LOCALIZATION
Timezone /etc/timezone

/etc/localtime

LOCALIZATION
Hardware clock /etc/adjtime LOCALIZATION
Kernel modules /etc/modules-load.d/ HARDWARE

Para fines de transición, la sección DAEMONS /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 /etc/rc.conf por completo y habilitar los servicios en systemd. Para cada <nombre_del_servicio> de la matriz DAEMONS de /etc/rc.conf, escriba:

# 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 esta tabla.

Si <nombre_del_servicio>.service no existe:

  • El archivo .service puede no estar disponible para systemd. En ese caso, usted tendrá que mantener rc.conf para iniciar el servicio durante el arranque.
  • systemd puede nombrar el servicio de manera diferente, por ejemplo,cronie.service reemplaza el lanzamiento del demonio crond y alsa-restore.service reemplaza el lanzamiento del demonio alsa. Otro ejemplo importante es el demonio network, que es reemplazado por otro conjunto de archivos de servicio (consulte 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, dbus.service se activará automáticamente cuando dbus-core está instalado. Revise la lista de servicios disponibles y su estado utilizando el comando systemctl .

Escribir los archivos .service personalizados

Gestionar 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 antes que A se haya iniciado. 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, agrega Wants=B y After=B. Tenga en cuenta que Wants= y Requires= no incluyen After=, lo que significa que si 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, 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 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 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.
  • 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 PIDFile= para que systemd puede realizar un seguimiento del proceso principal.
  • Type=oneshot: Esto es útil para los scripts que hacer un solo trabajo y luego concluir. Es posible que desee también establecer RemainAfterExit= de modo que systemd sigue considerando el servicio como activo después de que el proceso ha 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. Ésto requiere del código específico proporcionado por libsystemd-daemon.so.
  • Type=dbus: El demonio se considera listo cuando el especificado BusName que aparece en el sistema del bus es DBus.

Reemplazar los archivos unit suministrados

Los archivos unit en /etc/systemd/system/ tienen prioridad sobre los de /usr/lib/systemd/system/. 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 /usr/lib / a /etc/ y hacer los cambios allí. Alternativamente, puede utilizar .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:

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

.include /usr/lib/systemd/system/<service-name>.service

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

A continuación, ejecute lo siguiente para que los cambios surtan efecto:

 # systemctl reenable <unit>
 # systemctl restart <unit>
Tip: Puede utilizar 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 resaltado de sintaxis para los archivos unit de systemd con Vim se puede activar mediante la instalación de vim-systemdAUR de AUR.

FAQ

Para obtener una lista actualizada de los problemas conocidos, consulte primero TODO.

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Template:FAQ

Optimización

systemd-analyze

Systemd proporciona una herramienta llamada 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 python2-dbus y python2-cairo para usarlo.

Para ver cuánto tiempo ha empleado el arranque del kernel y del userspace, sólo tiene que utilizar:

$ systemd-analyze
Tip: Si se agrega el parámetro timestamp a la matriz HOOKS en /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:

$ systemd-analyze blame

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

$ systemd-analyze plot > plot.svg

Habilitar bootchart junto con systemd

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 bootchart2AUR de AUR viene con un indocumentado servicio de systemd. Después de haber instalado bootchart2 hacer:

# systemctl enable bootchart.service

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

Atajos Shell

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 ~/.bashrc para ayudar a simplificar la interacción con systemd y mejorar la experiencia general.


if ! systemd-notify --booted; then # not using systemd
  alias start='sudo rc.d start'
  alias restart='sudo rc.d restart'
  alias stop='sudo rc.d stop'
else
  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

Disminuir el output

Cambie verbose a 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

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:

# systemctl enable console-kit-daemon.service

Esto provocará el arranquede de console-kit tan pronto como sea posible, sin causar carreras con la activación del socket o dbus.

Automount

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 /home, tal vez sería mejor permitir que los servicios que no dependen de /home inicien, mientras /home está controlada. Esto se puede lograr mediante la adición de las siguientes opciones para la entrada fstab de su / home partición:

noauto, x-systemd.automount

Esto controlará y montará /home cuando se acceda por primera vez, y el kenel almacenará todos los accesos a los archivos de /home hasta que esté listo.

Si tiene sistemas de archivos cifrados con keyfiles, también puede añadir el parámetro noauto para las entradas correspondientes de /etc/crypttab. Systemd no abrirá el dispositivo cifrado en el arranque, sino que esperará hasta que realmente se 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:

/etc/crypttab
data /dev/md0 /root/key noauto

Readahead

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:

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

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

Reemplazar ConsoleKit con systemd-logind

A partir de polkit 0.107 (actualmente en repositorio [testing]), ConsoleKit puede ser completamente reemplazado por systemd-logind. Sin embargo, actualmente no existe un gestor de pantallas en los repositorios de Arch Linux que soporte de forma nativa systemd-logind sin la función aún de ConsoleKit. El método más fácil para ser capaz de eliminar ConsoleKit es conexión automática a una consola virtual e 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 ck-launch-session de su ~/.xinitrc.

Con el fin de comprobar el estado de la sesión de usuario, puede utilizar loginctl. Para ver si su sesión de usuario está configurada correctamente, compruebe si el comando siguiente contiene Active=yes. Todas las acciones de polkit como suspender el sistema o montar unidades externas con Udisks deberían entonces funcionar automáticamente.

$ loginctl show-session <session-id>
Note: Si utiliza NetworkManager, hay que volver a compilar con el soporte systemd de ABS mediante el ajuste --with-session-tracking=systemd en PKGBUILD.

Solución de problemas

Apagar/reiniciar se hace terriblemente largo

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

SLiM y sesión xfce

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:

/etc/systemd/system/slim.service
[Unit]
Description=SLiM Simple Login Manager
After=systemd-user-sessions.service

[Service]
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]
WantedBy=graphical.target

Esto hace que SLiM se termine usando SIGKILL. Puesto que el archivo de bloqueo también se elimina ésto no causa un problema.

Si algunos servicios no se inician

Si el archivo /var/tmp es un enlace simbólico a /tmp, provocará que algunos servicios fallen el arranque cuando se inicia systemd. En estos casos, el estado de los procesos (mediante systemctl status <service>) será "226/NAMESPACE". Para superar este bloqueo, basta con quitar el propio enlace simbólico del archivo /var/tmp y reinstalar el paquete filesystem.

Véase también