-
Notifications
You must be signed in to change notification settings - Fork 856
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Location.GetConnectionData : The HTTP request timed out (With agent 2.177.0) #3176
Comments
Hello, is there some extra information I can give or debug option I can use to help in this issue resolution? |
Hi @xlz-jgoutin, is 'https://dev.azure.com/Accelize/' reachable from agent machine? If you experience some network issues - you can also use agent knobs - just by increasing value for them by setting VSTS_HTTP_RETRY and VSTS_HTTP_TIMEOUT environment variables - to increase HTTP timeout and retry count for agent |
Hello, I did the following test on a fresh Ubuntu 18.04 instance:
=> Success (with a very short response delay) Trying to configure the agent
=> Error Retrying with curl after the config command.
=> Success. Test with full URL from logs:
=> Success I also run the same test from my full CI process by editing my Ansible playbook, the curl command always works everywhere, but the |
@xlz-jgoutin could you please try to increase http timeout/retry count also using agent knobs? |
I rerun the full tests sequences with increased values: I still get the same error on the same set of OS (But after 50 minutes of a single "./config.sh" run). Note that:
This does not seem to be a network issue. |
Instead of using the latest release, I tried to run my tests (Ubuntu 18.04 only) against pinned versions:
So, the conclusion is that the issue is only with the agent version >= 2.177.0 |
Pin version on some tests (Cf microsoft/azure-pipelines-agent#3176)
Add option to pin to a specific agent version Pin version on some tests (Cf microsoft/azure-pipelines-agent#3176)
I seen "Switch to new HTTP handler by default (#3117)" in the 2.177.0 changelog. So i tried to run 2.177.1 agent with AZP_AGENT_USE_LEGACY_HTTP=true, and it completes successfully. The cause of this issue is related to the new HTTP handler. |
@xlz-jgoutin thanks for investigation here, as per release notes for 2.177.0 - new HTTP handler is used by default, so to use legacy http - you just need to set AZP_AGENT_USE_LEGACY_HTTP=true. |
Is there a chance that Suggestion: the agent may try to fallback itself to the legacy HTTP handler if failing the new HTTP handler. |
This issue is 100% reproducible even in 2.204.0! It took me hours to find this issue and try to work around it with AZP_AGENT_USE_LEGACY_HTTP=true. Is there an ETA for a fix for this? |
Running Ubuntu 20.04 and could never get service to go past the 'Connecting to the server' error to Azure DevOps Server. Thought it might be SSL related but no logs to indicate. I installed 7 different versions of the agent including the prerelease 2.209.0 to see if anything could help. No dice; same connecting standoff. Took the suggestion here and installed v2.165.0 and finally got it to connect! But I sent over the first job and the agent updates to 2.181.2 (even though the agent pool is set to NOT auto update). Once it updates, I'm back to the 'Connection to the server' error. Very frustrating; I have no way to build on a linux os.
|
Agent Version and Platform
Version of your agent? 2.177.1
OS of the machine running the agent? Ubuntu 18.04, CentOS8
Azure DevOps Type and Version
dev.azure.com
If dev.azure.com, what is your organization name? Accelize
What's not working?
The command :
Returns the error:
We use an Ansible role to provision the agent on differents OS and cloud (Azure or AWS). This works good since almost one year now. But recently, we starded get this issues on some case like (100% reproductible):
Strangely, this works on:
There is no differences between theses cases (Except base image and cloud provider), so I do not see from where come the issue. Especially since this worked perfectly before.
Agent and Worker's Diagnostic Logs
The text was updated successfully, but these errors were encountered: