Public bug reported:
The open-vm-tools.service unit declares After=apparmor.service and
Before=cloud-init-local.service with ConditionVirtualization=vmware.
On non-VMware platforms (ex Azure, GCP, AWS), the condition correctly prevents
open-vm-tools from running, but the static ordering constraints still apply
during systemd's dependency-graph construction before conditions are evaluated.
This serializes cloud-init-local to wait for AppArmor completion, adding ~2.5
seconds of delay to boot time on affected platforms.
Impact:
Boot time, time-to-SSH increase: ~2.5s on Azure Standard_D2as_v5
Scope: All non-VMware deployments (Azure, GCP, AWS, bare metal without VMware
hypervisor)
Evidence: Same-VM A/B test on Ubuntu 26.04 Server with single variable
(open-vm-tools.service masked) shows AppArmor→cloud-init-local ordering flips
from serialized (+0.011s) to overlapped (−1.24s)
Root Cause:
Systemd evaluates unit dependencies (like After=, Before=) during graph
construction, before conditions (like ConditionVirtualization=) are evaluated
at runtime. The open-vm-tools.service unit declares:
After=apparmor.service
Before=cloud-init-local.service
ConditionVirtualization=vmware
On non-VMware platforms, the ConditionVirtualization=vmware condition correctly
skips the service at runtime, but the static ordering constraints from the
graph construction phase remain active.
Result: cloud-init-local is ordered to wait for AppArmor completion even though
the service declaring that order never runs.
** Affects: open-vm-tools (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
- The open-vm-tools.service unit declares After=apparmor.service and
Before=cloud-init-local.service with ConditionVirtualization=vmware.
- On non-VMware platforms (ex Azure, GCP, AWS), the condition correctly
prevents open-vm-tools from running, but the static ordering constraints still
apply during systemd's dependency-graph construction before conditions are
evaluated.
+ The open-vm-tools.service unit declares After=apparmor.service and
Before=cloud-init-local.service with ConditionVirtualization=vmware.
+ On non-VMware platforms (ex Azure, GCP, AWS), the condition correctly
prevents open-vm-tools from running, but the static ordering constraints still
apply during systemd's dependency-graph construction before conditions are
evaluated.
This serializes cloud-init-local to wait for AppArmor completion, adding ~2.5
seconds of delay to boot time on affected platforms.
Impact:
- Boot time, time-to-SSH increase: ~2.5s on Azure Standard_D2as_v5
+ Boot time, time-to-SSH increase: ~2.5s on Azure Standard_D2as_v5
Scope: All non-VMware deployments (Azure, GCP, AWS, bare metal without VMware
hypervisor)
Evidence: Same-VM A/B test on Ubuntu 26.04 Server with single variable
(open-vm-tools.service masked) shows AppArmor→cloud-init-local ordering flips
from serialized (+0.011s) to overlapped (−1.24s)
Root Cause:
-
- Systemd evaluates unit dependencies (like After=, Before=) during graph
- construction, before conditions (like ConditionVirtualization=) are
- evaluated at runtime. The open-vm-tools.service unit declares:
+ Systemd evaluates unit dependencies (like After=, Before=) during graph
construction, before conditions (like ConditionVirtualization=) are evaluated
at runtime. The open-vm-tools.service unit declares:
After=apparmor.service
Before=cloud-init-local.service
ConditionVirtualization=vmware
On non-VMware platforms, the ConditionVirtualization=vmware condition
correctly skips the service at runtime, but the static ordering
constraints from the graph construction phase remain active. Result:
cloud-init-local is ordered to wait for AppArmor completion even though
the service declaring that order never runs.
Proposed Solution:
Move the platform-specific ordering constraints (After=apparmor.service,
Before=cloud-init-local.service) into a VMware-only systemd generator, so they
are only added to the dependency graph on VMware hypervisors. This keeps the
constraints present on VMware (where they are intended) while eliminating them
on other platforms.
** Description changed:
The open-vm-tools.service unit declares After=apparmor.service and
Before=cloud-init-local.service with ConditionVirtualization=vmware.
On non-VMware platforms (ex Azure, GCP, AWS), the condition correctly
prevents open-vm-tools from running, but the static ordering constraints still
apply during systemd's dependency-graph construction before conditions are
evaluated.
This serializes cloud-init-local to wait for AppArmor completion, adding ~2.5
seconds of delay to boot time on affected platforms.
Impact:
Boot time, time-to-SSH increase: ~2.5s on Azure Standard_D2as_v5
Scope: All non-VMware deployments (Azure, GCP, AWS, bare metal without VMware
hypervisor)
Evidence: Same-VM A/B test on Ubuntu 26.04 Server with single variable
(open-vm-tools.service masked) shows AppArmor→cloud-init-local ordering flips
from serialized (+0.011s) to overlapped (−1.24s)
Root Cause:
Systemd evaluates unit dependencies (like After=, Before=) during graph
construction, before conditions (like ConditionVirtualization=) are evaluated
at runtime. The open-vm-tools.service unit declares:
After=apparmor.service
Before=cloud-init-local.service
ConditionVirtualization=vmware
On non-VMware platforms, the ConditionVirtualization=vmware condition
correctly skips the service at runtime, but the static ordering
constraints from the graph construction phase remain active. Result:
cloud-init-local is ordered to wait for AppArmor completion even though
the service declaring that order never runs.
-
- Proposed Solution:
- Move the platform-specific ordering constraints (After=apparmor.service,
Before=cloud-init-local.service) into a VMware-only systemd generator, so they
are only added to the dependency graph on VMware hypervisors. This keeps the
constraints present on VMware (where they are intended) while eliminating them
on other platforms.
** Description changed:
The open-vm-tools.service unit declares After=apparmor.service and
Before=cloud-init-local.service with ConditionVirtualization=vmware.
On non-VMware platforms (ex Azure, GCP, AWS), the condition correctly
prevents open-vm-tools from running, but the static ordering constraints still
apply during systemd's dependency-graph construction before conditions are
evaluated.
This serializes cloud-init-local to wait for AppArmor completion, adding ~2.5
seconds of delay to boot time on affected platforms.
Impact:
Boot time, time-to-SSH increase: ~2.5s on Azure Standard_D2as_v5
Scope: All non-VMware deployments (Azure, GCP, AWS, bare metal without VMware
hypervisor)
Evidence: Same-VM A/B test on Ubuntu 26.04 Server with single variable
(open-vm-tools.service masked) shows AppArmor→cloud-init-local ordering flips
from serialized (+0.011s) to overlapped (−1.24s)
Root Cause:
Systemd evaluates unit dependencies (like After=, Before=) during graph
construction, before conditions (like ConditionVirtualization=) are evaluated
at runtime. The open-vm-tools.service unit declares:
After=apparmor.service
Before=cloud-init-local.service
ConditionVirtualization=vmware
- On non-VMware platforms, the ConditionVirtualization=vmware condition
- correctly skips the service at runtime, but the static ordering
- constraints from the graph construction phase remain active. Result:
- cloud-init-local is ordered to wait for AppArmor completion even though
- the service declaring that order never runs.
+ On non-VMware platforms, the ConditionVirtualization=vmware condition
correctly skips the service at runtime, but the static ordering constraints
from the graph construction phase remain active.
+ Result: cloud-init-local is ordered to wait for AppArmor completion even
though the service declaring that order never runs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2166910
Title:
open-vm-tools.service unnecessary ordering constraint blocks cloud-
init on non-VMware platforms
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/2166910/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
