yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1707222@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package cloud-init - 0.7.9-267-g922c3c5c-
0ubuntu1

---------------
cloud-init (0.7.9-267-g922c3c5c-0ubuntu1) artful; urgency=medium

  * New upstream snapshot.
    - Ec2: only attempt to operate at local mode on known platforms.
      (LP: #1715128)
    - Use /run/cloud-init for tempfile operations. (LP: #1707222)
    - ds-identify: Make OpenStack return maybe on arch other than intel.
      (LP: #1715241)
    - tests: mock missed openstack metadata uri network_data.json
      [Chad Smith] (LP: #1714376)
    - relocate tests/unittests/helpers.py to cloudinit/tests
      [Lars Kellogg-Stedman]
    - tox: add nose timer output [Joshua Powers]
    - upstart: do not package upstart jobs, drop ubuntu-init-switch module.
    - tests: Stop leaking calls through unmocked metadata addresses
      [Chad Smith] (LP: #1714117)

 -- Scott Moser <smoser@xxxxxxxxxx>  Thu, 07 Sep 2017 16:59:04 -0400

** Changed in: cloud-init (Ubuntu)
       Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1707222

Title:
  usage of /tmp during boot is not safe due to systemd-tmpfiles-clean

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  Earlier this week on Zesty on Azure I saw a cloud-init failure in its 'mount_cb' function.
  That function esentially does:
   a.) make a tmp directory for a mount point
   b.)  mount some filesystem to that mount point
   c.) call a function
   d.) unmount the directory

  What I recall was that access to a file inside the mount point failed during 'c'.
  This seems possible as systemd-tmpfiles-clean may be running at the same time as cloud-init (cloud-init.service in this example).

  
  It seems that this service basically inhibits *any* other service from using tmp files.
  It's ordering statements are only:

    After=local-fs.target time-sync.target
    Before=shutdown.target

  So while in most cases only services that run early in the boot
  process like cloud-init will be affected, any service could have its
  tmp files removed.  this service could take quite a long time to run
  if /tmp/ had been filled with lots of files in the previous boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1707222/+subscriptions