Several of our deployments have failed with the following error:
The step failed: Activity failed with error ‘An error occurred when sending a request to ‘server’, before the request could begin: No such host is known. No such host is known.’.
Sometimes it’s just one target server but it can also be 3-4. When we check, the Octopus tentacle is running on the supposedly unknown host. Retrying the deployment (even without restarting the tentacle or the affected server) seems to work without any problem.
What could be causing this problem and how do we resolve it long term?
Thanks for reaching out to Octopus Support, and I’m sorry you’re experiencing these failures in your deployments.
At first glance, this seems to be a transient DNS issue based on the error and the successful redeployment. Are these deployment targets already in place before your deployment is run? Are the targets being spun up and down (i.e. dynamic targets), or are they static? Just trying to get an idea of your process.
Could you send me a copy of the raw task log from a failed and successful deployment to the same targets for review? I’ve created a secure upload link you can use to send us any files.
I’d also like to mention a new Step Retry feature we implemented in 2023.2. We added this functionality to help address client issues with transient network issues.
I look forward to hearing back, and please let me know if you have any questions.
Thanks for your reply. These deployment targets are in place prior to the deployment, they are servers in one of our QA testing environments. I uploaded the raw task log you requested.
I looked into the Step Retry feature and was curious if it could be used in this case. The failure is occurring during acquire packages, which is an automatic step between our configured steps 1 and 2 (manual intervention steps) and step 3 (the first actual deployment step). Since we didn’t actual set up and configure the acquiring packages process, can we enable the Step Retry?
Thanks for sending over that deployment log. You’re right about the step retry; unfortunately, it’s not available for package acquisition, so it won’t help us in this situation.
I found another forum post that tackles a similar intermittent DNS issue that has a few helpful troubleshooting steps. You can also take a look through our tentacle troubleshooting doc. We have a utility called Tentacle Ping which can be very helpful when diagnosing networking issues like this.
Although we would hope to find the root cause on the network side, there are also a few things you could do to alleviate the issue in the short term. You can update your deployment targets to use an IP address rather than the hostname. You should see a more consistent connection if this is a DNS issue. You could also add a Health Check step to the beginning of your deployment. The step could help ensure you have a healthy connection before it attempts to download packages.
Please let me know if this helps or if you have any other questions for us.