I have seen that strategy also but as you say, not super clean. I may have to go digging into the ansible galaxy roles and see if I can do some tweaking there because that appears to be the primary area with the issue. Outside of that a wait strategy might work. On Thursday, February 3, 2022 at 7:23:09 AM UTC-5 [email protected] wrote:
> Maybe it's not the most clean approach, but you can check if the > command returned an error message including "Could not get lock" > substring. > > You can repeat this command with some delay in between and with a > limit of repeating cycles, waiting for the automatic update to finish. > Once the command ends with no error (or with a different error), then > you can continue. > > El mié, 2 feb 2022 a las 13:32, Martin Sharp (<[email protected]>) > escribió: > > > > I have a single node deployment anisble playbook that runs via rundeck > to stage cloud-init, pxe installed, 20.04 Ubuntu systems with ubuntu > desktop for an idm domain with a standard configuration. The issue I am > having is that on first run after the pxe process we get a "No package > matching 'freeipa-client' is available" when we get into installing the > free-ipa client via galaxy ansible_freeipa on the host. > > > > If we run a repeat rundeck job almost immediately after the first > failure, we get a "Could not get lock /var/lib/dpkg/lock-frontend. It is > held by process XXXXX (apt)" or sometimes depending on some troubleshooting > steps that were tried, apt-get. Then once we wait for a "time" we do a > third run and it will finish correctly. I have told it to do manual apt-get > based updates also which caused the same type of errors in other parts of > the play and one time it errored out an a pre bash script with the lock and > error-ed out one time saying it couldn't find "crony" under another step. > > > > Based on multiple tests, I believe this is an issue related to ansible > not waiting for apt/apt-get to completely finish before continuing on. > > > > Is there some sort of strategy I am missing for the playbook or free-ipa > role for it to not be handling the plays correctly for apt/apt-get causing > this sort of problem? > > > > It occurs inside the primary playbook and the subsequent call of the > galaxy free-ipa playbook but usually between steps "TASK [ipaclient : > Import variables specific to distribution]" and "TASK [ipaclient : Install > IPA client]" within the free_ipa cliient task call. > > > > I have looked into potentially implementing a wait_for but that doesn't > really make sense as the galaxy call is just that, an import install call > and not something I necessarily would be adjusting without messing with the > base project. I am unsure if this is strictly an ansible problem or > potentially a galaxy free_ipa problem in the way it is using ansible. > > > > Any thoughts on this would be greatly appreciated. > > > > > > > > -- > > You received this message because you are subscribed to the Google > Groups "Ansible Project" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected]. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/c5695c69-cf48-4960-aa64-71d0a0def4e8n%40googlegroups.com > . > > > > -- > > Roberto Paz > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/16ffa80b-9e5f-4804-b65d-611e485cdbb5n%40googlegroups.com.
