Systemd/es

In other languages: English (en) español (es) italiano (it) português do Brasil (pt-br) 中文（中国大陆） (zh-cn) [edit]

Por favor ayuda a pulir esta traducción.

systemd es un sistema y administrador de servicios para Linux, compatible con scripts de inicio (init) SysV y LSB. systemd proporciona capacidades de paralelización agresivas, utiliza socket y activación D-Bus para iniciar los servicios, ofrece la puesta en marcha de demonios bajo demanda, realiza el seguimiento de procesos utilizando Linux cgroups, soporta copia instantánea de volumen y la restauración de estado del sistema, mantiene puntos de montaje y automontaje e implementa un elaborado servicio lógico de control transaccional basado en la dependencia. Puede funcionar como un reemplazo para sysvinit. Para más información, ver el video en http://linuxconfau.blip.tv/file/4696791/ o http://www.youtube.com/watch?v=TyMLi8QF6sw

Para administradores de sistemas
Los administradores de sistemas pueden visitar esta página, para entender cómo usar las llamadas systemctl nativas que reemplacen su antiguo flujo de trabajo en SysVinit. Tenga en cuenta que los comandos service y chkconfig seguirán trabajando como se esperaba en el mundo de systemd.

¿Por qué systemd?

http://0pointer.de/blog/projects/why.html

Introducción

systemd inicia y supervisa todo el sistema y se basa en la noción de unidades compuestas de un nombre, tipo y coincidencia de un archivo de configuración con el mismo nombre y tipo (por ejemplo, una unidad avahi.service tiene un archivo de configuración con el mismo nombre y es una unidad de encapsulado del demonio Avahi). Existen siete tipos diferentes de unidades:

1. service: este es el tipo más obvio de unidad: demonios que pueden ser iniciados, detenidos, reiniciados, recargados.
2. socket: Esta unidad encapsula un socket en el sistema de archivos o en Internet. Actualmente systemd soporta el funcionamiento de los tipos de sockets AF_INET, AF_INET6, AF_UNIX, datagram y paquetes secuenciales. También puede soportar FIFOs clásicos como transporte. Cada unidad socket tiene una unidad de servicio correspondiente, que se inicia si la primera conexión entra en el socket o FIFO (por ejemplo, nscd.socket inicia nscd.service en una conexión entrante).
3. device: esta unidad encapsula un dispositivo en el árbol de dispositivos de Linux. Si un dispositivo está marcado para ello a través de reglas udev, se expondrá como una unidad device en systemd. Las propiedades establecidas con udev pueden utilizarse como configuración fuente para establecer dependencias para unidades device.
4. mount: esta unidad encapsula un punto de montaje en la jerarquía del sistema de archivos.
5. automount: este tipo de unidad encapsula un punto de montaje automático en la jerarquía del sistema de archivos. Cada unidad automount tiene una unidad mount correspondiente, que se inicia (es decir, montada) tan pronto como se accede al directorio de automontaje.
6. target: este tipo de unidad se utiliza para la agrupación lógica de unidades: en vez de realmente hacer nada por sí misma simplemente hace referencia a otras unidades, que así pueden ser controladas conjuntamente, (por ejemplo, multi-user.target, que es un objetivo que básicamente desempeña el papel de nivel de ejecución 5 en el sistema clásico SysV; o bluetooth.target que es solicitado tan pronto como esté disponible un adaptador bluetooth y que simplemente carga servicios relacionados con bluetooth que de lo contrario no tendrían que iniciarse: bluetoothd, obexd y cosas por el estilo).
7. snapshot: similar a las unidades target, snapshots en realidad no hacen nada ellas mismas y su único propósito es hacer referencia a otras unidades.

Documentación de systemd

systemd tiene documentación muy completa. Consulte

http://0pointer.de/blog/projects/systemd-docs.html

Características de systemd

systemd ofrece lo siguiente:

• Capacidades de paralelización agresiva usando socket: para acelerar el arranque completo e iniciar más procesos en paralelo, systemd crea los sockets de escucha antes de iniciar realmente el demonio y sólo pasa el socket al mismo. Todos los sockets para todos los demonios se crean en un solo paso en el sistema de inicio (init) y luego en un segundo paso ejecuta a la vez todos los demonios. Si un servicio necesita de otro, y no se ha iniciado completamente, lo que sucederá es que la conexión esté en la cola del servicio de suministro y el cliente potencialmente se bloqueará en esa única solicitud. Pero sólo ése cliente se bloquea y solo en ésa solicitud. También, las dependencias entre servicios ya no tienen que estar configuradas para permitir el correcto arranque paralelizado: iniciando todos los sockets a la vez y un servicio que necesite de otro, seguramente se podrá conectar a su socket.

• Activación D-Bus para iniciar servicios: utilizando la activación bus, un servicio puede ser iniciado la primera vez que se accede. La activación bus también da la sincronización por solicitud mínima necesaria para poner en marcha los proveedores y consumidores de servicios de D-Bus al mismo tiempo: iniciando un servicio al mismo tiempo que otro, si uno es más rápido, a través de la lógica de activación bus, las colas de D-Bus lo solicitan hasta que el otro consigue establecer su nombre de servicio.

• ofrece inicio de demonios bajo demanda

• Realiza el seguimiento de procesos utilizando Linux cgroups: cada proceso ejecutado obtiene su propio cgroup y es muy fácil de configurar systemd para realizar servicios en cgroups que han sido configurados externamente, por ejemplo a través de las utilidades de libcgroups.

• Soporta snapshotting y restauración de estado del sistema: las Snapshots pueden ser utilizadas para guardar/restaurar el estado de todos los servicios y unidades del sistema de inicio (init). Principalmente tiene dos casos de uso: para permitir al usuario temporalmente entrar en un estado específico como «Shell de emergencia», la terminación de los servicios actuales y proporcionar una manera fácil para regresar al estado anterior, activando otra vez todos los servicios que consiguió desactivar temporalmente.

• Mantiene puntos de montaje y automontaje: systemd supervisa cómo vienen y van todos los puntos de montaje y también puede utilizarse para montar o desmontar los puntos de montaje. /etc/fstab puede utilizarse aquí como una fuente de configuración adicional para estos puntos de montaje. Usando la opción comment= de fstab incluso puede marcar entradas en /etc/fstab para que sean controladas por systemd a través de los puntos de automontaje.

• Implementa una elaborada lógica de control de servicios transaccional basada en la dependencia: systemd admite varios tipos de dependencias entre servicios (o unidades), utilizando las opciones After/Before, Requires y Wants en los archivos de configuración de la unidad para fijar el orden de cómo se activarán las unidades. Requires y Wants, expresan una dependencia de requisito positivo, obligatorio u opcional. Existe Conflicts que expresa una dependencia de requisito negativo y otras menos utilizadas. Como un control transaccional, si se solicita una unidad de arranque o se apaga, systemd la añadirá con todas sus dependencias a una transacción temporal, verificando si la transacción es consistente (o el orden vía After/Before de todas las unidades es de ciclo libre). Si no es así, systemd intentará solucionarlo y eliminará las tareas no esenciales de la transacción que podrían quitar el bucle.

y:

• Por cada proceso generado, controla: el entorno, límites de recursos, directorio de trabajo y raíz, máscara de usuario (umask), ajuste de OOM killer, nivel de nice, IO class y prioridad, política y prioridad de la CPU, afinidad de la CPU, temporizador (timer slack), id de usuario, id de grupo, identificadores de grupo complementario, directorios de lectura/escritura/inaccesible, montaje de banderas (flags) compartida/privada/esclava, capabilities/bounding set, secure bits, CPU scheduler reset of fork, private /tmp name-space, control de cgroup para distintos subsistemas. También puede conectar fácilmente stdin/stdout/stderr de servicios a syslog, /dev/kmsg, TTYs arbitrarias. Si está conectado a TTY para entrar a systemd asegúrese que un proceso obtenga acceso exclusivo, opcionalmente en espera o forzado.

• Los archivos de configuración nativa utilizan una sintaxis que sigue de cerca los archivos .desktop conocidos: es una sintaxis simple para los analizadores sintácticos que ya existen en mucho software frameworks. Además, esto permite contar con las herramientas existentes de internacionalización (i18n) para descripciones de servicios y similares, sin que los administradores necesiten aprender una nueva sintaxis.

systemadm
Hay una interfaz de usuario mínima, systemadm que permite iniciar/detener/examinar servicios. Es parte del paquete systemd-gtk. Es un trabajo en progreso y aún no es funcional, pero útil como herramienta de depuración. Está escrito en Vala. No lo utilice por ahora a menos que sea un desarrollador.

(... y más avanzados)

• Compatibilidad scripts de inicio (init) SysV: toma ventajas de LSB y encabezados Red Hat de chkconfig si están disponibles, si no, utiliza otra forma de información disponible, como las prioridades de inicio en /etc/rc.d. Estos scripts init simplemente son considerados una fuente diferente de configuración, facilitando la ruta de actualización a los servicios de systemd adecuados.

• Archivo de configuración /etc/fstab: es otra fuente de configuración. Usando la opción comment= de fstab es posible marcar entradas en /etc/fstab para que sean controladas por systemd a través de los puntos de automontaje.

• Soporta un mecanismo simple de plantillas/instancia: por ejemplo, en lugar de tener seis archivos de configuración para seis gettys, tiene sólo un archivo getty@.service que crea una instancia getty@tty2.service y cosas por el estilo. La parte de la interfaz incluso puede ser heredada por las expresiones de la dependencia, es decir, es fácil de codificar que un servicio dhcpcd@eth0.service cargue avahi-autoipd@eth0.service, mientras permita la eth0 con cadena de comodines.

• Compatibilidad, hasta cierto punto, con /dev/initctl. De hecho, esta compatibilidad se implementa con un servicio FIFO-activated, que simplemente traduce estas solicitudes heredadas a las peticiones D-Bus. Efectivamente esto significa el antiguo shutdown, poweroff y comandos similares de Upstart y sysvinit siguen trabajando con systemd.

• Compatibilidad con utmp y wtmp (En una medida que es mucho más que saludable, dada la mala calidad que hoy tienen utmp y wtmp).

Para todos los detalles ver Una pequeña lista de otras características en el blog del desarrollador.

Herramientas

• systemctl: usada para examinar y controlar el estado del sistema systemd y el administrador de servicios.
• systemd-cgls: muestra recursivamente el contenido del árbol de jerarquías de un determinado grupo de control de Linux.
• systemadm: una interfaz gráfica para el sistema systemd y el administrador de servicios que permite la introspección y el control de systemd. Es parte del paquete systemd-gtk. Esta es una versión temprana y necesita más trabajo. No la utilice por ahora a menos que sea un desarrollador.

Ver las páginas man para obtener más detalles.

Línea de comandos de arranque del Kernel

En el arranque systemd activa (por defecto), la unidad target default.target cuyo trabajo es activar servicios y otras unidades arrastrándolas a través de las dependencias.

Para reemplazar la unidad a activar, systemd analiza sus propios argumentos de la línea de comandos del kernel a través de la opción de línea de comandos systemd.unit=. Esto puede utilizarse para arrancar temporalmente una unidad de arranque distinto. Los niveles de ejecución clásicos se reemplazan como sigue:

systemd.unit=rescue.target es una unidad target especial para configurar el sistema base y un shell de rescate (similar al nivel 1 de ejecución); systemd.unit=emergency.target, es muy similar a passing init=/bin/sh pero con la opción para arrancar el sistema completo desde allí; systemd.unit=multi-user.target para configurar un sistema multiusuario no gráfico; systemd.unit=graphical.target para configurar una pantalla gráfica de ingreso (login).

Para obtener más información acerca de estas unidades de arranque systemd especial, ver la página man systemd.special.

¿Cuál es el estado de systemd en Fedora?

Fedora 14 lo presentó como un avance de esta tecnología. Es el predeterminado en Fedora 15 y superior, en sustitución de Upstart.

¿Tienen todos los archivos init heredados de System V que convertirse en archivos service de systemd o equivalentes?

Muchos de los servicios principales (/lib/systemd/system tienen y pueden comprobar el estado en http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability) si han sido convertidos pero no todos ellos todavía. La transición está prevista para Fedoral 16. Detalles en http://fedoraproject.org/wiki/Features/SysVtoSystemd. systemd es totalmente compatible con los scripts de inicio (init) heredados.

¿Qué es la herramienta para administrar los servicios con systemd?

systemctl es la herramienta principal para usar. Combina la funcionalidad de ambos servicios y chkconfig en una única herramienta que puede utilizar por ejemplo para activar/desactivar servicios permanentemente o sólo para la sesión actual.

lista de todos los servicios en ejecución, etc.:

 systemctl 

Consulte man systemctl para más detalles. systemd-cgls enumera los procesos en ejecución en forma de árbol. Puede mostrar de forma recursiva el contenido de cualquier grupo de control determinado. Consulte man systemd-cgls para más detalles.

¿Cómo iniciar/detener o activar/desactivar servicios?

Activa un servicio inmediatamente:

 systemctl start foo.service 

Desactiva un servicio inmediatamente:

 systemctl stop foo.service 

Reinicia un servicio:

 systemctl restart foo.service 

Muestra el estado de un servicio, incluyendo si se está ejecutando o no:

 systemctl status foo.service 

Permite un servicio para iniciarse en el arranque:

 systemctl enable foo.service 

Deshabilita un servicio para que no se inicie durante el arranque:

 systemctl disable foo.service 

Comprueba si un servicio ya está habilitado o no:

 systemctl is-enabled foo.service; echo $? 

0 indica que está activado, y 1 indica que está desactivado. En Fedora 17, además del código de retorno, «activado» o «desactivado» se imprimirá en la salida estándar (stdout).

Consulte man systemctl para más detalles.

¿Cómo se puede cambiar el nivel de ejecución (runlevel)?

systemd tiene el concepto de targets, que es un reemplazo más flexible para los niveles de ejecución en sysvinit.

El nivel de ejecución 3 es emulado por multi-user.target. El nivel de ejecución 5 es emulado por graphical.target. runlevel3.target es un enlace simbólico a multi-user.target y runlevel5.target es un enlace simbólico a graphical.target.

Puede cambiar a 'nivel de ejecución 3' ejecutando

 systemctl isolate multi-user.target (o) systemctl isolate runlevel3.target 

Puede cambiar a 'nivel de ejecución 5' ejecutando

 systemctl isolate graphical.target (o) systemctl isolate runlevel5.target 

¿Cómo se puede cambiar el nivel de ejecución predeterminado?

systemd utiliza symlinks (enlaces simbólicos) para señalar el nivel de ejecución predeterminado. Tiene que eliminar primero el symlink existente antes de crear uno nuevo.

 rm /etc/systemd/system/default.target 

Cambiar a nivel de ejecución 3 por defecto

 ln -sf /lib/systemd/system/multi-user.target /etc/systemd/system/default.target 

Cambiar a nivel de ejecución 5 por defecto

 ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target 

systemd no utiliza el archivo /etc/inittab.

¿Cómo saber el nivel de ejecución actual?

El comando runlevel todavía funciona con systemd. Puede continuar usándolo, sin embargo los runlevels son un concepto heredado en systemd y es emulado a través de 'targets' y múltiples targets que se pueden activar al mismo tiempo. Por lo que es el equivalente en términos de systemd.

 systemctl list-units --type=target 

¿Cómo apagar la máquina?

Se puede utilizar

 poweroff 

Algunas posibilidades más son: halt -p, init 0, shutdown -P now

Tenga en cuenta que halt solía trabajar igual a poweroff en anteriores versiones de Fedora, pero systemd distingue entre los dos, por lo que halt sin parámetros ahora hace exactamente lo que dice - simplemente se detiene el sistema sin apagarlo.

¿Funciona el comando service con systemd?

Sí. Se ha modificado para llamar a systemctl automáticamente cuando trate con archivos service de systemd. Así que cualquiera de los siguientes comandos hace lo mismo.

 service NetworkManager stop 

(o)

 systemctl stop NetworkManager.service 

¿Funciona el comando chkconfig con systemd?

Sí, para encender/apagar servicios, la compatibilidad ha proporcionado ambas formas. chkconfig ha sido modificado para llamar a systemctl al tratar con archivos service de systemd. También systemctl llama automáticamente a chkconfig cuando se trata de un archivo init sysv tradicional.

Así que cualquiera de los siguientes comandos hace lo mismo

 chkconfig NetworkManager off 

(o)

 systemctl disable NetworkManager.service 

chkconfig --list no lista servicios de systemd, sólo servicios de Sys V. La salida de chkconfig toma nota de esto, junto con la información adicional presentada.