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.

• maintains mount and automount points: Systemd monitors all mount points how they come and go, and can also be used to mount or unmount mount-points. /etc/fstab can be used here as an additional configuration source for these mount points. Using the comment= fstab option you can even mark /etc/fstab entries to become systemd controlled automount points..

• implements an elaborate transactional dependency-based service control logic: Systemd supports several kinds of dependencies between services (or units), using After/Before, Requires and Wants options in the unit configuration files to fix the ordering how units are activated. Requires and Wants, express a positive requirement dependency, either mandatory, or optional. There is Conflicts which expresses a negative requirement dependency, and others less used. As a transactional control, if a unit is requested to start up or shut down, systemd will add it and all its dependencies to a temporary transaction, verifing if the transaction is consistent (or the ordering via After/Before of all units is cycle-free). If it is not, systemd will try to fix it up, and removes non-essential jobs from the transaction that might remove the loop.

y:

• For each process spawned, it controls: The environment, resource limits, working and root directory, umask, OOM killer adjustment, nice level, IO class and priority, CPU policy and priority, CPU affinity, timer slack, user id, group id, supplementary group ids, readable/writable/inaccessible directories, shared/private/slave mount flags, capabilities/bounding set, secure bits, CPU scheduler reset of fork, private /tmp name-space, cgroup control for various subsystems. Also, you can easily connect stdin/stdout/stderr of services to syslog, /dev/kmsg, arbitrary TTYs. If connected to a TTY for input systemd will make sure a process gets exclusive access, optionally waiting or enforcing it.

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

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.