Systemd

From Gentoo Wiki
Jump to: navigation, search
This page is a translated version of the page Systemd and the translation is 94% complete.

Other languages:
English • ‎español • ‎italiano • ‎日本語 • ‎한국어 • ‎português do Brasil • ‎русский • ‎中文(中国大陆)‎

Warning: Display title "systemd/es" overrides earlier display title "Systemd".

Resources

systemd es un moderno reemplazo (cuando está ejecutándose)[1] de sysvinit y RC para los sistemas Línux. Tiene soporte en Gentoo como una alternativa del sistema de inicio (init).

Instalación

Nota
Al actualizar desde <=sys-apps/systemd-203 compruebe la subpágina de actualización.

El núcleo de línux

systemd hace uso de muchas características modernas del núcleo de Línux. Ahora mismo, el límite inferior de la versión del núcleo (para usar systemd) se encuentra en el ebuild 2.6.39. En versiones recientes de sys-kernel/gentoo-sources, hay una manera eficaz de seleccionar las opciones del núcleo, tanto obligatorias como opcionales, para systemd (leer la configuración del núcleo para obtener más detalles):

KERNEL Configuración rápida usando gentoo-sources
Gentoo Linux --->
        Support for init systems, system and service managers --->
                [*] systemd

Para configurar las opciones del núcleo manualmente (que es la única opción cuando no utilice sys-kernel/gentoo-sources), se requieren o recomiendan las siguientes opciones de configuración del núcleo:

KERNEL Mandatory options
General setup  --->
	[*] open by fhandle syscalls
	[*] Control Group support --->
	[ ] Enable deprecated sysfs features to support old userspace tools
	[*] Configure standard kernel features (expert users)  --->
		[*] Enable eventpoll support
		[*] Enable signalfd() system call
		[*] Enable timerfd() system call
[*] Networking support --->
Device Drivers  --->
	Generic Driver Options  --->
		[*] Maintain a devtmpfs filesystem to mount at /dev
File systems  --->
	[*] Inotify support for userspace
	Pseudo filesystems  --->
		[*] /proc file system support
		[*] sysfs file system support
KERNEL Recommended options
General setup  --->
        [*] Checkpoint/restore support
	[*] Namespaces support  --->
		[*] Network namespace
[*] Enable the block layer  --->
	[*] Block layer SG support v4
Processor type and features  --->
	[*] Enable seccomp to safely compute untrusted bytecode
Networking support --->
	Networking options --->
		<*> The IPv6 protocol
Device Drivers  --->
	Generic Driver Options  --->
		()  path to uevent helper
		[ ] Fallback user-helper invocation for firmware loading
Firmware Drivers  --->
	[*] Export DMI identification via sysfs to userspace
File systems --->
	<*> Kernel automounter version 4 support (also supports v3)
	Pseudo filesystems --->
		[*] Tmpfs virtual memory file system support (former shm fs)
		[*]   Tmpfs POSIX Access Control Lists
		[*]   Tmpfs extended attributes

Para un sistema UEFI active también las siguientes opciones:

KERNEL Soporte para UEFI
[*] Enable the block layer  --->
	Partition Types  --->
		[*] Advanced partition selection
		[*]   EFI GUID Partition support
Processor type and features  --->
	[*] EFI runtime service support
Firmware Drivers  --->
        EFI (Extensible Firmware Interface) Support -->
	        <*> EFI Variable Support via sysfs

Si el sistema está utilizando el planificador BFQ, se recomienda, por los desarrolladores de BFQ, activar «BFQ hierarchical scheduling support» bajo «Enable the block layer -> IO Schedulers».

For an up-to-date list, see section "REQUIREMENTS" in the upstream README file.

/etc/mtab

Los desarrolladores solo dan soporte al archivo /etc/mtab siendo este un enlace simbólico de /proc/self/mounts. Si no se crea este enlace simbólico también causará problemas con mount (bug #434090) y (df). En el pasado algunas utilidades escribieron información (como opciones de montaje) en /etc/mtab y, por lo tanto, se dio por hecho que era un archivo normal. Hoy en día todo el software tiene en cuenta esto que para evitar dicho problema. Sin embargo, antes de cambiar el archivo para convertirse en un vínculo simbólico, revise bug #477498 para asegurarse de que el sistema no está afectado por ninguna regresión reportada.

Para crear el enlace simbólico, ejecute:

root #ln -sf /proc/self/mounts /etc/mtab

Asegurarse de que /usr está presente en el arranque

Para una configuración separada de /usr, utilice un initramfs para que monte /usr antes de iniciar systemd. Por ahora, esto implica que se puede utilizar sys-kernel/dracut o sys-kernel/genkernel-next hasta que el apoyo a /usr esté disponible en sys-kernel/genkernel. Dele un tiempo para realizar la migración:

root #emerge --ask --unmerge sys-kernel/genkernel
root #emerge --ask sys-kernel/dracut
root #emerge --ask sys-kernel/genkernel-next

Cuando utilice dracut, active el módulo usrmount, si no se ha activado por sí mismo al montar automáticamente /usr.

ARCHIVO /etc/dracut/dracut.conf
# Módulos Dracut para añadir a los valores por defecto
add_dracutmodules+="usrmount"

Cuando se utilice genkernel-next, antes de recompilar el núcleo, asegúrese de ajustar la variable UDEV en el archivo de configuración de genkernel a yes. Esto colocará /usr dentro de initramfs:

ARCHIVO /etc/genkernel.conf
# Utilice udev en lugar de mdev como el administrador de dispositivos por defecto para initramfs.
# Si utiliza systemd y, quizás también con LVM, entonces esta opción debe estar abierta.
UDEV="yes"
root #genkernel --install all

Consulte la Guía de initramfs para conocer otras alternativas.

Using LVM and initramfs

Cuando se utiliza sys-fs/lvm2 y el sistema se arranca usando un initramfs, dicho initramfs tendrá que ser creado con sys-kernel/genkernel-next, ejecutando:

root #genkernel --udev --lvm <target>

<target> es, o bien initramfs, o bien algún otro objetivo de genkernel que implique la creación de un initramfs. Para obtener más información, mire la salida de >genkernel --help:

user $genkernel --help

Cuando se utiliza LVM, el demonio lvmetad debe iniciarse también. De lo contrario systemd será incapaz de montar volúmenes LVM. lvmetad se puede activar en /etc/lvm/lvm.conf:

ARCHIVO /etc/lvm/lvm.confFragmento del cambio necesario en lvm.conf
# Ajustar use_lvmetad a '1' para systemd
use_lvmetad = 1
Nota
En lugar de modificar /etc/lvm/lvm.conf, esto, probablemente, podría lograrse a través de una unidad lvmetad.socket que active un servicio lvmetad.service, pero las versiones actuales de sys-fs/lvm2 no contienen dichas opciones aún.

sys-apps/systemd contiene udev. Una vez instalado, sys-fs/udev puede retirarse, dado que systemd será asistido por virtual/udev.

Active el parámetro global de USE systemd (en make.conf). Al mismo tiempo, el parámetro USE consolekit debe ser desactivado para evitar conflictos con el servicio systemd-logind. También es posible cambiar a un subperfil systemd para utilizar parámetros USE por defecto más coherentes, en cuyo caso no es necesario cambiar make.conf:

root #eselect profile list

Finalmente, actualice el sistema con los nuevos parámetros:

root #emerge -avDN @world

Cuando se producen problemas de dependencias (como sys-fs/udev bloqueando sys-apps/systemd), sys-fs/udev podría ser que estuviera registrado en el archivo word. Trate de resolver esto desmarcándolo:

root #emerge --deselect sys-fs/udev

Arrancar con systemd

Para poder arrancar systemd, hay que cambiar el init que el núcleo (o initramfs) utiliza como ejecutable.

Advertencia
Los servicios que se establecen para el gestor de servicios previo no se inician automáticamente (en el otro). Esto se debe a que el sistema ha cambiado a un gestor de servicios diferente. Con el fin de obtener de nuevo la funcionalidad de dichos servicios, como la conexión de redes o el gestor de inicio de sesión, estos servicios tendrán que ser activados nuevamente. Más información sobre esto se proporciona más adelante en la sección «Servicios» de este artículo.
Nota
Si la migración produce un estado inoperativo, siempre es posible arrancar de nuevo con el gestor de servicios por defecto (OpenRC) desandando los pasos para cambiar el init. Esto permite un retorno seguro y una manera de conseguir solucionar el problema a través de la sección «Solución de problemas» del final de este artículo.

Las siguientes subsecciones documentan cómo intercambiar el init en uno de los gestores de arranque o en el núcleo.

GRUB Legacy (0.x)

El argumento init=/usr/lib/systemd/systemd debe ser añadido a la línea de órdenes del núcleo. Un extracto de ejemplo de grub.conf se vería así:

ARCHIVO /boot/grub/grub.confEjemplo de configuración de GRUB para systemd
title=Gentoo con systemd
root (hd0,0)
kernel /vmlinuz root=/dev/sda2 init=/usr/lib/systemd/systemd

Si a pesar de esto el sistema arranca usando OpenRC, pruebe utilizando real_init en lugar de init.

GRUB 2

When grub-mkconfig is used, add the init option to GRUB_CMDLINE_LINUX:

Nota
Esto no es necesario cuando se utiliza un initramfs generado por dracut con systemd en su interior, dado que initramfs ya inicia systemd.
ARCHIVO /etc/default/grub=Configurar GRUB2 para systemd
# Añadir parámetros a la línea de órdenes del núcleo de línux
GRUB_CMDLINE_LINUX="init=/usr/lib/systemd/systemd"

Cuando el archivo de configuración de GRUB2 esté hecho a mano (solo expertos), añada el parámetro init= a la orden linux o linux16.

ARCHIVO /boot/grub/grub.cfgEjemplo de fragmento de configuración de GRUB2
linux /vmlinuz-3.10.9 root=UUID=508868e4-54c6-4e6b-84b0-b3b28b1656b6 init=/usr/lib/systemd/systemd

Cuando utilice initrd obtenido con genkernel-next, use real_init en lugar de init.

Nota
Este uso del parámetro real_init obsoleto no debería ser necesario para las versiones estables de genkernel-next.

En la configuración del núcleo

La configuración de init también puede ser introducida en la configuración del núcleo. Consulte Processor type and features -> Built-in kernel command line. Tenga en cuenta que esta técnica funciona tanto para GRUB como para GRUB2.

Configuración tras la instalación

systemd soporta algunos archivos de configuración del sistema para ajustar los detalles más básicos del sistema.

Nota
Si bien algunos parámetros de configuración del sistema se pueden actualizar mediante la modificación de los archivos de configuración apropiados, la mayoría de los ajustes se gestionan mediante utilidades que exigen que systemd esté corriendo. En este último caso, es seguro reiniciar el ordenador con systemd y utilizar las utilidades hostnamectl, localectl y timedatectl para hacer los ajustes que se necesiten.

Identificador de la máquina (Machine ID)

Crear un identificador de la máquina para que el journaling funcione. Esto se puede conseguir mediante la siguiente orden:

root #systemd-machine-id-setup

Nombre del equipo

Para establecer el nombre del equipo, cree/edite el archivo /etc/hostname y simplemente ponga el nombre deseado para el equipo.

Cuando arranca con systemd, dispone de una herramienta llamada hostnamectl que permite editar /etc/hostname y /etc/machine-info. Para cambiar el nombre del equipo, ejecute:

root #hostnamectl set-hostname <NOMBREDELEQUIPO>

Remítase a man hostnamectl para obtener más información.


Idioma del sistema

Por lo general, los locales migrarán correctamente desde OpenRC al instalar systemd. Cuando sea necesario, el idioma se puede ajustar en /etc/locale.conf, según las instrucciones dadas por el manual de Gentoo:

ARCHIVO /etc/locale.confConfiguración del idioma del sistema
LANG="es_ES.utf8"

Una vez arrancado el sistema con systemd, la herramienta localectl se puede utilizar para establecer la configuración regional y el mapa de teclas de la consola o de X11. Para cambiar la configuración regional del sistema, ejecute la siguiente orden:

root #localectl set-locale LANG=<LOCALE>

Para cambiar el mapa de teclado de la consola virtual:

root #localectl set-keymap <KEYMAP>

Y, por último, para configurar la distribución del teclado en X11:

root #localectl set-x11-keymap <LAYOUT>

Si es necesario el modelo, variante y opciones pueden especificarse así:

root #localectl set-x11-keymap <LAYOUT> <MODEL> <VARIANT> <OPTIONS>

Fecha y hora

La fecha y hora del sistema se pueden ajustar mediante la utilidad timedatectl. Esto también permitirá a los usuarios configurar la sincronización horaria del sistema sin necesidad de depender de net-misc/ntp o de otros proveedores que implementa el propio systemd.

Para aprender a utilizar timedatectl solo tiene que ejecutar:

root #timedatectl --help

Cargar módulos automáticamente

La carga automática de un módulo está configurada en un archivo diferente, o mejor dicho, en un directorio de archivos. Los archivos de configuración se almacenan en el directorio /etc/modules-load.d. Al arranque, se carga cada archivo que contiene una lista de módulos. El formato del archivo es una lista de módulos separados por saltos de línea, y dicho archivo puede tener cualquier nombre, siempre y cuando termine en .conf. La carga del módulo se puede separar por programa, servicio o cualquier forma que se adapte a sus preferencias personales. Un ejemplo para los módulos de virtualbox.conf se enumeran a continuación:

ARCHIVO /etc/modules-load.d/virtualbox.confArchivo de ejemplo para los módulos de virtualbox
vboxdrv
vboxnetflt
vboxnetadp
vboxpci

Conexión de red

systemd-networkd

systemd-networkd es útil para realizar una configuración sencilla de las interfaces de red cableada. Está desactivado por defecto.

To configure systemd-networkd, create a

  • .network file under /etc/systemd/network. See systemd.network(5) for reference. A simple DHCP configuration is given below:
ARCHIVO /etc/systemd/network/50-dhcp.network
[Match]
Name=en*
 
[Network]
DHCP=yes
root #systemctl enable systemd-networkd.service
root #systemctl start systemd-networkd.service

Advierta que systemd-networkd no actualiza resolv.conf de forma predeterminada. Para tener systemd administrando la configuración de DNS, sustituya resolv.conf con un enlace simbólico y ponga en marcha systemd-resolved.

root #ln -snf /run/systemd/resolve/resolv.conf /etc/resolv.conf
root #systemctl enable systemd-resolved.service
root #systemctl start systemd-resolved.service

NetworkManager

A menudo NetworkManager se utiliza para configurar los ajustes de red. Para ello, solo tiene que ejecutar la siguiente orden cuando se utiliza un escritorio corriendo con X11:

root #nm-connection-editor

Si ese no es el caso y la red necesita ser configurada desde consola, dele a nmcli una oportunidad, o siga un proceso de configuración asistida por nmtui:

root #nmtui

nmtui es una interfaz curses que guiará al usuario en el proceso de configuración mientras se ejecuta en modo consola.

Manejar los archivos de registo

systemd tiene su propia manera de manejar los archivos de registro sin necesidad de depender de ningún sistema de registro externo (como app-admin/syslog-ng or app-admin/rsyslog). Los mensajes ahora se pueden leer con journalctl. Aún así, systemd puede ser configurado para utilizar una herramienta externa de su preferencia para el manejo de los registros. Vea man journald.conf para aprender acerca de cómo configurar journald para que se ajuste a sus necesidades personales.

Algunas opciones comunes de journalctl:

Opciones de línea de órdenes para journalctl Resultado
journalctl sin opciones Muestra todas las entradas del registro comenzando por la más antigua.
-b, --boot Muestra todas las entradas del registro en este inicio del sistema.
-r, --reverse En primer lugar la entrada más actual.
-f, --follow Muestra las últimas entradas y las nuevas conforme se van produciendo.
-p, --priority= Especifica la (mínema) prioridad para mostrar los mensajes, se puede elegir entre: "emerg" (0), "alert" (1), "crit" (2), "err" (3), "warning" (4), "notice" (5), "info" (6), "debug" (7).
--since=, --until= Restringir entradas por su hora. Acepta el formato "YYYY-MM-DD hh:mm:ss" o las cadenas de caracteres "yesterday", "today" y "tomorrow" (ayer, hoy y mañana).
-n, --lines= Restringe a un número de entradas.
-k, --dmesg Restringe a los mensajes del núcleo.
-u, --unit= Restringe a una determinada unidad de Systemd.

Para obtener más información y muchas más opciones, eche un vistazo a man journalctl.

/tmp está ahora en tmpfs

Unless some other filesystem is explicitly mounted to /tmp in /etc/fstab, systemd will mount /tmp as tmpfs. That means it will be emptied on every boot and its size will be limited to 50% of the system's RAM size. To know why this is the desired behavior and how to modify it, take a look at API File Systems.

Configurar la verbosidad de proceso de arranque

Al migrar a systemd lo usuarios suelen notar diferencias en cuanto a la salida verbosa del proceso de arranque:

  • La opción de arranque quiet no solo influye en la salida de información sobre el núcleo, sino también sobre la del propio systemd. No obstante, mientras se configura systemd para la máquina, la opción de monstrar los errores, que fue descartada, podría volver a surgir. Por tanto, después de configurar systemd, añada de nuevo la opción «quiet» para conseguir una salida concisa de información del arranque (y, por ende, un arranque más rápido).
  • Incluso pasando la opción de arranque quiet, systemd todavía se puede configurar para mostrar su estado poniendo el parámetro systemd.show_status=1.
  • Cuando no utilice la opción de arranque quiet, algunos mensajes podrían sobrescribir las consolas. Esto es causado por la configuración del núcleo (ver man 5 proc y buscar /proc/sys/kernel/printk). Para ajustarlo pase el parámetro de arranque loglevel=5 al núcleo (y actualice el valor de acuerdo a su preferencia, por ejemplo, establezca un valor más bajo, como 1).

Servicios

En algún momento el sistema tendrá que ser reiniciado para que systemd se ponga marcha (en modo de sistema). Procure leer todo el presente documento para asegurarse de que systemd se configura tan completamente como sea posible antes de reiniciar (el equipo). Tenga en cuenta que, así como la utilidad journalctl funciona con systemd mientras este no está ejecutándose, por el contrario la utilidad systemctl no hará nada útil sin que systemd esté ejecutándose. Complete la configuración de los servicios (activación e iniciación de los servicios) después de entrar en el sistema que ejecuta systemd.

Servicios OpenRC

Aunque originalmente systemd intentó dar soporte a los antiguos scripts de init.d en ejecución, este apoyo no se adapta bien para un RC basado en dependencias como OpenRC y, por lo tanto, se desactiva por completo en Gentoo. OpenRC ofrece medidas adicionales para garantizar que los scripts de init.d no se ejecuten cuando no se utilice OpenRC para arrancar el sistema (de lo contrario los resultados serían impredecibles).

Listar servicios disponibles

Todas las unidades de servicios disponibles se pueden enumerar usando el argumento list-units con systemctl:

root #systemctl list-units
UNIT                               LOAD   ACTIVE SUB       DESCRIPTION
boot.automount                     loaded active waiting   EFI System Partition Automount
proc-sys-fs-binfmt_misc.automount  loaded active waiting   Arbitrary Executable File Formats File System Automount Point
...

Los siguientes sufijos de archivos son de interés:

Sufijo Descripción
.service archivos de servicio normal (por ejemplo, aquellos que se limitan a ejecutar un demonio directamente),
.socket servicios que escuchan socket (como inetd),
.path sistema de archivos que desencadenan servicios (servicios que se ejecutan cuando cambian los archivos, etc.).

Por otro lado, la herramienta systemctl se puede utilizar para enumerar todos los servicios (incluidos los implícitos):

root #systemctl --all --full

Y, por último, para comprobar los servicios que fallaron al iniciar:

root #systemctl --failed

Activar, desactivar, iniciar y detener servicios

La forma habitual de activar un servicio es usando la siguiente orden:

root #systemctl enable foo.service

Los servicios pueden ser igualmente desactivados:

root #systemctl disable foo.service

Estas órdenes activan los servicios utilizando el nombre por defecto en el target por defecto (ambos especificados en la sección «Install» del archivo de servicio). Sin embargo, algunos servicios, o bien no proporcionan esta información, o bien los usuarios prefieren tener otro nombre/target.

Tenga en cuenta que estas órdenes solo activan o desactivan el servicio en cuestión cuando el sistema se inicie de nuevo en un próximo arranque; para iniciar el servicio inmediatamente (si necesidad de reinicio del sistema), utilice:

root #systemctl start foo.service

Los servicios también pueden ser detenidos:

root #systemctl stop foo.service

Instalar archivos de unidad personalizados

Los archivos de unidad personalizados se pueden colocar en /etc/systemd/system, donde van a ser reconocidos después de ejecutar systemctl daemon-reload:

root #systemctl daemon-reload

/usr/lib/systemd/system está reservado para los archivos de servicios instalados por el gestor de paquetes.

Personalizar archivos de unidad

Cuando solo se necesitan cambios menores en una unidad, no hay necesidad de crear una copia completa del archivo de unidad original en /etc/systemd/system. Sobrescribir la configuración en una unidad proporcionada por el gestor de paquetes se puede lograr mediante archivos colocados en un directorio llamado

  • .d precedido con el nombre de la unidad original (por ejemplo apache2.d) en /etc/systemd/system/.
ARCHIVO /etc/systemd/system/apache2.d/mem-limit.confEjemplo de adición/modificación de la configuración de un archivo de servicio
[Service]
MemoryLimit=1G

Se necesita una recarga de los servicios para informar a systemd de los cambios:

root #systemctl daemon-reload

A continuación, es necesario reiniciar el servicio para aplicar los cambios:

root #systemctl restart apache2

Compruebe que la propiedad cambiada se ha aplicado al servicio:

root #systemctl show --property=MemoryLimit apache2
MemoryLimit=1074000000

Activar un servicio bajo un nombre personalizado

Cuando el nombre proporcionado por «Alias» en la sección «[Install]» de la unidad no cumple con sus expectativas y proporciona un nuevo valor permanente para este a través de una personalización que no es el valor deseado, se puede crear manualmente un enlace simbólico en /etc/systemd/system/*.wants/ (que apunte a otro servicio/target). El nombre del directorio

  • .wants puede especificar un target u otro servicio que dependerá de otro nuevo.

Por ejemplo, para instalar el servicio mysqld.service como db.service en el target multi-user.target:

root #ln -s /usr/lib/systemd/system/mysqld.service /etc/systemd/system/multi-user.target.wants/db.service

Para desactivar el servicio, basta con retirar el enlace simbólico:

root #rm /etc/systemd/system/multi-user.target.wants/db.service

Servicios nativos

Some of Gentoo packages already install systemd unit files. For these services, it is enough to enable them. A quick summary of packages installing unit files can be seen on systemd eclass users list.

La siguiente tabla, lista las coincidencias de los servicios de systemd con los de OpenRC:

Migration chart
Gentoo package OpenRC service systemd unit Notes
sys-apps/openrc bootmisc systemd-tmpfiles-setup.service always enabled, uses tmpfiles.d
consolefont systemd-vconsole-setup.service always enabled, uses vconsole.conf
devfs
dmesg
fsck fsck*.service pulled in implicitly by mounts
functions.sh See note bug #373219
hostname (builtin) /etc/hostname
hwclock See note always enabled as part of systemd (i.e. it is baked in and it is not a unit)
keymaps systemd-vconsole-setup.service always enabled, uses vconsole.conf
killprocs
local
localmount local-fs.target actual units are created implicitly from /etc/fstab
modules systemd-modules-load.service always enabled, uses /etc/modules-load.d/*.conf
mount-ro
mtab
netmount remote-fs.target
numlock
procfs (builtin)
root remount-rootfs.service
savecache n/a OpenRC internals
staticroute
swap swap.target actual units are created implicitly from /etc/fstab
swclock
sysctl systemd-sysctl.service sysctl.conf and sysctl.d/
sysfs (builtin)
termencoding systemd-vconsole-setup.service always enabled, uses vconsole.conf
urandom systemd-random-seed-load.service
systemd-random-seed-save.service
app-admin/rsyslog rsyslog rsyslog.service
app-admin/syslog-ng syslog-ng syslog-ng.service
media-sound/alsa-utils alsasound alsa-store.service (enabled by default)
alsa-restore.socket (enabled by default)
net-misc/dhcpcd dhcpcd dhcpcd.service
net-misc/netifrc net.* net@.service systemd wrapper for net.* scripts (comes with net-misc/netifrc)
netctl@.service net-misc/netctl is originally an Arch Linux tool.
NetworkManager.service For <networkmanager-0.9.8.4 : enable NetworkManager-dispatcher.service for dispatcher.d scripts to work.
Enable NetworkManager-wait-online.service to detect that the system has a working internet connection.
Disable all other managers (e.g., wicd, dhcpcd) and wpa_supplicant.
dhcpcd.service Provided by net-misc/dhcpcd
systemd.networkd.service Part of systemd
net-misc/openntpd ntpd ntpd.service
net-misc/openssh sshd sshd.service runs sshd as a daemon
sshd.socket runs sshd on a inetd-like basis (for each incoming connection)
net-wireless/wpa_supplicant wpa-supplicant wpa_supplicant.service D-Bus controlled daemon (e.g. for NetworkManager)
wpa_supplicant@.service interface-specific wpa_supplicant (used like wpa_supplicant@wlan0.service)
net-print/cups cupsd cups.service classic on-boot start up service
cups.socket socket and path activation (cups only started on-demand)
cups.path
net-wireless/bluez bluetooth bluetooth.service
sys-apps/dbus dbus dbus.service
dbus.socket
sys-apps/irqbalance irqbalance irqbalance.service supports daemon mode only
sys-apps/microcode-ctl microcode_ctl Configure microcode as a module to let it load the microcode itself. Go to "Processor type and features" -> "CPU microcode loading support" and remember to add the right option based on the system having an intel or amd processor.
sys-fs/udev udev udev.service
udev-mount (builtin) /dev is mounted as tmpfs
udev-postmount udev-trigger.service
udev-settle.service
sys-power/acpid acpid acpid.service Most of its functionality is done by systemd itself, so consider disabling this
x11-apps/xdm (xdm) xdm.service OpenRC uses common xdm init.d installed by x11-base/xorg-server. With systemd the corresponding unit file for each DM (gdm.service, kdm.service...) needs to be enabled.
net-firewall/iptables iptables iptables-store.service
iptables-restore.service

Servicios con temporizador

Desde la versión 197, systemd soporta temporizadores, haciendo de cron un programa innecesario en un sistema systemd. Desde la versión 212, se da soporte a los servicios persistentes, reemplazando, incluso, a anacron. Los temporizadores persistentes se ejecutan en la próxima oportunidad, si el sistema se apaga cuando se programó el temporizador.

El siguiente es un ejemplo de cómo hacer un temporizador simple que se ejecuta en el contexto de un usuario. Será ejecutado incluso si el usuario no inicia sesión. Cada servicio con temporizador necesita un temporizador, y un archivo de servicio que se activa por el temporizador de la siguiente manera:

ARCHIVO ~/.local/share/systemd/user/backup-work.timerEjemplo de un temporizador que se ejecuta todos los días laborables
[Unit]
Description=daily backup work
RefuseManualStart=no
RefuseManualStop=no
 
[Timer]
Persistent=false
OnCalendar=Mon-Fri *-*-* 11:30:00
Unit=backup-work.service
 
[Install]
WantedBy=default.target
ARCHIVO ~/.local/share/systemd/user/backup-work.serviceEjemplo de un servicio que ejecuta una copia de seguridad
[Unit]
Description=daily backup work
RefuseManualStart=no
RefuseManualStop=yes
 
[Service]
Type=oneshot
ExecStart=/home/<nombredeusuario>/scripts/backup-work.sh

En primer lugar, hay que decirle a systemd que recargue los archivos de servicio:

user $systemctl --user daemon-reload

Es posible realizar la copia de seguridad manualmente ejecutando la siguiente orden:

user $systemctl --user start backup-work.service

Se puede iniciar y detener el temporizador manualmente de la siguiente manera:

user $systemctl --user start backup-work.timer
user $systemctl --user stop backup-work.timer

Por último, para activar el temporizador en cada inicio del sistema, ejecute:

user $systemctl --user enable backup-work.timer

Para comprobar los últimos resultados de la ejecución del servicio:

user $systemctl --user list-timers

Correos electrónicos para comunicar fallos

Si un servicio programado se ejecuta y falla, se puede enviar un correo electrónico al usuario o administrador para informarle. Esto es posible con la línea «onfailure» que especifica lo que debería suceder si un servicio falla. Un fallo es detectado cuando el script invocado devuelve un código distinto de cero.

Habrá que cambiar el script de la siguiente manera:

ARCHIVO ~/.local/share/systemd/user/backup-work.serviceEjemplo de un servicio que ejecuta una copia de seguridad
[Unit]
Description=daily backup work
RefuseManualStart=no
RefuseManualStop=yes
OnFailure=failure-email@%i.service
 
[Service]
Type=oneshot
ExecStart=/home/<nombredeusuario>/scripts/backup-work.sh

Esto requiere que tenga el servicio failure-email@.service instalado, que se puede encontrar en kylemanna's systemd-utils repository.

Sustituir cron

Los archivos con temporizador y de servicios vistos antes también se pueden añadir a /usr/lib/systemd/system para hacerlos disponibles a todo el sistema. La sección «install» debería decir entonces WantedBy=multi-user.target para activar el servicio al iniciar el sistema.

Sin embargo, también cron ejecuta los scripts situados en /etc/cron.daily y otros lugares. Varios paquetes colocan scripts allí donde se espera que se ejecuten diariamente. Este comportamiento puede ser emulado con systemd instalando sys-process/systemd-cron. Luego active el nuevo reemplazo de cron con las siguientes órdenes:

root #systemctl enable cron.target
root #systemctl start cron.target

Solución de problemas

/dev/kmsg buffer overrun, some messages lost

Problema
Cuando se inicia el sistema, se muestra el mensaje /dev/kmsg buffer overrun, some messages lost en un bucle infinito. La pantalla de acceso no se llega a mostrar ya que no se alcanza ese punto del proceso de arranque.
Solución
En la mayoría de los casos este problema está causado porque la opción CONFIG_POWER_SUPPLY_DEBUG está habilitada en el núcleo. La solución actual consiste en deshabilitar esta opción en el núcleo, recompilar, instalar e iniciar el nuevo núcleo. Se puede encontrar la descripción de la solución en este hilo de los foros de Gentoo. Tal y como indica un usuario del foro, este problema se ha observado también cuando se utiliza una EEPROM I2C en un sistema incrustado[2]. La solución en este caso consiste en deshabilitar la opción CONFIG_I2C_DEBUG_CORE del núcleo.

Sesiones gráficas abiertas en lugares aleatorios

Por defecto, systemd lanza únicamente un proceso getty cuando se va a utilizar. Esto causa que algunos gestores gráficos (como GDM) utilicen los TTYs que queden para abrir sesiones gráficas bajo demanda lo cual puede resultar en tener las consolas y las sesiones gráficas repartidas de forma aleatoria dependiendo en el orden en el que se hayan utilizando.

Para que el comportamiento sea más "clásico" (esto es, las consolas se emplazan desde la tty1 a la tty6 y las sesiones gráficas utilizan los TTY que quedan) forzar a lanzar siempre getty en ellas:

root #systemctl enable getty@tty{2,3,4,5,6}.service

LVM

When switching from OpenRC to systemd and LVM is needed to properly mount the system volumes, activate the LVM service:

root #systemctl enable lvm2-monitor.service

While it might not be needed for activation of the root volume (if LVM is integrated into the initramfs) it might not work for other LVM volumes, unless the service is activated.

systemd-bootchart

Asegurarse de que CONFIG_DEBUG_KERNEL, CONFIG_SCHED_DEBUG y CONFIG_SCHEDSTATS están habilitadas.

KERNEL Habilitar el soporte para systemd-bootchart
File systems  --->
	Pseudo filesystems --->
	[*] /proc file system support
Kernel hacking  --->
	[*] Kernel debugging
	[*] Collect scheduler debugging info
	[*] Collect scheduler statistics

A continuación habilitar systemd-bootchart.service:

root #systemctl enable systemd-bootchart

El resultado de los cambios producirán un informe gráfico de arranque en formato SVG localizado en /run/log/ después de cada inicio. Se puede visualizar utilizando cualquier navegador Web actual.

Como alternativa a systemd-bootchart, el arranque de los servicios se puede visualizar con:

root #systemd-analyze plot > plot.svg

Fuente syslog-ng para systemd

No es necesario añadir unix-dgram('/dev/log'); al fichero de configuración /etc/syslog-ng/syslog-ng.conf. Causará el fallo de syslog-ng (al menos en la versión syslog-ng-3.7.2). Actualizar la línea source src { ...; }; mencionada en el artículo sobre syslog-ng como se muestra a continuación:

ARCHIVO /etc/syslog-ng/syslog-ng.conf
# Configuración por defecto para openrc
#source src { system(); internal(); };
 
# systemd
source src { systemd-journal(); internal(); };

Configuración de sys-fs/cryptsetup

systemd no parece respetar /etc/conf.d/dmcrypt (vea bug #429966) por lo que necesita ser configurado a través del archivo /etc/crypttab:

ARCHIVO /etc/crypttabArchivo de configuración para dispositivos de bloque cifrado
crypt-home UUID=c25dd0f3-ecdd-420e-99a8-0ff2eaf3f391 -

Respecto al fichero /etc/crypttab del sistema, puede ser necesario crear un nuevo fichero de servicio. Para hacer esto, habilitar el ajuste USE cryptsetup para sys-apps/systemd. Esto instalará /usr/lib/systemd/system-generators/systemd-cryptsetup-generator. Al lanzarlo se creará el fichero de servicio en /tmp/ que puede copiarse a /etc/systemd/system. Ajustarlo manualmente y añadirlo al nivel de ejecución deseado.

Comprobar la unidades que fallan al inicio

Compruebe si hay unidades que no pudieron comenzar con:

root #systemctl --failed

Activar modalidad de depuración de errores

Para obtener más información estableca lo siguiente en /etc/systemd/system.conf:

ARCHIVO /etc/systemd/system.conf
LogLevel=debug

O, active la depuración de errores en consola, que abre una terminal en tty9. Esto ayuda a depurar errores de los servicios durante el proceso de arranque.

root #systemctl enable debug-shell.service

La utilización de e4rat

Recuerde editar /etc/e4rat.conf para configurar 'init' para /usr/lib/systemd/systemd, de lo contrario se mantendrá el arranque de OpenRC.

Rigidez de GRSecurity

Con grsecurity activado, systemd-networkd podría registrar el error siguiente:

CÓDIGO systemd-networkd error
could not find udev device: Permission denied

El error aumenta debido a que cuando systemd-networkd trabaja bajo un usuario no root, grsecurity denegará el acceso a la estructura completa de /sys para dichos usuarios. Para desactivar esta opción, desactive la opción del núcleo CONFIG_GRKERNSEC_SYSFS_RESTRICT.

También se pueden encontrar alguno problemas con los permisos si se ha activado CONFIG_GRKERNSEC_PROC, leer más en la incidencia bug #472098.

shutdown -rF no fuerza la ejecución de fsck

El servicio systemd-fsck es el responsable de lanzar fsck cuando se necesita. No aplica para la opción -rF de shutdown per en lugar de eso se aplica a los siguientes parámetros de inicio del núcleo.

Parámetro de inicio Opciones soportadas Descripción
fsck.mode auto
force
skip
Controla el modo de operación. El valor por defecto es auto el cual asegura que se realizan comprobaciones del sistema de archivos cuando el comprobador del sistema de archivos lo estima necesario. force resulta en la comprobación completa del sistema de archivos incondicionalmente. skip evita cualquier comprobación del sistema de archivos.
fsck.repair preen
yes
no
Controla el modo de operación. El valor por defecto es preen el cual reparará de forma automática problemas que se pueden resolver de forma segura. yes contestará sí a todas las preguntas realizadas por fsck y no contestará no a todas esas preguntas.

Véase también

Recursos externos

Referencias