When refreshing the core snap, I noticed that it never seems to finish the update until the 10 minute timer expires and forces the reboot. Because of this, control is never returned to the user, or in my case, the calling script. Because this is something I’m using for some automated tests, I want to have a little more control over when the system reboots, so that I can refresh multiple snaps, then force the reboot and wait for the system to come back. But because of this long delay in the core snap without ever returning control, it gets part way through the list of commands to run over ssh and then times out until reboot - then the subsequent ssh commands fail because it’s unexpectedly down.
It also seems that once it hits this point, any other attempt to ssh to the system fails.
Is there any reason why the core snap behaves this way? Is something blocking it from completion, or is it just really taking longer than 10 minutes to finish the refresh?
FWIW we are using the same infrastructure to run part of our tests and the test cases that involve a core refresh or revert work consistently well if we take the following approach:
Run the refresh/revert command that will result in a reboot in a separate job step: this step connects to the testbed, runs the eventually hanging command and keeps the connection open for about 10min until the testbed reboots, when the connection is broken.
Run the rest of your commands as spread tasks in the next job step: spread takes care of waiting for the connection to be up.
As an example of this, during the core validation at beta we run a test scenario in which we begin from a stable image, then refresh core to beta and then run the full test suite. This is the job definition: http://paste.ubuntu.com/24645545/ (we call refresh on line 9 and right after spread on line 10) and these are the results: https://paste.ubuntu.com/24633121/ (the reboot takes place around line 5320 and the job continues with a refreshed image), this job has been consistently working for the last three releases, four executions in each release.
This is by no means a solution to the underlying problem, but if you can layout your tests in this way it will work after the final solution is in place, please let me know if you need any help wrapping your test actions in spread tasks.
