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 notifica
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.
https://bugs.launchpad.net/bugs/1750
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 aut
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 aut
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
s
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 test
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 test
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 instant
** 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 => Tri
** 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 wi
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
** 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 be
** 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
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 => In
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 simple
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
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 not
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 subscr
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 a
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. But
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 'After=local-fs.target' essentially pushes cloud-i
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
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
** 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 st
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
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]: https://launchpad.net/ubun
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.
https://bugs.launc
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.
https://bugs.launc
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 the
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
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 s
31 matches
Mail list logo
