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?
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 local-machine- agent main process ended, respawning
Jun 22 07:03:21 rf kernel: [74141.429782] init: juju-neal-
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?