Cannot determine boot-finished state reliably

[ubuntu-server-builder]

This bug was originally filed in Launchpad as LP: #1258113

Launchpad details

affected_projects = []
assignee = None
assignee_name = None
date_closed = None
date_created = 2013-12-05T11:36:30.833790+00:00
date_fix_committed = None
date_fix_released = None
id = 1258113
importance = medium
is_complete = False
lp_url = https://bugs.launchpad.net/cloud-init/+bug/1258113
milestone = None
owner = racb
owner_name = Robie Basak
private = False
status = triaged
submitter = racb
submitter_name = Robie Basak
tags = []
duplicates = []

Launchpad user Robie Basak(racb) wrote on 2013-12-05T11:36:30.833790+00:00

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!

[ubuntu-server-builder]

Launchpad user Scott Moser(smoser) wrote on 2014-01-14T17:25:34.674932+00:00

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.

[ubuntu-server-builder]

Launchpad user Thomas Bechtold(toabctl) wrote on 2015-04-13T13:55:30.180277+00:00

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.

[ubuntu-server-builder]

Launchpad user Robie Basak(racb) wrote on 2015-04-13T16:24:00.754674+00:00

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.

[ubuntu-server-builder]

Launchpad user Vincent Legoll(vincent-legoll) wrote on 2016-12-08T13:53:54.462061+00:00

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 ?

[holmanb]

The current portable way to do this is cloud-init status --wait. Be sure to check error status. Exit code of 1 means cloud-init completely failed. Exit code of 2 means that cloud-init succeeded but experienced some error that didn't cause cloud-init to fail.