geerlingguy / ansible-role-gitlab

Ansible Role - GitLab

Home Page:https://galaxy.ansible.com/geerlingguy/gitlab/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Async timeout too short in install task

jknaus opened this issue · comments

With the given async: 300 setting in the Install Gitlab task my installation never succeeded:

TASK [geerlingguy.gitlab : Install GitLab] *********************************************************************************************
fatal: [testvm]: FAILED! => {"changed": false, "msg": "async task did not complete within the requested time - 300s"}

I changed it to 60000 (might be too high, actually) and then it worked.

Maybe the timeout could better be a variable in defaults/main.yml?

I also have to change this, 600 worked for me. It's a huuuge package and a lot of post actions, so 300 is not enough.

I've created pull request #163 for this

commented

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

Timeout as well in my case. I removed the async statement entirely. What was the intent to use async?

Br,
Sebastian

commented

This issue is no longer marked for closure.

Timeout for me as well:
TASK [geerlingguy.gitlab : Install GitLab] ************************************* fatal: [ubu-gitlab]: FAILED! => {"changed": false, "msg": "async task did not complete within the requested time - 300s"}

My usecase: vagrant with:

  • Ubuntu 16.04.7 LTS
  • 4GB mem

fix was to increase async, however would be fine to have a long-term solution (fixed in role).

Thanks in advice.

Br,

commented

This issue has been marked 'stale' due to lack of recent activity. If there is no further activity, the issue will be closed in another 30 days. Thank you for your contribution!

Please read this blog post to see the reasons why I mark issues as stale.

commented

This issue has been closed due to inactivity. If you feel this is in error, please reopen the issue or file a new issue with the relevant details.

FWIW I'm running into this as well. Unsure what's causing it to work quickly on local VMs and not in EC2 instances, as the local VMs don't get the timeout.