Excerpts from Guilhem Lettron's message of Mon May 21 13:45:13 UTC 2012: > to bypass this limitation, you can use upstart event. more information > http://netsplit.com/2010/12/03/event-matching-in-upstart/ > > An example : > https://github.com/Youscribe/ceph/commit/66d0027229921e411600bb7900d713c917cb2c9b >
Right, to be clear though, that requires that you have control of both the thing which wants the job started, and the job itself.
If you only want to ensure that a job, unmodified, is started, you still have to deal with the lack of idempotency in the start/stop commands.
You can also work around it with the 'wait-for-state' job that was added in Ubuntu 11.10, which actually is idempotent:
start wait-for-state WAITER=`date` WAIT_FOR=job-to-start TARGET_GOAL=start
This will simply return immediately if the job is already started, or will wait for the job to start completely (just like the start command) if it is not.
I still think this bug needs to be fixed though, as these are all just workarounds.
Excerpts from Guilhem Lettron's message of Mon May 21 13:45:13 UTC 2012: netsplit. com/2010/ 12/03/event- matching- in-upstart/ /github. com/Youscribe/ ceph/commit/ 66d0027229921e4 11600bb7900d713 c917cb2c9b
> to bypass this limitation, you can use upstart event. more information
> http://
>
> An example :
> https:/
>
Right, to be clear though, that requires that you have control of both
the thing which wants the job started, and the job itself.
If you only want to ensure that a job, unmodified, is started, you still
have to deal with the lack of idempotency in the start/stop commands.
You can also work around it with the 'wait-for-state' job that was added
in Ubuntu 11.10, which actually is idempotent:
start wait-for-state WAITER=`date` WAIT_FOR= job-to- start TARGET_GOAL=start
This will simply return immediately if the job is already started, or
will wait for the job to start completely (just like the start command)
if it is not.
I still think this bug needs to be fixed though, as these are all just
workarounds.