Comment 1 for bug 1173224

The current behaviour is in fact as intended; error states are intended to prevent a unit from doing anything until a human has solved the problem that juju considers intractable. This is done with `juju resolved`, which indicates to juju that you have yourself completed the task that juju failed to do. This would of course be a bare-faced lie, and wouldn't help the next hook's chances of success much, but by repeatedly resolving errors without looking you can assist a dying unit to its eventual suicide.

In this specific case -- a failure on install -- I think it would be reasonable for the unit to be removed directly when it was destroyed; and it is probably reasonable to do so at any point up to the successful completion of the start hook; but once that's run, we really ought to be running a stop hook before shutting the unit down. And once it's joined relations the question is harder still; so we err on the side of safety, and ask for interventions whenever we're unsure. So I have two proposals to address the near and far terms:

1) destroy-unit on a unit that has not run its "start" hook should remove the unit directly regardless of error state.

2) destroy-unit --force on a unit that has run its "start" hook should cause it to run all hooks necessary for it to disengage, but to ignore error states and continue blindly on through "stop" to death.

Would either, or both, address your needs?