Systemd/es

From FedoraProject

< Systemd(Difference between revisions)
Jump to: navigation, search
(Introducción)
Line 16: Line 16:
 
# <code>service</code>: este es el tipo más obvio de unidad: demonios que pueden ser iniciados, detenidos, reiniciados, recargados.
 
# <code>service</code>: este es el tipo más obvio de unidad: demonios que pueden ser iniciados, detenidos, reiniciados, recargados.
 
# <code>socket</code>: 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).
 
# <code>socket</code>: 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).
# <code>device</code>: 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 de dispositivo en systemd. Las propiedades establecidas con udev pueden utilizarse como configuración fuente para establecer dependencias para unidades de dispositivos.
+
# <code>device</code>: 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.
# <code>mount</code>: this unit encapsulates a mount point in the file system hierarchy.
+
# <code>mount</code>: esta unidad encapsula un punto de montaje en la jerarquía del sistema de archivos.
# <code>automount</code>: this unit type encapsulates an automount point in the file system hierarchy. Each automount unit has a matching mount unit, which is started (i.e. mounted) as soon as the automount directory is accessed.
+
# <code>automount</code>: 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.
# <code>target</code>: this unit type is used for logical grouping of units: instead of actually doing anything by itself it simply references other units, which thereby can be controlled together. (e.g. multi-user.target, which is a target that basically plays the role of run-level 5 on classic SysV system; or bluetooth.target which is requested as soon as a bluetooth dongle becomes available and which simply pulls in bluetooth related services that otherwise would not need to be started: bluetoothd and obexd and suchlike).
+
# <code>target</code>: 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).
# <code>snapshot</code>: similar to target units snapshots do not actually do anything themselves and their only purpose is to reference other units.
+
# <code>snapshot</code>: 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

Revision as of 05:01, 20 October 2012

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

Note.png
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