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

No, unless you were afraid that what ticked open-vm-tools into having issues here being a wider more general issue. But then given that 16.04 is used widely for quite some time I think we can assume it is a corner case only. incomplete on the systemd task is ok. -- You received this bug

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

So, is there anything requested to be done with Xenial's systemd in this bug? ** Changed in: systemd (Ubuntu Xenial) Status: New => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

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

This bug was fixed in the package open-vm-tools - 2:10.2.0-3~ubuntu0.17.10.1 --- open-vm-tools (2:10.2.0-3~ubuntu0.17.10.1) artful; urgency=medium * backport Bionic open-vm-tools to Artful (LP: #1741390) - d/control: B-D for dh-autoreconf and dh-systemd - d/rules: re-add

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

This bug was fixed in the package open-vm-tools - 2:10.2.0-3~ubuntu0.16.04.1 --- open-vm-tools (2:10.2.0-3~ubuntu0.16.04.1) xenial; urgency=medium * backport Bionic open-vm-tools to Xenial (LP: #1741390) - d/control: B-D for dh-autoreconf and dh-systemd - d/rules: re-add

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

1. Upgrade from proposed - this is the same for all associated bugs, so I only documented details in bug 1741390 2. This bug in particular Running a few restarts and checking $ systemctl status -l open-vm-tools.service This checks if the service rules avoid the issue on these systems with older

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

Hello ChristianEhrhardt, or anyone else affected, Accepted open-vm-tools into artful-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/open-vm- tools/2:10.2.0-3~ubuntu0.17.10.1 in a few hours, and then in the -proposed repository. Please help us by

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

Hello ChristianEhrhardt, or anyone else affected, Accepted open-vm-tools into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/open-vm- tools/2:10.2.0-3~ubuntu0.16.04.1 in a few hours, and then in the -proposed repository. Please help us by

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

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

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

** Also affects: open-vm-tools (Ubuntu Artful) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Artful) Importance: Undecided Status: New ** No longer affects: systemd (Ubuntu Artful) ** Changed in: open-vm-tools (Ubuntu Xenial) Status: Invalid =>

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

** Merge proposal unlinked: https://code.launchpad.net/~paelzer/ubuntu/+source/open-vm-tools/+git/open-vm-tools/+merge/341797 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1750780 Title: Race

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

Note: When we do the Xenial backport of the new version of open-vm-tools (which we plan to do) this becomes an issue. In the same upload I intend to fix it right away, so it should never effectively exist in the field (keep invalid, but there might be a fix-released update to open-vm-tools here at

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

** Merge proposal linked: https://code.launchpad.net/~paelzer/ubuntu/+source/open-vm-tools/+git/open-vm-tools/+merge/341796 ** Merge proposal linked: https://code.launchpad.net/~paelzer/ubuntu/+source/open-vm-tools/+git/open-vm-tools/+merge/341797 -- You received this bug notification

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

** Changed in: open-vm-tools (Debian) Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1750780 Title: Race with local file systems can make open-vm-tools fail

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

For open-vm-tools this issue will only exist with the planned backport of the newer version. Since we will not ship the broken backport as we found it in pre-checks the correct state for open-vm-tools in xenial is invalid. ** Changed in: open-vm-tools (Ubuntu Xenial) Status: Triaged =>

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

With the former update in mind I retried Xenial/Bionic again. All of it is racy (as we knew), but it never triggered for Bionic. Xenial (19/33 fails) Bionic (0/37 fails) So for now we continue to assume that it is fixed there (by systemd) and revert our added dependency. Note: as with the

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

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

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

I agree with reverting change in bionic, and that xenial still needs some fix. I recreated your failure in xenial and agree with your change there. I used this job as it actually tries to write to the private tmp. If I change 'ExecStart' below to be just '/bin/true' like in your job, it does

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

I'Ll likely revert the Binonic change tmrw morning as we have discussed. local-fs.target is actually >> the implicit dependency. But that does not solve the Xenial issue outlined in the former comment. -- You received this bug notification because you are a member of Ubuntu Bugs, which is

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

Installed another Xenial and Bionic in vmware to take a deper look. - Xenial (with backported open-vm-tools): affected - Bionic (with the interim fix reverted): no hit in several retries, explanation below Systemd fixed it (via our assumed implicit dependency). In Bionic the PrivateTmp gives it

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

There is a difference between cloud-init sometimes running after local- fs.target and being guaranteed to run after local-fs.target. The change here guarantees it. For the moment, this isn't too bad, as cloud-init can't really affect local-fs.target because it isn't guaranteed to run before.

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

On Thu, Feb 22, 2018 at 9:16 AM, Scott Moser wrote: > I dont think I really agree with this fix. > > I forgot that we dropped local-fs.target for exactly what we needed: After=systemd-remount-fs.service RequiresMountFor=/var/lib/cloud > Adding

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

While I can follow your argument of "it should work" I tested and if I drop 'After=local-fs.target' I'm in bad state again. If from this state I disable PrivateTmp it works as well. So it is PrivateTmp even though the documentation you linked says it should not. I wondered if that might only be

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

I dont think I really agree with this fix. Adding 'After=local-fs.target' essentially pushes cloud-init to have that same dependency, which it does not have. We don't really want cloud-init to have to wait for local-fs.target. For example see bug 1691489 (and related fallout bug 1717477). If

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

** Changed in: open-vm-tools (Debian) Status: Unknown => Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1750780 Title: Race with local file systems can make open-vm-tools fail to

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

This bug was fixed in the package open-vm-tools - 2:10.2.0-3ubuntu1 --- open-vm-tools (2:10.2.0-3ubuntu1) bionic; urgency=medium * d/open-vm-tools.service: Add After=local-fs.target dependency ensuring filesystems are ready to fix a race on startup (LP: #1750780) -- Christian

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

1. I updated the ppa we test for a potential xenial-backport. It now has 10.2.0-3ubuntu0.16.04.1~ppa2 with the fix applied 2. Pushed said fix to Bionic [1] (need to check proposed migration) 3. reported the same to Debian, but then found [2] and chimed in there [1]:

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

cloud-init task was just for discussion, marking it invalid to make clear there is no cloud-init action needed. ** Changed in: cloud-init Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

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

I'll fix the current known race for now. @Rharper - I guided the original author of the change to the bug 1667831 here. @Sankar - I hope you can answer Ryans question. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

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

I tested the fix a bit more, always worked for me, that said I'll: 1. upload something to the ppa of the xenial backport (it is a ppa, we can iterate fast there) 2. I consider Ryans check an ack to an MP (and it is the only change), so I'll fastpath that change and upload to bionic 3. report

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

So, definitely using the After=local-fs.target is a sane fix to ensuring that the local filesystem is mounted before starting. I'm interested in understanding why the open-vm-tools needs to run before cloud-init. specifically, what's wrong with: After=cloud-init.service which is when more of

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

Note: IMHO a consequence of the bad fix (in Debian) to bug 1667831 ** Changed in: open-vm-tools (Ubuntu) Status: New => Triaged ** Changed in: open-vm-tools (Ubuntu) Importance: Undecided => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is