Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This article discusses possible causes and how to resolve an unresponsive deployment which doesn't exit the Waiting state.
Symptoms
When you try to deploy a container group, the deployment times out after 30 minutes and fails. Additionally, the container state is shown as Waiting.
Cause
The Waiting state indicates there's a condition preventing deployment setup or container start. The most likely root causes include:
- The container main process won't start or crashes.
- The container is using reserved ports.
- The container group has an Azure file share volume and it's failing to mount.
- There's subnet IP exhaustion (like bring your own virtual network (BYOVNET)).
- There are capacity issues.
Solution
Possible solutions include:
- Check that the container runs fine locally. A local machine with Docker can be used to do this.
- Inspect possible errors on the Container Events tab starting with the main container process.
- Make sure no reserved ports are being used in the container definition. For more information, see Does the ACI service reserve ports for service functionality?.
- Check that there's connectivity to the Azure file share and that the key is correct or valid. If deployment is on BYOVNET, check that DNS resolution is working for the Azure file share fully qualified domain name (FQDN).
- Check Azure file share volume limitations for Azure Container Instances (ACI). Using a private endpoint to connect to an Azure file share hasn't been tested and might not be reliable. Instead, use a subnet service endpoint for private connectivity as recommended in documentation.
- Change the subnet network mask. ACI keeps its own IP mapping internally and at ARM level all IPs always show as available. Depending on the frequency of deployments or restarts, subnet IP exhaustion errors can happen because internal mapping isn't updated in time. To avoid this issue, we recommend using a subnet network mask of
/24or greater. - Attempt the deployment with less resource requests or in another region to confirm possible capacity issues.
Note
We don't recommend using subnets smaller than /24 to work around unsupported scenarios (like simulating a fixed IP address by restricting the Dynamic Host Configuration Protocol (DHCP) to only a few IPs) as this can cause failed deployments or failed start operations due to subnet full errors.
Resources
Contact us for help
If you have questions, you can ask Azure community support. You can also submit product feedback to Azure feedback community.
Third-party contact disclaimer
Microsoft provides third-party contact information to help you find additional information about this topic. This contact information may change without notice. Microsoft does not guarantee the accuracy of third-party contact information.