# running apt commands immediately after ec2 provisioning in AWS can be problematic **URL:** \ **Category:** Ansible Project\ **Tags:** ubuntu, aws\ **Created:** [November 13, 2013, 12:25am UTC](https://forum.ansible.com/t/running-apt-commands-immediately-after-ec2-provisioning-in-aws-can-be-problematic/13897 "2013-11-13T00:25:56Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![John\_Jarvis](https://avatars.discourse-cdn.com/v4/letter/j/e47774/32.png) [@John\_Jarvis](https://forum.ansible.com/u/John_Jarvis)\ **Post date:** [November 13, 2013, 12:25am UTC](https://forum.ansible.com/t/running-apt-commands-immediately-after-ec2-provisioning-in-aws-can-be-problematic/13897/1 "2013-11-13T00:25:56Z")
For anyone who has been provisioning ubuntu boxes with the ec2 module it looks like you cannot safely update packages immediately after provisioning when ssh becomes available (the standard pattern for us has been launching a new server is to add a wait\_for condition for ssh and then add it to a host group). The typical failure I see is something like this: 21:19:20 TASK: [launch\_ec2 | Wait for SSH to come up] ---
**Author:** ![polfilm](https://avatars.discourse-cdn.com/v4/letter/p/bc8723/32.png) [@polfilm](https://forum.ansible.com/u/polfilm)\ **Post date:** [May 16, 2014, 9:45am UTC](https://forum.ansible.com/t/running-apt-commands-immediately-after-ec2-provisioning-in-aws-can-be-problematic/13897/2 "2014-05-16T09:45:29Z")
John Thank you for posting this. I confirm this to be a problem in ubuntu1204. Same problem exists for me with Windows 2012 instances. WinRm is connecting ok but cannot be used for at least 120 seconds (doing who knows what). Introducing delays or verification of required state seems to work. Yet another example is saving information back in chef. It takes about 60 seconds to save in Chef database so querying back for value being saved is a must to continue if other elements depend on them. Peter ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [May 16, 2014, 12:37pm UTC](https://forum.ansible.com/t/running-apt-commands-immediately-after-ec2-provisioning-in-aws-can-be-problematic/13897/3 "2014-05-16T12:37:04Z")
For new readers, we use a GIANT TON of 12.04 with Ansible, and haven’t run into this yet, but it’s quite possible our playbooks are a little different. We’d like to see your update line for “configure instances” to make sure we’re on the same page. We also don’t believe in having a lot of arcane incantations, like knowing you have to wait for a string in a file. What might be interesting is to explore the root cause of _why_ the cache is not yet available in cloud-init (is it a lock scenario because something else is happening, etc) and then we update the apt module to know how to wait – if it’s within reason, or at least capture and return a better error message. ---
**Author:** ![Adam\_Johnson](https://avatars.discourse-cdn.com/v4/letter/a/c57346/32.png) [@Adam\_Johnson](https://forum.ansible.com/u/Adam_Johnson)\ **Post date:** [February 25, 2015, 2:55pm UTC](https://forum.ansible.com/t/running-apt-commands-immediately-after-ec2-provisioning-in-aws-can-be-problematic/13897/4 "2015-02-25T14:55:11Z")
This has happened to me recently with the latest 14.04 ubuntu AMIs (from ec2\_ami\_search). The fix was to just re-order the tasks being applied so we don’t immediately run “apt: update\_cache=yes” but instead do some other environment/template tasks whilst waiting (hoping) for cloud-init to finish before apt is called, rather than adding the grep-polling on its log file.