systemd (Español)

From ArchWiki
Revision as of 15:01, 16 August 2012 by Pedro (Talk | contribs) (Traducción al Español)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Sumario help replacing me
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 daemons, permite el inicio de los daemons bajo demanda, realiza un seguimiento de los procesos con el uso de los cgroups 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.
Relacionado
Systemd/Services

Consulte artículo sobre el blog para una introducción más larga, the three status updates since then, y el resumen más reciente. Véase también el artículo de la Wikipedia y la página web del proyecto.

Contents

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 del parámetro init=/bin/systemd del kernel. Para probar systemd en Arch es necesario:

Una instalación systemd pura

  1. Instale systemd de [core].
  2. El paquete systemd-arch-units contiene unidades del systemd adicionales (servicios) que pueden serle de utilidad.
  3. Agregue init=/bin/systemd a los parámetros del kernel en su gestor de arranque.
  4. Cree los archivos de configuración de systemd.
  5. Habilite los servicios con systemctl enable .... Servicios para sustituir a los daemons de rc.conf.

Una instalación systemd mixta

  1. Instale systemd del repositorio [core]
  2. Agregue init=/bin/systemd a los parámetros del kernel en su gestor de arranque.
  3. Le recomendamos que use los archivos de configuración nativa de systemd en lugar de los archivos de configuración clásica de Arch. Puede seguir utilizando /etc/rc.conf para configurar unas pocas variables, si los archivos de configuración nativos no existen, pero el apoyo a aquél será dado de baja en el futuro.
  4. El paquete systemd-arch-units contiene unidades de systemd adicionales (servicios) que pueden serle de utilidad, en especial para la configuración de la red.

Después de arrancar con systemd

  1. (Opcional) Si desea una configuración pura de systemd ahora puede eliminar initscripts y sysvinit, y usar systemd commands así como systemctl poweroff en lugar de los comandos habituales. La razón para hacer este paso es que después de un reinicio el sistema que se inicia con initscripts todavía necesita /etc/inittab para que se cierre correctamente.
  2. (Opcional) Si desea enlaces simbólicos a init, reboot etc, instale systemd-sysvcompat. A continuación, puede eliminar el parámetro init= de su línea de comandos del kernel.

Información complementaria

Tip: Si usted tiene quiet en los parámetros de su kernel, debe eliminarlo durante el primer inicio para poder identificar cualquier problema durante el arranque.
Advertencia: /usr debe ser montado y disponible en el arranque (esto no es particular de systemd). Si su /usr está en una partición separada, tendrá que hacer ajustes para montarlo con el initramfs y desmontarla de la raíz en el cierre. Consulte la página wiki mkinitcpio y la freedesktop.org#partición-usr-separada-está-rota

Archivos de configuración nativos de systemd

Template:Moveto

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

Nota: Puede que tenga que crear estos archivos

Hostname

/etc/hostname
myhostname

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=us
FONT=lat9w-16
FONT_MAP=8859-1_to_uni

Para más información consulte: Fuentes de la consola

Locale (Configuración Regional)

Consulte man locale.conf para más opciones

/etc/locale.conf
LANG=es_ES.UTF-8
LC_COLLATE=C
Nota: /etc/profile.d/locale.sh de systemd-sysvcompat o initscripts es necesario que sea capaz de configurar los locales de los usuarios correctamente

Zona horaria

Consulte man 5 timezone para más opciones

/etc/timezone
Europe/Madrid
}
Nota: Este archivo no elimina la utilización de /etc/localtime.

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 harward 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 para ajustarlo a UTC estableciendo una clave DWORD a 1 en el registro del sistema:

HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
Advertencia: En los sistemas recientes (Windows 7, Windows Vista Service Pack 2), esta opción impide que Windows sea capaz de actualizar el reloj del sistema en absoluto, y las versiones anteriores no funcionan correctamente cuando se reanudan desde la hibernación o suspensión. Además, los últimos sistemas pueden dejar de responder durante el cambio de horario de verano (DST) si RealTimeIsUniversal se establece.

Si llega a tener problemas en el arranque dual con Windows, puede configurar el horari 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
Nota: Los demás parámetros siguen siendo necesarios, pero son ignorados por systemd.
Nota: 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, véase 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.

Sustituir acpid 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 : Apague 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

Dependiendo del valor de estas opciones, estos eventos pueden, por ejemplo, activarse cuando no hay nadie conectado (no-session) o cuando una única sesión de usuario está activa(any-session). Consulte man logind.conf para más detalles.

Estas opciones no se deben utilizar en entornos de escritorio como Gnome y XFCE, ya que estos eventos de ACPI lo gestionan por sí mismos. Sin embargo, en los sistemas que funcionan sin la configuración gráfica o sólo con un simple gestor de ventanas como i3 o awesome, puede sustituir al daemon acpid que se utiliza generalmente para gestionar estos eventos ACPI.

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

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

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

La salida 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 {ic|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.

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 objetivo 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 .destok, 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).

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.
  • 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 (no compatible con los archivos .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 de root.

Apagado y reinicio del sistema:

$ systemctl reboot

Apagado del sistema:

$ systemctl poweroff

Apagado completo del sistema:

$ systemctl halt

Suspensión del sistema:

$ systemctl suspend

Hibernación del sistema:

$ systemctl hibernate

Runlevels/targets

Runlevels (niveles de ejecución) es un concepto legacy 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 d 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 .
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 puede 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 Shell 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 default.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 cargador 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 DE (Entorno de Escritorio) con systemd

Utilizar el administrador 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 servicios de GDM, KDM, Slim, XDM y LXDM.

# systemctl enable kdm.service

Esto debería funcionar. Si no es así, usted podría tener establecido un default.target 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 hará uso de su default.target predefinido (es decir, graphical.target).

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

Si / etc / locale.conf se utiliza para establecer la configuración regional, añada una entrada a /etc/environment:

/etc/environment
LANG=es_ES.utf8

Usar servicio de archivo

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ímie 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 se encuentra en una partición raíz de 50GiB esto permitiría hasta 5GiB de datos de journal. El tamaño máximo de ljournal persistente puede ser controlada por SystemMaxUse en Template:IC, por lo que limitarlo, por ejemplo, quitar los comentarios 50MiB y editar la línea correspondiente a: Template:AC Mira journald.conf el hombre 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). En el caso syslog-ng cambiar el fragemnto source del {ic|/etc/syslog-ng/syslog-ng.conf}} de esta manera:

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

y activar (o reactivar) syslog-ng:

# systemctl enable syslog-ng.service

De forma predeterminada, journald está configurado para leer de /proc/kmsg, pero esto choca con una implementación de syslog que hace lo mismo (systemd-devel post). Desactivar la lectura de /proc/kmsg por systemd-journald en /etc/systemd/journald.conf:

ImportKernel=no

Red

Dinámico (DHCP)

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

Tenga en cuenta que ésto activará el servicio con la configuración predefinida por eth0. Si desea utilizar otra interfaz, tiene que crear el enlace simbólico de forma manual, por ejemplo:

# ln -s '/usr/lib/systemd/system/dhcpcd@.service' '/etc/systemd/system/multi-user.target.wants/dhcpcd@eth1.service'

Otras configuraciones

Para las redes estáticas, wireless o configuraciones avanzadas como bridging puede utilizar netcfg o NetworkManager, que ambos proporcionan file service de systemd.

Si necesita una configuración de ethernet estática, pero no quiere usar netcfg, hay un archivo de servicio personalizado disponible en el Systemd/Services page.

Nota: Si se utiliza NetworkManager NetworkManager-wait-online.service para obligar a las unidades dependientes de network.target que esperen a que una conexión de red se complete antes de comenzar.

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 la transición de los usuarios a systemd.

/etc/inittab no se utiliza en absoluto.

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 nativos de configuración systemd, que tendrán prioridad sobre /etc/rc.conf.

Variables compatibles:

  • LOCALE
  • KEYMAP
  • CONSOLEFONT
  • CONSOLEMAP
  • HOSTNAME

Variables incompatibles con la configuración de systemd:

  • TIMEZONE: haga un enlace simbolico /etc/localtime al proprio archivo con la información de su zona manualmente.
  • HARDWARECLOCK: Consulte Tiempo de Reloj por hardware.
  • USELVM: use en su lugar lvm.service proporcionado por el paquete systemd-arch-units.
  • USECOLOR
  • MODULES
  • DAEMONS

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 #I_files_di_configurazione_nativi_di_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
Fuentes de consola y distribución teclado /etc/vconsole.conf LOCALIZACIÓN - 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 .

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

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. Usted tiene que instalar python2-dbus e 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

Habilitación 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
  start() {
    sudo rc.d start $1
  }

  restart() {
    sudo rc.d restart $1
  }

  stop() {
    sudo rc.d stop $1
  }
else
  start() {
    sudo systemctl start $1.service
  }

  restart() {
    sudo systemctl restart $1.service
  }

  stop() {
    sudo systemctl stop $1.service
  }

  enable() {
    sudo systemctl enable $1.service
  }

  status() {
    sudo systemctl status $1.service
  }

  disable() {
    sudo systemctl disable $1.service
  }
fi

Disminuir el output

Cambie verbose en 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.

Sesiones de usuario

systemd puede dividir las sesiones de usuario en cgroups. Agregue session optional pam_systemd.so a su correspondiente /etc/pam.d/ (por ejemplo, login para el acceso a tty, sshd para el acceso remoto, kde para la contraseña de acceso de kdm, kde-np para para el acceso automático de kdm).

Antes:

$ systemd-cgls systemd:/system/getty@.service
systemd:/system/getty@.service:
├ tty5
│ └ 904 /sbin/agetty tty5 38400
├ tty2
│ ├ 13312 /bin/login --
│ └ 15765 -zsh
[…]

Dopo:

$ systemd-cgls systemd:/user/example/
systemd:/user/example/:
├ 4
│ ├   902 /bin/login --
│ └ 16016 -zsh
[…]

Además, se pueden reemplazar las funciones de ConsoleKit con systemd. Para ello necesita recompilar polkit a partir de ABS con systemd habilitado (--enable-systemd), y cosas como el automontaje de dispositivos USB funcionarán sin consolekit. DBus soporta systemd desde la versión 1.6.0 , por lo que no será necesario recompilar de Git por mucho tiempo.

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 el servicio CUPS no se inicia bajo demanda

Encontrándose en mi máquina, incluso después de ejecutar "systemctl enable cups.service", cups no vuelve a trabajar hasta que se emite manualmente "systemctl start cups.service". Para solucionar este problema puede crear manualmente un enlace simbólico al servicio cups para iniciarlo automáticamente en el arranque:
# sudo ln -s '/usr/lib/systemd/system/cups.service' '/etc/systemd/system/multi-user.target.wants/cups.service'

Véase también