Thanks Scott for your cross check. I wonder why my former test failed on each of my tests without writing, but never the less your extended example is great for the systemd issue that remains.
Although all of this is still a race, for example with the job above on a Xenial container I could not trigger it in several retries (5/5 worked). Doing the same in a Xenial KVM guest instead triggered it right away, but still not on every reboot (3/5 failed). I hope that helps everybody trying to reproduce this. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, 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: Fix Released 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 package in Debian: Incomplete 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@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 -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
