systemd, otro reemplazo de init<http://diegocg.blogspot.com/2010/05/systemd-otro-reemplazo-de-init.html> Justo cuando parecía seguro que *upstart* era el futuro, cuando todas las distribuciones lo habían integrado o planeaban hacerlo, ocurre lo que tantas veces en el mundo linuxero: Sale alguien implementado algo totalmente diferente porque no termina de gustarle la nueva propuesta. Estas cosas sin duda son una enorme pérdida tiempo en muchos casos, pero también una gran fuente de creatividad. Ese es el caso de *systemd*, el nuevo juguete de Lennart Poettering <http://0pointer.de/blog/projects/systemd.html> (tambien creador del magnífico Pulseaudio). Pero antes, algo sobre *upstart*. En lugar de usar dependencias de unos archivos a otros, como hicieron varias intentonas de paralelización del sistema tradicional sysvinit, las dependencias son en base a eventos. Por ejemplo, al iniciarse el sistema *upstart* genera el evento "startup". A continuación, *upstart* interpreta todos los archivos de eventos (trabajos, en jerga *upstart*) de /etc/event.d que tengan la dependencia "start on startup". El trabajo puede ejecutar un script, un comando, o emitir un evento ("emit mi-propio-evento"). En este último caso, *upstart* ejecutaría todos los trabajos que tengan un "start on mi-propio-evento". Tambien hay eventos específicos para interfaces de red, etc. Poettering ha aplicado otro punto de vista al problema. Prescinde de las dependencias y la sincronización la relega a mecanismos sistémicos de bajo nivel. Bajo *systemd* todos los servicios del sistema podrían arrancarse a la vez, sin preocuparse de que tal servicio depende de otro. Por ejemplo, podría arrancarse X.org antes que D-Bus (que X.org necesita para pedir a udev la lista de dispositivos de entrada). Esto, claro está, causaría un fallo en el inicio de X.org, las dependencias de *upstart* existen, precisamente, para prevenir este problema. ¿Y qué hace *systemd* para evitar el fallo de X.org? El truco utilizado es el mismo que utiliza inetd o el *launchd* de Mac OS X. Buena parte de las dependencias de sysvinit o de *upstart* están para que un servicio (ej, X.org) espere a que otro servicio arranque y cree un socket Unix (ej, el socket de D-Bus) para poder comunicarse con él. Bien, pues resulta que esos sockets pueden crearse antes de que los servicios (D-Bus en este caso) arranquen. *systemd*, mismamente, puede crearlos -pero sin "escuchar" lo que se envía a ellos-, y las aplicaciones (X.org) pueden conectarse e incluso escribir a ese socket, porque el kernel va guardando en un buffer todo, a espera de que alguien se decida a leerlo. Solo cuando esto sucede, *systemd* decide iniciar el servicio (D-Bus), que una vez finalizado su arranque se pone al día leyendo los buffers acumulados. Esto implica que las dependencias no son necesarias, *systemd* crearía todos los sockets de todos los servicios pero sin iniciar ninguno inicialmente, solo los arrancaría a medida que los clientes los intentan utilizar. Hay una gran ventaja de este sistema sobre *upstart*, derivado de la ausencia de dependencias. Si en *upstart *hay, por ejemplo, varios servicios que tienen la línea "start on dbus", al iniciar D-Bus se iniciarán esos servicios (X.org, avahi, networkmanager, vaya usted a saber). Esto ocurre incluso si no era esa la intención del administrador. Con *systemd* esta situación no es posible. Simplemente se iniciaría X.org, o Networkmanager, o avahi, y D-Bus sería iniciado automáticamente sólo cuando alguien intente leer su socket. Aun con todo lo hasta aquí descrito, *systemd* no sería más que una reimplementación del *launchd* de Mac OS X. Sin embargo, no se queda ahí. Poettering identifica otro "punto de contención" en el inicio: los montajes en el sistema de archivos. Ciertos servicios tienen que esperar a que ciertos puntos de montaje estén disponibles antes de iniciarse. Además, al iniciar el sistema hay que montar -y quizás fsck'ear- los sistemas de archivo que indique /etc/fstab (y mientras se hace esta tarea quizás se pierde la oportunidad de iniciar algunos scripts que tienen sus puntos de montaje ya montados). *systemd* se basa en el viejo y fiable autofs (un "montador automático") para aplicar la misma idea que en los sockets: todos los montajes posibles se pre-crean sin que esté montados realmente, y autofs los irá montando de verdad -y quizás fsckeando- a medida que los servicios intenten acceder a ellos, pero no antes. Con este sistema, *systemd* hace que /etc/fstab sea algo obsoleto o al menos prescindible. Todo esto ya de por si hace de *systemd *una seria alternativa a *upstart* y una mejora respecto a otros sistemas de inicio. Sin embargo, un sistema de inicio debe hacer más cosas que gestionar lo descrito anteriormente. Debe intentar reiniciar un servicio si se cae, o apagarle y enviar una alerta al administrador si se cae demasiado. Para hacer bien esta tarea de niñera, el sistema de inicio debe tener conocimiento de lo que hacen todos los procesos hijos que los servicios crean, algo que no es sencillo en Unix (*upstart* lo logra analizando datos de /proc), ya que los procesos "nietos" del sistema de inicio pueden perderse y existir a su aire sin que su "abuelo" se entere de qué ocurre. Para solucionarlo Poettering usa, en vez de los trucos que utilizan otros sistemas, una de las novedades más potentes y menos conocidas de los últimos kernels: "Control Groups" (cgroups). cgroups son "grupos de procesos" elegidos al azar, y que comparten, como grupo, una serie de características. Los hijos de un proceso de un cgroup heredan la pertenencia a ese cgroup. Esto permite a *systemd* gestionar a nietos y biznietos con seguridad. Pero tengamos en cuenta que las propiedades configurables de los cgroups pueden ser cosas como límites de CPU, de memoria, de prioridad de disco...pues * systemd* tambien permite, ya de paso, que los servicios puedan configurar todas esas características. Por ejemplo, updatedb puede configurarse para usar una prioridad de disco baja. Hay mucho más que decir de este sistema: los tipos de archivos de configuración, o *units*, una UI para visualizar los servicios -escrita en Vala-, planes de una unit *timer* que sustituiría a cron, una unit *swap,*potencial reemplazo al menos de parte de la funcionalidad de los gestores de sesion de los escritorios (gnome-session/kdeinit), etc. Y varias funcionalidades avanzadas (por ejemplo, guardar el estado de los servicios en un momento dado, apagarlos todos, ir a un shell de emergencia, y regresar al estado anterior). El documento del proyecto es una lectura muy recomendable <http://0pointer.de/blog/projects/systemd.html>. Aun así, podemos decir que es, en principio, conceptualmente superior a *upstart*, y es muy fácil de migrar a él por no ser necesario reescribir scripts y crear nuevas dependencias. Dado que Poettering trabaja para Red Hat, no será sorprendente que Fedora lo adopte en futuras versiones. Escrito por: Diego Calleja -- Pablo Manuel Rizzo ------------------------------- http://pablorizzo.com -------------------------------