Comment 2 for bug 862418

I think the prescribed mechanics are to error out some hook which will cancel the destruction of the service. I don't know if an error in the 'stop' hook would do this, but its currently the only one that runs before the service unit is taken down.

One can actually filter the debug-log, which might work.

juju debug-log --include 'servicename*'

Because of the async nature, whats probably needed is the ability to block until a state change that you would expect. So

juju destroy-service swift --wait-and-log

Which would wait for the state transition and show the debug-log for said service while waiting. This would actually make juju feel very interactive.