Sean,
Thanks for the suggestion of handling SIGTERM. I wasn't sure it would work, but in testing it does seem to.
I've verified that it works by booting a system, and looking in /var/log/dmesg. You'll see something like:
$ grep "init:.*cloud-init.*kill" /var/log/dmesg
[ 13.207358] init: cloud-init-nonet main process (679) killed by TERM signal
After this commit, you wont see that any more. I was confused as to whether or not it would fix it as it was unclear if the message was stating that upstart was *sending* a kill to the given process, or that that process had been killed by TERM.
It appears to be the latter.
Also, now we'll see something this on console output:
cloud-init start-local running: Mon, 04 Mar 2013 19:32:27 +0000. up 3.02 seconds
no instance data found in start-local
cloud-init-nonet[3.95]: waiting 10 seconds for network device
cloud-init-nonet[13.95]: waiting 120 seconds for network device
cloud-init-nonet[22.00]: static networking is now up
Sean, *cloud- init.*kill" /var/log/dmesg
Thanks for the suggestion of handling SIGTERM. I wasn't sure it would work, but in testing it does seem to.
I've verified that it works by booting a system, and looking in /var/log/dmesg. You'll see something like:
$ grep "init:.
[ 13.207358] init: cloud-init-nonet main process (679) killed by TERM signal
After this commit, you wont see that any more. I was confused as to whether or not it would fix it as it was unclear if the message was stating that upstart was *sending* a kill to the given process, or that that process had been killed by TERM.
It appears to be the latter.
Also, now we'll see something this on console output: init-nonet[ 3.95]: waiting 10 seconds for network device init-nonet[ 13.95]: waiting 120 seconds for network device init-nonet[ 22.00]: static networking is now up
cloud-init start-local running: Mon, 04 Mar 2013 19:32:27 +0000. up 3.02 seconds
no instance data found in start-local
cloud-
cloud-
cloud-