shell to machine in delayed-shutdown state

[pekof]

Fix bug #461
ssh_info returns connection data if machine is still running

[codecov]

Codecov Report

Merging #465 into master will decrease coverage by 0.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #465      +/-   ##
==========================================
- Coverage   66.65%   66.64%   -0.02%     
==========================================
  Files         141      141              
  Lines        5413     5414       +1     
==========================================
  Hits         3608     3608              
- Misses       1805     1806       +1

Impacted Files	Coverage Δ
src/daemon/daemon.cpp	23.72% <0%> (ø)	⬆️
include/multipass/virtual_machine.h	0% <0%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9428d15...b88cff6. Read the comment docs.

[Saviq]

Hey @pekof, thanks for this! Allowing shelling in is one thing, but we also need to cancel the shutdown timer, otherwise the machine will go down from under the user's feet.

[pekof]

@Saviq if you think that's necessary I will do it.

My only issue is what's use case for delayed stop if shell or exec would cancel it.
I can imagine that one user might want machine stopped in 30 minutes and connect to it in meantime.

[townsend2010]

@pekof, thanks for the contribution too!

The original reason we recommended cancelling the delayed shutdown was a case were snapcraft would do a build in a Multipass instance and then when it's done, it puts the instance in a delayed shutdown. At this point, a user shell's/exec's into the instance and does stuff and then all of a sudden, the instance is shutdown from underneath them.

However, after thinking about it, a user poking around a snapcraft instance is probably not the best thing to do and if they do, they are on their own. snapcraft is the true consumer of that instance and not the user.

So my recommendation is that the consumer of the instance should be the one to issue a multipass stop --cancel on the instance or the user who is subverting the consumer should be cognizant of what state the instance is in. Given that, shell and exec should not cancel a delayed shutdown.

[pekof]

@Saviq and @townsend2010 if I add commit that cancels delayed shutdown and you decide that that behavior is not desired you can still merge prior commit?
Or should I wait for decision?

[Saviq]

After chatting a bit I think we'll try and replicate the shutdown behaviour using wall to warn logged in users and preventing new shells and execs within a minute from shutdown or so.

We'll do this in a separate PR though.

bors r+

[townsend2010]

Hmm, let's try this again...
bors r=saviq

[bors]

Build failed

• continuous-integration/travis-ci/push