Comment 9 for bug 1006553

Thanks, Clint - makes sense, though I wonder how we'll configure services that need to restart on reboot.

For the record, here are some more kern.log messages, which accompanied the strace that I talked about before, and give some more background on why the cpu calmed down.

Jun 22 07:03:21 rf kernel: [74141.409402] init: juju-neal-local-machine-agent main process (1100) killed by TRAP signal
Jun 22 07:03:21 rf kernel: [74141.429782] init: juju-neal-local-machine-agent main process ended, respawning

Based on the respawn, I guess it may come back, so instructions geared to any newbies who run across this bug on how to most easily destroy the environment would help. I tried to dig up what I had done in my testing via the status command, but it doesn't help:

$ juju status
could not connect before timeout
2012-06-22 18:04:00,125 ERROR could not connect before timeout

I can't run 'juju destroy-service' without knowing what service I started ;) So e.g. how can we figure that out?