Slight, maybe problem.

[Scott James Remnant]

On Mon, 2006-11-13 at 21:13 +0100, Luka Renko wrote:

> On Monday 13 November 2006 03:53, Jerry Haltom wrote:
> > Since our event match tree is created when Upstart learns of a job, it
> > is only filled in from then on. If a new job is added, such as
> > installing Apache, the Apache job will be learned, but it will have
> > never heard from "network-up", and thus will be waiting for the network
> > to come up.
> 
> This is exactly what was discussed on upstart BOF in MtView: for "and" 
> conditions, we need to keep the state of event and evaluate the complete 
> condition on every change of state (or better event). In your example, newly 
> registered job (apache) would evaluate conditon of network-up that would be 
> cached in upstart. 
> 
The obvious problem here is that upstart would have to cache whether an
event has happened or not.  And while this is suitable for "from
network-up until network-down" stanzas, this would not be suitable for
"on control-alt-delete"

Also there's a majorly obvious problem...

while true; do
	initctl emit `uuidgen`
done

upstart will consume all available memory.


My inclination is that this is mostly necessary for those combinations
that indicate states, e.g.

	from fhs-up until fhs-down and network-up until network-down

That can be placed in /etc/event.d/multi-user ... then other jobs can
refer directly to it:

	with multi-user

This refer could be deliberately stateful, and non-event like, so that
it a mirroring of goals, rather than just an event trigger.

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20061113/8ab20f1e/attachment.pgp