Diario de un indeciso... o no

lunes, agosto 28, 2006

Upstart: el sustituto de init en Ubuntu

Ayer Scott James, de Canonical Ltd., publicó un artículo explicando el nuevo sistema Upstart que reemplazará a init en Ubuntu (posiblemente en octubre). También se publicaba la noticia en Barrapunto.

Aquí va una traducción rápida del artículo (correcciones y sugerencias bienvenidas):

Upstart

Upstart será el futuro sustituto del demonio init: el proceso creado por el núcleo que se encarga de iniciar, supervisar y detener todos los demás procesos del sistema.

El demonio actual se basa en el del UNIX System V, por lo que se le conoce como sysvinit. Clasifica las tareas en diferentes “run levels” o niveles de ejecución, y puede ejecutar una tarea concreta cuando se entra en un determinado nivel de ejecución (e.g. /etc/init.d/rc 2) o continuamente durante todo el tiempo en que se permanezca en un mismo nivel (e.g. /sbin/getty).

El script /etc/init.d/rc también está basado en el del System V (y se encuentra en el paquete sysv-rc). Ejecuta los scripts de parada y posteriormente los de inicio, que hay en /etc/rcN.d (donde N es el nivel de ejecución) por orden numérico.

¿Por qué cambiarlo?

Ejecutar una serie fijada de scripts, uno tras otro, en un determinado orden nos ha funcionado razonablemente bien hasta ahora. No obstante, conforme Linux ha ido mejorando y adáptandose a los sistemas modernos (posiblemente el manejo de dispositivos desmontables es mejor en Linux que en Windows) este enfoque ha empezado a plantear problemas.

La antigua solución sólo funciona si garantizamos que en determinados instantes de la secuencia de arranque están disponibles ciertos recursos, por ello para que los scripts de init funcionen se deben ejecutar en puntos concretos de dicha secuencia. Normalmente se ordenan teniendo en cuenta que:

• Los discos duros deben haberse encontrado, iniciado y haber detectado sus particiones antes de que intentemos montarlas desde /etc/fstab.
• Los dispositivos de red deben haberse detectado e iniciado antes de que activemos los servicios de red.

Esto funcionaba hace diez años, ¿por qué ahora no? La respuesta breve es que nuestras computadoras se han vuelto mucho más flexibles:

• Los dispositivos pueden enchufarse y desenchufarse en cualquier momento, e.g. dispositivos USB.
• Los buses de almacenamiento aceptan un número variable de dispositivos, por lo que hay que explorar el bus. Esta operación no debe ser bloqueante.
• Para reducir el consumo eléctrico, las unidades de disco duro pueden dejar de girar hasta que se explore el bus, por lo que tardarán un tiempo mayor en aparecer.
• Los dispositivos de red pueden enchufarse y desenchufarse en cualquier instante.
• Puede que el firmware requiera ser escrito después de detectar el dispositivo, pero antes de que sea utilizable por el sistema.
• Montar una partición de /etc/fstab puede requerir que estén disponibles programas de /usr que no pueden utilizarse hasta que se configure la red si /usr está en un sistema de ficheros de red.

Hasta ahora hemos podido hackear el sistema para que gran parte de esto sea posible, pero el resultado es un conglomerado de bugs y condiciones de carrera ("race conditions"). Era hora de diseñar un sistema nuevo que pudiera enfrentarse a todas estas situaciones sin problemas.

Necesitábamos un sistema init que pudiera reordenar dinámicamente la secuencia de inicio basándose en la configuración y el hardware disponible en cada situación.

Diseño de upstart

Upstart es un demonio controlado por eventos. Los eventos generados por el sistema pueden iniciar una tarea y parar las que ya se están ejecutando. Los eventos pueden ser, entre otros:

• El sistema se ha iniciado.
• El sistema de ficheros raíz ya permite acceso de escritura.
• Un dispositivo de bloque se ha añadido al sistema.
• Se ha montado un nuevo sistema de ficheros.
• Un instante determinado o ciclos temporales periódicos.
• Otra tarea se ha iniciado o ha terminado.
• Un fichero ha sido modificado.
• Hay ficheros en una cola del sistema.
• Se ha detectado un dispositivo de red.
• El enrutamiento predeterminado ha sido añadido o eliminado.

De hecho, cualquier proceso del sistema puede enviar eventos al demonio init a través de su socket de control (cumpliendo ciertas restricciones, por supuesto) por lo que no hay ningún límite.

Cada tarea tiene un ciclo de vida como el que se muestra en la siguiente figura:

Los dos estados encuadrados en rojo (“en espera” y “ejecución”) son estados duraderos, en los que normalmente permanecerá una tarea hasta que se produzca un evento y lo pasemos al siguiente estado.

Los estados restantes son temporales (estados de tránsito). Permiten a una tarea lanzar scripts que preparen su ejecución (“iniciándose”) y cerrar y limpiarlo todo cuando termine (“parándose”). Los servicios que deban reiniciarse si llega un evento mientras está en estado de “ejecución”, pueden ejecutar scripts antes de que el proceso se inicie de nuevo (“reiniciándose”).

Las tareas abandonan un estado porque su proceso asociado termina (o se mata externamente) y avanzan hacia el estado siguiente, siguiendo la flecha verde si la tarea va a iniciarse o la roja si va a pararse. Cuando un script devuelve un valor de salida distinto de cero, o se ha matado externamente, la tarea siempre se parará. Cuando el proceso principal termina y la tarea no debe reiniciarse, también se parará siempre.

Tal y como se ha dicho, los eventos generados por el demonio init o enviados por otros procesos pueden provocar que las tareas se inicien o detengan. También pueden recibirse peticiones manuales para iniciar o parar una tarea.

La comunicación entre el demonio init y otros procesos es bidireccional, por lo que se puede solicitar el estado en el que se encuentran las otras tareas e incluso pueden recibirse los cambios de estado que se produzcan.

¿En qué se diferencia de launchd?

Launchd es el sustituto de init en MacOS X desarrollado por Apple como proyecto de “fuente abierta”. Su licencia no ha sido libre hasta hace poco y por lo tanto sólo nos habría sido de interés cuando Apple la cambió por una libre.

El objetivo de los dos sistemas es aparentemente el mismo: ambos inician tareas en función de los eventos del sistema. Sin embargo, launchd limita los eventos a:

• El arranque del sistema.
• Modificaciones de ficheros y envío de ficheros a colas.
• Un instante concreto (en sustitución de cron).
• Conexión en un puerto (en sustitución de inetd).

Por consiguiente, no nos permite solucionar directamente nuestros problemas: no podríamos montar sistemas de ficheros después de haberse producido el evento de “sistema de ficheros verificado”; no podríamos verificar los sistemas de ficheros cuando un dispositivo de bloque se añadiera; tampoco podríamos iniciar demonios después de que todo el sistema de ficheros (tal y como se especifica en /etc/fstab) estuviera disponible y con acceso de escritura.

Si una tarea no puede iniciarse, el modelo de launchd la obliga a que "se siente y espere" en vez de proporcionar un mecanismo para que la tarea sólo se inicie cuando no tenga que esperar. Las tareas que precisen que /usr esté montado tendrían que permanecer en un bucle, esperando hasta que /usr esté disponible antes de continuar (o utilizar un fichero en un sistema tmpfs para indicar que está disponible y usar dicha modificación como el evento).

Apple tiene pleno control tanto del hardware como del sitema operativo subyacente, por lo que en su caso este modelo no es descabellado. No tiene que preocuparse de la amplísima diversidad de sistemas y configuraciones que tenemos en el mundo de Linux.

En todo caso si la licencia de launchd hubiese sido lo suficientemente libre cuando iniciamos el desarrollo de upstart, probablemente lo habríamos extendido en vez de implementar otro sistema nuevo. Cuando Apple cambió la licencia, nuestro sistema ya se ajustaba mejor a nuestros objetivos que launchd.

¿En qué se diferencia de initng?

Initng es otro reemplazo de init desarrollado por Jimmy Wennlund para sustituir al sysvinit de Linux. Es un sistema basado en dependencias, mientras que upstart es un sistema basado en eventos.

En este punto sería interesante analizar el concepto de sistema basado en dependencias. Las tareas declaran sus dependencias de otras tareas que necesitan ejecutarse antes de que se inicie la propia tarea. Iniciar una tarea obliga a sus dependencias a iniciarse primero, y a las dependencias de aquellas, etc. Cuando una tarea se pare, las restantes tareas en ejecución que no tengan dependencias también pueden pararse.

Es una solución elegante al problema de ordenar una secuencia de arranque y al problema de reducir el número de procesos en ejecución al mínimo necesario.

Sin embargo, esto significa que tienes que tener unos objetivos en mente cuando arrancas el sistema: tendrías que haber decidido que quieres iniciar gdm para que tanto gdm como sus dependencias se inicien. Initng utiliza niveles de ejecución para implementarlo, siendo un nivel de ejecución una lista de tareas objetivo que deben ejecutarse en dicho nivel.

Tampoco está claro cómo interaccionan las dependencias con las distintas clases de tareas: una dependencia con Apache necesita que el demonio se mantenga en funcionamiento, mientras que una dependencia con "verificación del sistema raíz" necesita que el script de verificación ya haya terminado de ejecutarse. Upstart gestiona estas dos situaciones mediante distintos eventos (evento "ejecución de apache" y evento "checkroot parándose").

Aunque initng sea interesante, no soluciona los problemas que planteábamos. Puede reordenar un conjunto fijado de tareas, pero no puede determinar dinámicamente el conjunto de tareas que precisa un determinado arranque.

Un ejemplo podría ser un sistema en el que la tarea de configuración de la red no se haya configurado como objetivo de arranque sino como dependencia de la tarea de montaje de los sistemas de ficheros de red. En este caso, si la tarea de montaje fallase o no fuese un objetivo de arranque (e.g. porque no hubiese que montar ningún sistema de ficheros de red), el resultado sería que los dispositivos de red no se configurarían. Una solución podría ser definir todas las tareas como objetivos de arranque y dejar que el sistema utilizase las dependencias para determinar el orden de ejecución, pero esto es mucho menos eficiente que reordenar los scripts existentes en sysv-rc (lo que podría hacerse durante la instalación).

También podría darse el caso de que no se sepa si algo es una dependencia o no hasta después de leer otra configuración. Por ejemplo, el montaje de los sistemas de ficheros de red puede ser una dependencia de todo lo que haya en /usr o puede ser tan solo una dependencia de algo que permita al usuario iniciar su sesión si tan solo monta /home.

La diferencia entre los dos modelos puede resumirse en que initng empieza con una lista de objetivos y averigua cómo llegar a ellos, mientras que upstart empieza sin nada y averigua a dónde tiene que llegar.

¿En qué se diferencia del SMF de Solaris?

SMF es otro enfoque para sustituir a init desarrollado por Sun para su sistema operativo Solaris. Al igual que initng, es un sistema basado en dependencias, por lo que ya se han comentado las diferencias entre dichos sistemas y upstart.

El objetivo principal de SMF es administrar los servicios, asegurando que una vez que estén en funcionamiento, lo seguirán estando, así como permitir al administrador del sistema conocer y modificar los estados de las tareas del sistema.

A este respecto, upstart ofrece las mismas funcionalidades: los servicios pueden reiniciarse si fallan y los administradores del sistema pueden conocer el estado en el que se encuentran los servicios en cualquier momento y además modificar su estado según sus propias necesidades.

¿Reemplazará a cron, inetd, etc?

La finalidad de upstart es reemplazar a todos estos demonios, de manera que sólo haya un lugar (/etc/event.d) en el que los administradores del sistema tengan que configurar cuándo y cómo se ejecutan las tareas.

De hecho, el obejtivo es que upstart también sustituya a los "scripts de ejecución de eventos" de todos los demonios del sistema. Demonios tales como acpid, apmd y el Gestor de red enviarían eventos a init en vez de ejecutar sus propios scripts con su configuración y semántica particulares.

Un administrador del sistema que lo único que quiera es que se ejecute un determinado demonio mientras su portátil se encuentre alimentado por CA, sólo tendría que editar /etc/event.d/daemon y cambiar “on startup” por “on ac power”.

¿Qué pasa con la compatibilidad?

Hay muchos administradores de sistemas que ya están acostumbrados al funcionamiento de Linux y no querrán aprender otra vez de nuevo. También hay una ingente cantidad de libros sobre el software actual y no se ocuparán de upstart hasta dentro de unos años.

Por este motivo, la compatibilidad es muy importante. Upstart continuará ejecutando los scripts actuales en el futuro cercano, de manera que los paquetes no tendrán que actualizarse hasta que sus autores lo estimen oportuno.

También se implementarán herramientas compatibles para la línea de órdenes, que se comportarán igual que sus equivalentes actuales. Un administrador de sistemas nunca necesitará saber que crontab -e en realidad está cambiando tareas de upstart.

¿Utiliza D-BUS?

“Para la gente de D-BUS, D-BUS lo soluciona todo.”
—Erik Troan

La filosofía de UNIX es que algo debe hacer únicamente una cosa, y hacerla bien. La función de upstart es iniciar, supervisar y parar otras tareas; la función de D-BUS es el intercambio de mensajes entre tareas.

D-BUS ofrece un mecanismo para que los servicios se activen cuando se les pase el primer mensaje, y por lo tanto puede iniciar tareas. Hay quien apoyándose en esta idea ha sugerido que todo de lo que un sustituto de init debería encargarse es de registrar tareas con D-BUS y gestionar el arranque del sistema como una simple cuestión de intercambio de mensajes.

Personalmente me parece un enfoque erróneo. Habría que ampliar D-BUS para que supervise estos servicios, les ofrezca mecanismos para reiniciarse y pararse, así como ocuparse de ser el proceso #1, lo que implica reorganizar y hacer limpieza cuando un proceso padre muera dejando a sus hijos huérfanos, etc. Parece mucho más sencillo adaptar D-BUS para enviar un evento a init cuando haya que iniciar un servicio, y centrarse en ser un excelente sistema de intercambio de mensajes.

Los mecanismos de IPC (Inter-Process Communication) que utiliza upstart no usan D-BUS por diversos problemas. No obstante, siempre se ha dado por supuesto que incluso si el mismo init no se comunicase con D-BUS directamente, habría un proxy para D-BUS que se encargaría de que los mensajes de todas las tareas de init y sus eventos se envíen a D-BUS y de que los clientes D-BUS puedan enviar mensajes a init para leer y cambiar el estado de las tareas.

¿Cómo se ha planificado su implementación?

Dado que lo que estamos modificando es el proceso #1, queremos estar seguros de que lo hacemos bien. Por lo tanto en lugar de publicar un demonio lleno de funcionalidades y totalmente configurable, lo haremos en las siguientes etapas:

1. Desarrollo principal: al final de esta etapa el demonio se ha implementado y puede administrar las tareas como se ha descrito.
2. Sustitución de /sbin/init pero ejecutando los actuales scripts de sysv-rc. Esta es la prueba de fuego del demonio. ¿Podrá desempeñar la misma función que el actual demonio sysvinit sin ninguna regresión?
3. Sustitución de los scripts de /etc/rcS.d por las tareas de upstart. Esto constituye la mayoría de tareas necesarias para arrancar el sistema en modo monousuario y contempla muchos de los actuales problemas de ordenación y condiciones de carrera. Si el demonio soluciona estos problemas, será un éxito.
4. Sustitución de los scripts de otros demonios por tareas de upstart revisando paquete por paquete. Esto requerirá un esfuerzo considerable durante el cual upstart continuará ejecutando los scripts actuales de sysv-rc a la vez que sus propias tareas. Durante esta etapa el sistema de eventos puede retocarse para garantizar que soluciona los problemas que nos hacen falta.
5. Sustitución de cron, atd, anacron e inetd. Esta etapa progresará paralelamente a la anterior y concluirá con un único lugar para configurar las tareas del sistema.
6. Modificación de otros demonios y procesos para que envíen eventos a init en vez de intentar ejecutar procesos ellos mismos.

Nuestro propósito actual es llegar al menos a la etapa #3 en el momento en que se publique edgy, para distribuirla con upstart como el demonio de inicio y ejecutando con él los scripts más críticos de rcS, para corregir los problemas más importantes.

Para edgy+1 esperamos haber completado hasta la etapa #5 y estar cerca de completar la #6. Desde el inicio del desarrollo de edgy+2, no se aceptará ningún paquete nuevo a menos que incluya tareas para upstart en lugar de scripts para init. Los scripts para init se considerarán obsoletos.

¿En qué estado está actualmente?

El demonio init ya se ha implementado y es capaz de administrar las tareas como se ha descrito anteriormente, recibiendo eventos en el socket de control para iniciarlas y pararlas. Se han subido a Ubuntu universe en el paquete upstart para probarlo antes de que sea el demonio de inicio predeterminado.

Estaremos muy agradecidos a todos los usarios experimentados que quieran ayudar a probarlo. Instala el paquete y sigue las instrucciones de /usr/share/doc/upstart/README.Debian para añadir una opción de arranque que utilice upstart en lugar de init. Si tu sistema arranca y se apaga con normalidad (a excepción de un arranque algo más verboso y sin ejecutar usplash) entonces funciona correctamente.

Otras clases de eventos se irán añadiendo durante la fase de desarrollo y prueba conforme sean necesarios. Actualmente tan sólo se ha desarrollado una herramienta cliente básica (initctl), mientras que otras herramientas de compatibilidad como shutdown comenzaremos a desarrollarlas la semana próxima o la siguiente, antes de que sustituyan al paquete sysvinit.

Original: © 2006 Scott James Remnant. Content distribution licence.
Traducción: © 2006 Miguel Abad Pérez. Creative Commons Licence.

Etiquetas: gnu/linux

Publicado por un indeciso a las 03:35