cloud-init-nonet main process killed by TERM signal

Bug #1015223 reported by Scott Moser
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cloud-init
Fix Released
Low
Unassigned
cloud-init (Ubuntu)
Fix Released
Low
Unassigned
upstart (Ubuntu)
Confirmed
Low
Unassigned

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
ProcEnviron:
 TERM=screen-bce
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Scott Moser (smoser) wrote :
Scott Moser (smoser)
Changed in cloud-init (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Scott Moser (smoser)
description: updated
Revision history for this message
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
Revision history for this message
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.

Revision history for this message
Ido Anteby (8-ido) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in upstart (Ubuntu):
status: New → Confirmed
Revision history for this message
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.

Revision history for this message
Scott Moser (smoser) wrote :

fix-committed in trunk at revno 788.

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

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

Revision history for this message
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
Revision history for this message
Scott Moser (smoser) wrote :

fixed in 0.7.2

Scott Moser (smoser)
Changed in cloud-init:
status: Fix Committed → Fix Released
Revision history for this message
James Falcon (falcojr) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.