From Fedora Project Wiki
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 hacer que systemd las controle como 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.
  • The native configuration files use a syntax that closely follows the well-known .desktop files: It is a simple syntax for which parsers exist already in many software frameworks. Also, this allows to rely on existing tools for i18n for service descriptions, and similar, without for admins the need to learn a new syntax.
  • 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
There's a minimal UI, systemadm that allows to start/stop/introspect services. It is part of the systemd-gtk package It's a work in progress and is not functional yet, but useful as a debugging tool. It's written in Vala. Do not use it for now unless you are a developer

(... y más avanzados)

  • Compatibility with SysV init scripts: It takes advantages of LSB and Red Hat chkconfig headers if they are available, if not, it uses otherwise available information, such as the start priorities in /etc/rc.d. These init scripts are simply considered a different source of configuration, easing the upgrade path to proper systemd services.
  • /etc/fstab configuration file: it just another source of configuration. Using the comment= fstab option it is possible to mark /etc/fstab entries to become systemd controlled automount points.
  • Support a simple templating/instance mechanism: For example, instead of having six configuration files for six gettys, it has only one getty@.service file which gets instantiated to getty@tty2.service and suchlike. The interface part can even be inherited by dependency expressions, i.e. it is easy to encode that a service dhcpcd@eth0.service pulls in avahi-autoipd@eth0.service, while leaving the eth0 string wild-carded.
  • Compatibility, to a certain extent, with /dev/initctl. This compatibility is in fact implemented with a FIFO-activated service, which simply translates these legacy requests to D-Bus requests. Effectively this means the old shutdown, poweroff and similar commands from Upstart and sysvinit continue to work with systemd.
  • Compatibilidad con utmp y wtmp (En una medida que es mucho más que saludable, dada la mala calidad que actualmente tienen utmp y wtmp).

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

Retrieved from "https://fedoraproject.org/w/index.php?title=Systemd/es&oldid=308003"