I had the same error as you did, and got an unresponsive canister which when I tried to dfx canister --network ic install --mode reinstall <canister>, I could get the successful reinstall but still not get my canister to work correctly (it was a frontend canister which had a large file I thought I deleted but was put back with a commit from my teammate). I then went to NNS where I made this canister. I then detached it assuming I would get the cycles back but did not. I thus have some questions:
Q1 → Could someone please tell me how I can get my cycles back? Or if this is at all possible?
Q2 → How do I switch off another one of my canisters? I have two canisters currently running and deployed on ic (just backend Motoko). How can I do this without losing control of the canister as well as my cycles? Note I have two principals on all the canisters I made (I made 3 of them initially). I never remove my principals, as I wish to control all from the terminal. These two backend canisters are not giving me problems, but I refactored them to operate as a single canister so I don’t need the other ic canister. Any advice would be appreciated. Thanks in advance.
To get cycles out of a canister you’re deleting, you have to withdraw them before you delete the canister. This is why dfx canister delete takes so long: it first installs a cycles wallet wasm into the canister-to-be-deleted, withdraws (almost) all cycles, stops the canister, and then deletes it.
If you’re still a controller of the canister and haven’t lost the ID, you can run dfx canister delete on it and it’ll do the whole withdrawal process to your cycles wallet.
Does dfx canister stop fit your use case? This will make the canister unresponsive, but you’ll also not have to pay for update call costs.
1 Like
Thanks for the reply.
I did this initially to get my cycles back but always got errors including the following error (i tried again now and got the same):
Error: Encountered an error while trying to fetch the root key.
Caused by:
An error happened during communication with the replica: error sending request for url (http://127.0.0.1:8000/api/v2/status): error trying to connect: tcp connect error: Connection refused (os error 111)
Actually I should mention before I detached that canister (I was silly and frustrated), i exhausted all the dfx canister commands stop, uninstall-code, request-status, delete, update-settings. Do I need to have the local replica running when interacting with the ic? I normally can interact with my other working canisters on ic without the local running.
After the call to dfx canister stop <working canister> , how would I get this canister up again should I choose to do so? Could I perhaps transfer my cycles to another canister (say from y to x) since x will be doing the job of (x+y) canister going forward? Thanks again for your insights and speedy replies.
This means you’re trying to connect to the local replica and it’s not running. dfx canister --network ic stop will talk to the real IC.
dfx canister (maybe --network ic) start will do the reverse of stop.
Yes, but you need some way to send the cycles. You do this by calling some code in the canister that attaches cycles to a message. If you just want to decommission canister y, it’s probably easiest to stop it, then dfx canister delete y (which will withdraw the cycles to your cycles wallet) and then send the cycles from your wallet to x.
I’m an idiot, of course this it why its not working … hehe 
Me standing too close to an elephant thinking its a mountain.
OK, thanks I see, this makes perfect sense to stop then delete. Thanks I will give it a go.
Cheers for the help!!
1 Like