[Bug 1750780] Re: Race with local file systems can make open-vm-tools fail to start

[ChristianEhrhardt]

This will only "become" an issue for Xenial/Artful with the backport.
But lets do it right for tracking - so I added/modified tasks for these releases which allows me to refer changes and changelog to here.

That way with the backport it will "be an issue" for the former
releases, but also instantly be closed for them.

For SRU consideration, due to the newer systemd in >=Bionic it is not
affected - so it is "invalid" there. But for SRU considerations this is
ok, as the "most recent release has to be fixed" is covered, there won't
be an upgrade regression as when going e.g. Xenial->Bionic.

In the queue for SRU review now - main bug 1741390

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750780

Title:
  Race with local file systems can make open-vm-tools fail to start

Status in cloud-init:
  Invalid
Status in open-vm-tools package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Fix Released
Status in open-vm-tools source package in Xenial:
  Triaged
Status in systemd source package in Xenial:
  New
Status in open-vm-tools source package in Artful:
  Triaged
Status in open-vm-tools package in Debian:
  Fix Released

Bug description:
  Since the change in [1] open-vm-tools-service starts very (very) early.
  Not so much due to the 
  Before=cloud-init-local.service
  But much more by
  DefaultDependencies=no

  That can trigger an issue that looks like
  root at ubuntuguest:~# systemctl status -l open-vm-tools.service
  ● open-vm-tools.service - Service for virtual machines hosted on VMware
     Loaded: loaded (/lib/systemd/system/open-vm-tools.service; enabled; vendor preset: enabled)
     Active: failed (Result: resources)

  
  As it is right now open-vm-tools can race with the other early start and then fail.
  In detail one can find a message like:
    open-vm-tools.service: Failed to run 'start' task: Read-only file system"

  This is due to privtaeTmp=yes which is also set needing a writable
  /var/tmp [2]

  To ensure this works PrivateTmp would have to be removed (not good) or some after dependencies added that make this work reliably.
  I added
  After=local-fs.target
  which made it work for me in 3/3 tests.

  I' like to have an ack by the cloud-init Team that this does not totally kill the originally intended Before=cloud-init-local.service
  I think it does not as local-fs can complete before cloud-init-local, then open-vm-tools can initialize and finally cloud-init-local can pick up the data.

  To summarize:
  # cloud-init-local #
  DefaultDependencies=no
  Wants=network-pre.target
  After=systemd-remount-fs.service
  Before=NetworkManager.service
  Before=network-pre.target
  Before=shutdown.target
  Before=sysinit.target
  Conflicts=shutdown.target
  RequiresMountsFor=/var/lib/cloud

  # open-vm-tools #
  DefaultDependencies=no
  Before=cloud-init-local.service

  Proposed is to add to the latter:
  After=local-fs.target

  [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859677
  [2]: https://github.com/systemd/systemd/issues/5610

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