I did a few experiments on slow hardware. I experienced that
1st boot (finish.sh) establishes the ansible tmp directory in /tmp/potos_ansible and runs the prepare.yml and playbook.yml from there.
One of the first roles to be executed (in my implementation) is basics which installs ansible-pull and the associated timer units. When this happens just before the full hour, it is possible that that timer fires while the playbook.yml spawned from finish.sh is still running.
While the temporary file locations are different and do not conflict, most likely one or the other apt lock fails (on either side)...
Possible Solutions:
add the lock file from ansible-pull to finish.sh
move basics to the end of my requirements.yml (I don't think this is actually a solution)
move the activation of the ansible-pull timers to a handler (that will be executed only after all roles are done). Not so nice IMHO as there is a risk that if the first ansible-pull is aborted (e.g. power failure on host), the time window for a "not activated timer" becomes quite long. This would result in an unmanaged client that needs a one time manual undisturbed run of ansible-pull to fix.
Description of the bug
I did a few experiments on slow hardware. I experienced that
prepare.yml
andplaybook.yml
from there.basics
which installsansible-pull
and the associatedtimer
units. When this happens just before the full hour, it is possible that that timer fires while theplaybook.yml
spawned fromfinish.sh
is still running.While the temporary file locations are different and do not conflict, most likely one or the other
apt
lock fails (on either side)...Possible Solutions:
lock
file fromansible-pull
tofinish.sh
basics
to the end of myrequirements.yml
(I don't think this is actually a solution)ansible-pull
timers to a handler (that will be executed only after all roles are done). Not so nice IMHO as there is a risk that if the first ansible-pull is aborted (e.g. power failure on host), the time window for a "not activated timer" becomes quite long. This would result in an unmanaged client that needs a one time manual undisturbed run of ansible-pull to fix.Steps To Reproduce
see above
Additional Information
No response