multiple instances of the same script?

[paul]

Thanks Scott,

The "instance" stanza does solve this for me (I am running upstart 
0.3.7). My second block device gets checked and the partition on this 
gets mounted.

Paul

Scott James Remnant wrote:
> On Sat, 2007-03-10 at 14:13 +0100, paul wrote:
>
>   
>> Can multiple instance of the same script run at the same  time?
>>
>>     
> Yes.
>
> As you've noted, this isn't the default behaviour because the "one copy
> of one job running at one time" behaviour turns out to be more useful
> for most cases; especially since it provides free locking for cron
> replacement later on, etc.
>
> Since 0.3.5, Upstart has also supported having jobs that may have
> multiple copies running at any one time; I would recommend 0.3.7 though,
> since that massively improves the initctl tool's handling of them.
>
> Such jobs (where multiple instances may be running at any one time) can
> be declared by using the "instance" stanza in the job definition.
>
> Example:
>
> 	start on block-device-added
>
> 	instance
>
> 	script
> 	    ...
> 	end script
>
> Now every time the start event happens, or a manual start is attempted,
> a new instance will be created and that will run.  Such jobs are
> expected to handle interlocking between each other themselves.
>
> Example:
>
> 	# status --show-ids foo
> 	foo [#100] (instance)
>
> 	# start --show-ids foo
> 	foo [#123] (start) waiting
> 	foo [#123] (start) starting
> 	  :
>
> 	# start --show-ids foo
> 	foo [#124] (start) waiting
> 	foo [#124] (start) starting
>
> 	# status --show-ids foo
> 	foo [#100] (instance)
> 	    [#123] (start) running, process 54321
> 	    [#124] (start) running, process 56789
>
> 	# status --show-ids --by-id 123
> 	foo [#123] (start) running, process 54321
>
> Notice how the new instances have a different id to the primary one, but
> the same name.  The primary job can never be anything other than
> stop/waiting since attempting to start it always spawns a new instance.
>
> Running "stop foo" would stop all instances of it; you can stop
> individual instances by their id.
>
>
> There's future plans for a possible "watershed" variety on this.
> Watershed jobs wouldn't spawn new instances whenever the event occurred,
> instead they would simply recognise that they need to be respawned after
> they have stopped.
>
> This is useful for where the task being run is expensive, and it's only
> necessary to run it if there was any change since the last time it was
> started -- and not for each event.
>
> Scott
>