initctl: add a flag to make start/stop idempotent

[Clint Byrum]

It would be useful in scripts to simply be able to say

start job --ok-no-goal-change

Which would basically mean that if its already in a goal of 'start', just return 0. This is most useful in configuration management where one just wants to make sure the job is in a start or stop goal.

[Tv (tv42)]

For the benefit of others stumbling on this, here's my workaround:

status myjob VAR=val \
| {
  set -e
  read name goal_status rest
  case "$goal_status" in
    start/*)
      # no action needed
      ;;
    *)
      start myjob VAR=val
      ;;
  esac
}

[Tv (tv42)]

Except the case pattern there doesn't cope with instance ids in parens. That'd be easy to fix:

if ! status myjob VAR=val | grep -qE '^[^ ]+( \([^)]\))? start/'; then
  start myjob VAR=val
fi

except if the job is stopped, status will complain about "Unknown instance", so I ended up with this:

if initctl list|mawk '$1=="myjob" && $2=="(" INSTANCE ")" && $3~/start\// { exit 1 }' INSTANCE="$id"; then
  start myjob VAR="$id"
fi

Definite interface smell here..

[Guilhem Lettron (guilhem-fr)]

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

[Clint Byrum (clint-fewbar)]

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.