cloud-init-nonet main process killed by TERM signal

Bug #1015223 reported by Scott Moser on 2012-06-19
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cloud-init (Ubuntu)
upstart (Ubuntu)

Bug Description

it has been reported in maas (and i think i've seen it other places) that the console may include:
  init: cloud-init-nonet main process (307) killed by TERM signal

This message is scary to users, even though it is not fatal or even an indication of a problem.

It occurs because the cloud-init-nonet's purpose in life is to block the running of cloud-init until the network devices are up. when upstart recognizes that 'static-network-up' it kills cloud-init-nonet, which allows cloud-init to start.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: cloud-init 0.6.3-0ubuntu1
ProcVersionSignature: User Name 3.2.0-25.40-virtual 3.2.18
Uname: Linux 3.2.0-25-virtual x86_64
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
Date: Tue Jun 19 17:41:24 2012
Ec2AMI: ami-b2288bdb
Ec2AMIManifest: ubuntu-us-east-1/images-testing/ubuntu-precise-daily-amd64-server-20120616.manifest.xml
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: m1.small
Ec2Kernel: aki-825ea7eb
Ec2Ramdisk: unavailable
PackageArchitecture: all
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Scott Moser (smoser) wrote :
Scott Moser (smoser) on 2012-06-19
Changed in cloud-init (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Scott Moser (smoser) on 2012-06-19
description: updated
Clint Byrum (clint-fewbar) wrote :

I'm adding an upstart task. I'm wondering if its even valid for upstart to log these at the default log priority. Perhaps they should be dropped to 'info' level. Killing a process as part of stopping the job is a perfectly normal situation and doesn't really seem to warrant logs. The only time I think it might be useful is when debugging issues with boot ordering, which would seem to be a good time to lower log priority to info anyway.

Changed in upstart (Ubuntu):
importance: Undecided → Low
Ido Anteby (8-ido) wrote :

I am encountering the same error when I try to add the second node using physical machines. If I use VMWare Workstation 8.0 I get this error when trying to add the first node. In both scenarios I am using PXE boot. Enlisting the nodes works but actualling installing them fails. Before the process cloud-init-nonet is killed, I also see an error stating "sdb: unknown partition table." I tried adding another hard drive and the error repeats except it shows "sdc" insteaf of "Sdb." I hope I'm not the only one experiencing these errors. Any feedback is appreciated.

Ido Anteby (8-ido) wrote :

I forgot to mention that there may be a relation to bug 992075

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in upstart (Ubuntu):
status: New → Confirmed
Sean Channel (sean-channel) wrote :

ading "normal exit SIGTERM" to /etc/init/cloud-init.conf will probably suppress the appearance of normal termination messages in dmesg. What would be slightly better, though probably overkill in this case, would be a signal handler that somehow pacifies upstart by catching SIGTERM and exiting more gracfully with 0 status.

Scott Moser (smoser) wrote :

fix-committed in trunk at revno 788.

Changed in cloud-init:
status: New → Fix Committed
importance: Undecided → Low
Scott Moser (smoser) wrote :

  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

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package cloud-init - 0.7.2~bzr795-0ubuntu1

cloud-init (0.7.2~bzr795-0ubuntu1) raring; urgency=low

  * New upstream snapshot.
    * documentation on write-files module (LP: #1111205)
    * support for specifying package versions in package installs
    * DataSourceNoCloud: allow specifyin user-data and meta-data in
      the datasource config (LP: #1115833)
    * work around bug in upstart for now (1124384)
    * support resizing btrfs fileystems
    * parse ssh keys more correctly (LP: #1136343)
    * upstart/cloud-init-nonet.conf: handle sigterm gracefully (LP: #1015223)
    * support growing partitions (LP: #1136936)
    * use --force-unsafe-io for dpkg installations to improve speed
      This is sane as it happens on instance initialization.
    * more powerful and user-suppliable cloud-config merge mechanisms
      (LP: #1023179)
 -- Scott Moser <email address hidden> Thu, 07 Mar 2013 17:33:59 -0500

Changed in cloud-init (Ubuntu):
status: Triaged → Fix Released
Scott Moser (smoser) wrote :

fixed in 0.7.2

Scott Moser (smoser) on 2013-05-15
Changed in cloud-init:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers