Muy interesante: systemd otro reemplazo de init
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 -------------------------------
On Tuesday 04 May 2010 00:05:30 Pablo Manuel Rizzo wrote:
systemd, otro reemplazo de init<http://diegocg.blogspot.com/2010/05/systemd-otro-reemplazo-de-init.htm l>
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
Todo bien Suena fantástico pero qué perdido que estaré cuando cambie todo eso :S -- Marcos Guglielmetti ▲ :::::::::::::::::: M U S I X ::::::::::::::::::::: ▼ www.musix.org.ar www.ovejafm.com ▲ :::::::::::::::::: O V E J A ::::::::::::::::::::: ▲ _______________________________________________ La lista solar-general es un canal de comunicación de SoLAr por el libre intercambio de ideas de todos los interesados en el movimiento de software libre. Debido a su libre suscripción y publicación, y dado que no existe ningún tipo de moderación previa ni posterior, es un excelente lugar para compartir opiniones, elaborar políticas y prácticas por el Software Libre en Argentina y el mundo. Tal como dice en ourproject: "La lista de todos y todas en solar" http://ourproject.org/mail/?group_id=23 Te invitamos a subscribirte enviando un mail a [email protected] ¡Asociate a SOLAR!: http://www.solar.org.ar/?article573 * por la restauración del historial de solar-socios (dejó de funcionar el 25 de nov de 2009) * por la apertura del sitio solar.org.ar y de solar-socios para todo el movimiento * por el fin de la censura contra el compañero Saravia y contra todos los compañeros * por el fin de las mociones represivas que generan malestar entre los miembros * por la inmediata reincorporación de cualquier socio del movimiento SL expulsado * por la reapertura de solar-general y del wiki.solar.org.ar * por la discusión de principios para ampliar la participación http://musix.org.ar/wiki/index.php/Principios_participativos
2010/5/4 Marcos Germán Guglielmetti <[email protected]>
On Tuesday 04 May 2010 00:05:30 Pablo Manuel Rizzo wrote:
systemd, otro reemplazo de init< http://diegocg.blogspot.com/2010/05/systemd-otro-reemplazo-de-init.htm l>
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).
Todo bien
Suena fantástico
pero qué perdido que estaré cuando cambie todo eso :S
Por lo que dice ahí parece ser mas simple que init en su uso -- Pablo Manuel Rizzo ------------------------------- http://pablorizzo.com -------------------------------
2010/5/4 Marcos Germán Guglielmetti <[email protected]>
On Tuesday 04 May 2010 00:05:30 Pablo Manuel Rizzo wrote:
systemd, otro reemplazo de init< http://diegocg.blogspot.com/2010/05/systemd-otro-reemplazo-de-init.htm l>
Todo bien
Suena fantástico
pero qué perdido que estaré cuando cambie todo eso :S
Por lo que dice ahà parece ser mas simple que init en su uso
en arch ponemos todos los servicios en un array de bash en el orden que queremos y con una @arroba adelante para iniciarlos en paralelo :p --
2010/5/4 Pablo Manuel Rizzo <[email protected]>
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.
¡Excelente!. [Lo siguiente es arqueología informática, y no tiene que ver con el Software Libre, pero viene a cuento como anécdota] Ironicamente, en OS/2 Warp 4.0, una gran causa de "lentitud de booteo" era que apenas cargado el entorno gráfico (PMShell), pasaba a cargar todo lo que esta en el Startup folder (en Windows pasa lo mismo), lanzando en 4 segundos unas 7 u 8 aplicaciones que pasaban a competir por el acceso a disco para terminar de cargarse. Si estuvieramos hablando de una máquina con RAMdisk o SSD, es una cosa, pero en un disco rígido por el seek time únicamente (el cabezal no puede estar en 2 sitios al mismo tiempo), el sumar varias lecturas de archivos en paralelo logra enlentecer geométricamente la operación. Por eso, había encontrado una solución que disminuía el tiempo de booteo a la mitad: simplemente cronometré cuantos segundos tardaba en cargar cada programa en el booteo, y en lugar del S.O: llamar a uno tras otro inmediatamente (lo que causaba el cuello de botella en la lectura desde disco), lo que hice fué cargar todo mediante startup.cmd, pero esta vez poniendo una demora de "x" segundos entre uno y otro, donde "x" era el tiempo exacto que tardaba en cargar el programa desde disco. entonces se cargaba uno tras otro secuencialmente, pero solo se cargaba el programa #2 una vez que el #1 ya estaba cargado por completo y no necesitaba mas acceso a disco. En fin... la moraleja es que hoy día, ningún Windows cuenta con tal funcionalidad... todos continuan llamando a todo lo que exista en la carpeta de inicio, al mismo tiempo, ocasionando un tremendo cuello de botella en la lectura de disco y el clásico "cuando terminará de bootear esta carreta". Los gigas de RAM y los discos ultrarápidos solo enmascaran el problema... Bueno, eso... recuerdos. :) Pero no demos ideas antes de que Microsoft patente la carga demorada de aplicaciones al inicio. ;-) FC
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 -------------------------------
________________________________________________
Solar-General es una lista abierta a toda la comunidad, sin ninguna moderación, por lo que se apela a la tolerancia y al respeto mutuo. Las opiniones expresadas son responsabilidad exclusiva de sus respectivos/as autores/as. La Asociación Solar no se hace responsable por los mensajes vertidos, ni representan necesariamente el punto de vista de la Asociación Solar.
[email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-general
-- "Me gustaría vivir un tiempo razonable. Qué se yo, mil, dos mil años". -Ernesto Sábato
On Tuesday 04 May 2010 06:47:56 Fernando Cassia wrote:
2010/5/4 Pablo Manuel Rizzo <[email protected]>
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.
¡Excelente!.
[Lo siguiente es arqueología informática, y no tiene que ver con el Software Libre, pero viene a cuento como anécdota]
Ironicamente, en OS/2 Warp 4.0, una gran causa de "lentitud de booteo" era que apenas cargado el entorno gráfico (PMShell), pasaba a cargar todo lo que esta en el Startup folder (en Windows pasa lo mismo), lanzando en 4 segundos unas 7 u 8 aplicaciones que pasaban a competir por el acceso a disco para terminar de cargarse.
Si estuvieramos hablando de una máquina con RAMdisk o SSD, es una cosa, pero en un disco rígido por el seek time únicamente (el cabezal no puede estar en 2 sitios al mismo tiempo), el sumar varias lecturas de archivos en paralelo logra enlentecer geométricamente la operación.
Por eso, había encontrado una solución que disminuía el tiempo de booteo a la mitad: simplemente cronometré cuantos segundos tardaba en cargar cada programa en el booteo, y en lugar del S.O: llamar a uno tras otro inmediatamente (lo que causaba el cuello de botella en la lectura desde disco), lo que hice fué cargar todo mediante startup.cmd, pero esta vez poniendo una demora de "x" segundos entre uno y otro, donde "x" era el tiempo exacto que tardaba en cargar el programa desde disco. entonces se cargaba uno tras otro secuencialmente, pero solo se cargaba el programa #2 una vez que el #1 ya estaba cargado por completo y no necesitaba mas acceso a disco.
En Musix 1.0 hice una pavada así para arrancar las aplicaciones de escritorio sin que el tiempo de lectura del CD fuera terriblemente hinchabolas. (y el CD sabemos que es mucho más molesto que el HD)
En fin... la moraleja es que hoy día, ningún Windows cuenta con tal funcionalidad... todos continuan llamando a todo lo que exista en la carpeta de inicio, al mismo tiempo, ocasionando un tremendo cuello de botella en la lectura de disco y el clásico "cuando terminará de bootear esta carreta". Los gigas de RAM y los discos ultrarápidos solo enmascaran el problema...
Bueno, eso... recuerdos. :)
Pero no demos ideas antes de que Microsoft patente la carga demorada de aplicaciones al inicio. ;-)
FC
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 -------------------------------
________________________________________________
Solar-General es una lista abierta a toda la comunidad, sin ninguna moderación, por lo que se apela a la tolerancia y al respeto mutuo. Las opiniones expresadas son responsabilidad exclusiva de sus respectivos/as autores/as. La Asociación Solar no se hace responsable por los mensajes vertidos, ni representan necesariamente el punto de vista de la Asociación Solar.
[email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/solar-general
-- Marcos Guglielmetti ▲ :::::::::::::::::: M U S I X ::::::::::::::::::::: ▼ www.musix.org.ar www.ovejafm.com ▲ :::::::::::::::::: O V E J A ::::::::::::::::::::: ▲ _______________________________________________ La lista solar-general es un canal de comunicación de SoLAr por el libre intercambio de ideas de todos los interesados en el movimiento de software libre. Debido a su libre suscripción y publicación, y dado que no existe ningún tipo de moderación previa ni posterior, es un excelente lugar para compartir opiniones, elaborar políticas y prácticas por el Software Libre en Argentina y el mundo. Tal como dice en ourproject: "La lista de todos y todas en solar" http://ourproject.org/mail/?group_id=23 Te invitamos a subscribirte enviando un mail a [email protected] ¡Asociate a SOLAR!: http://www.solar.org.ar/?article573 * por la restauración del historial de solar-socios (dejó de funcionar el 25 de nov de 2009) * por la apertura del sitio solar.org.ar y de solar-socios para todo el movimiento * por el fin de la censura contra el compañero Saravia y contra todos los compañeros * por el fin de las mociones represivas que generan malestar entre los miembros * por la inmediata reincorporación de cualquier socio del movimiento SL expulsado * por la reapertura de solar-general y del wiki.solar.org.ar * por la discusión de principios para ampliar la participación http://musix.org.ar/wiki/index.php/Principios_participativos
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.
je, exactamente como le estaba poniendo a ututo 2.0, de hecho de eso hable en un encuentro regional en uruguay hace mucho tiempo. despues no tuve tiempo de seguir con eso -- Diego Saravia [email protected] NO FUNCIONA->[email protected]
participants (5)
-
Diego Saravia -
Fernando Cassia -
Marcos Germán Guglielmetti -
Nicolás Reynolds -
Pablo Manuel Rizzo