Linux Managed Run Command: approximately five-minute delay between execution success and provisioning success

Question

Linux Managed Run Command: approximately five-minute delay between execution success and provisioning success

S B 0

We observe a repeatable delay on an Ubuntu Azure VM using Managed Run Command (Microsoft.Compute/virtualMachines/runCommands, API 2025-04-01, asyncExecution=false).

Two commands ultimately completed successfully with executionState=Succeeded, provisioningState=Succeeded and exitCode=0. The scripts ran for approximately 3 seconds and 2 seconds. However, the gaps between first observed execution success and first observed provisioning success were 301.544 seconds and 300.233 seconds respectively.

We poll approximately every 5 seconds plus request time. These are observation times, not exact transition times. The second run had zero read errors. Azure Activity Log independently recorded the second command's write Succeeded event about 307.795 seconds after guest execution ended (using eventTimestamp, not submissionTimestamp).

Sanitized waagent log metadata contains status/success entries associated with that command about 4 seconds after guest execution ended. This does not establish successful upload or control-plane ingestion; we have not captured an upload acknowledgment.

Observed versions: WALinuxAgent launcher 2.11.1.4, goal-state agent 2.16.0.3, RunCommandHandlerLinux 1.3.28.

A read-only check of /etc/waagent.conf found Extensions.Enabled=y and Logs.Verbose=n, with no explicit Extensions.GoalStatePeriod override. The walinuxagent service is active/running. The documented default polling period is 6 seconds; this configuration-file check does not prove the effective in-memory interval.

We searched the public handler source/release notes but found no confirmed explanation for this approximately 300-second gap. We have not changed asyncExecution, restarted/upgraded agents, or relaxed completion verification.

Questions:

Is this delay a known or expected behaviour for Linux Managed Run Command with synchronous execution?
What supported read-only diagnostics distinguish guest status upload delay from Azure control-plane provisioning-state propagation?
Is there a documented mitigation that preserves both execution and provisioning completion verification?

This is a sanitized summary; resource identifiers, correlation IDs, scripts, credentials and raw logs are intentionally omitted.

0 comments

1 answer

Your answer

Answer 1

1. Is the delay known or expected?

I couldn’t find anything saying the 300 seconds is intentional. so I wouldn’t build a timeout around that number.

2. What read-only diagnostics separate guest upload delay from control-plane propagation?

You already have what you need. The waagent logs don’t prove upload or ingestion, but ExecutionState from the API does, since the control plane can’t report it until it has the guest status. So if ExecutionState shows Succeeded at around 3 seconds while ProvisioningState hasn’t flipped yet, the guest side is done and whatever remains is platform side.

3. Is there a documented mitigation that preserves verification?

No, not if you need both confirmed. The 300 seconds is the wait on ProvisioningState, a separate event from the script finishing.

What the docs do settle is whether you actually need both. Run scripts in a Linux VM in Azure using managed Run Commands says of InstanceView.ExecutionState: “Refer this state to know whether your script was successful or not.” ProvisioningState is defined separately as “Status of general extension provisioning end to end (whether extension platform was able to trigger Run Command script or not).”

So if what you are verifying is that the script ran and succeeded, ExecutionState plus ExitCode is the documented check, with “A nonzero ExitCode indicates an unsuccessful execution.”

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.