cloud-init

Cannot determine boot-finished state reliably

Bug #1258113 reported by Robie Basak on 2013-12-05

This bug affects 4 people

Affects		Status	Importance	Assigned to	Milestone
	cloud-init	Expired	Medium	Unassigned

Bug Description

From outside an instance, ssh becomes available before cloud-init is done. If I ssh in, I'd like to be able to automatically wait until cloud-init has finished, so as not to collide with anything it is doing.

I'd like to be able to do this independently of any userdata. I think this makes for a cleaner separation between components, and makes everything easier to develop and test. For example, I'ld like uvtool to allow the user to completely override everything that is passed through to cloud-init, but for uvtool to still be able to detect when the instance is ready "from the outside". This is why I don't like the idea of having to make my own arrangement for this via userdata.

/var/lib/cloud/instance/boot-finished works, but only for the first boot, since it is persistent. Another point of unreliability is if somebody boots a machine in order to modify it, shuts it down, and then clones it. In this case, each clone has a boot-finished file before it has started booting.

We discussed doing something in /run instead.

I can't think of any other mechanism that can be used "from the outside", independent of userdata, that is not horribly obtuse or racy.

Could whatever we end up doing please be added in time for Ubuntu Trusty, so that tools that boot Trusty images will be able to use it? Otherwise we'll need to wait another two years I think. Thanks!

Revision history for this message

Scott Moser (smoser) wrote on 2014-01-14:

We can make final_modules write a marker file in /run.
I think jst adding a different 'final-marker' module (cc_final_marker) would be best.

We cna make it write to /run/cloud-init/finished.
and also try to figure out how we can make it mark "all passed" or some indication of pass/failed there too.

patches are most definitely welcome.

Changed in cloud-init:
status:	New → Triaged
importance:	Undecided → Medium

Revision history for this message

Thomas Bechtold (toabctl) wrote on 2015-04-13:

I think the bug is done. See http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/status.txt for description howto check if cloud-init run finished.

Revision history for this message

Robie Basak (racb) wrote on 2015-04-13:

That looks good - thanks!

I have one more related request that I didn't think of when I originally wrote this report. I'd like to be able to detect that an installed system _will_ write to the new path in /run if nothing is there right now, so that I can detect when I can wait for that file and when I must fall back to my previous hacks. Maybe a test for a file, or a way to run --version against something? dpkg-query seems a bit too Debian/Ubuntu -specific to me. Is running "cloud-init --version" acceptable to use with a no API breakage guarantee?

Alternatively any other way to fix my hack so detection works for both cloud-init with this new feature and on old releases using older cloud-init using the same script in both cases would be fine.

Right now my hack looks like this: http://bazaar.launchpad.net/~uvtool-dev/uvtool/trunk/view/head:/remote-wait.sh

No rush as I won't try and make Vivid for this since the current hack works OK. I can fix this next cycle though.

Revision history for this message

Vincent Legoll (vincent-legoll) wrote on 2016-12-08:

Is this bug finished, I skimmed through the doc, but did not find the way I should check for c-i to be done.

Did I miss it ?

Revision history for this message

James Falcon (falcojr) wrote on 2023-05-10:

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2416