Sudden error after update: initial DNS resolution test failed #2410
Comments
|
I'm hitting this as well with a fresh install running the latest docker image, it seems to be stable until traffic goes through it according to the logs. |
|
@tchit What version worked previously? |
|
Just to be clear. When you say "error after update" you mean an update of your Synology, right? We've had a slight issue with NordVPN in the newest release as well (but completely unrelated to this) that should be fixed now on the Anyways it seems like the error message is saying that it can't parse the |
|
Mmmm I’m running Watchtower and it says it updated the version a few days ago. That’s weird. Maybe it shows an incorrect version number? It was written in the variables…Resolv.conf shows nameserver 8.8.8.8 and 8.8.4.4I update my Nas regularly but didn’t update it between the time it worked and it stopped working. Thanks a lot!Le 16 nov. 2022 à 09:45, Kristian Haugene ***@***.***> a écrit :
Just to be clear. When you say "error after update" you mean an update of your Synology, right?
Because the version of the image you're running is two years old. So this is probably on the Synology side.
We've had a slight issue with NordVPN in the newest release as well (but completely unrelated to this) that should be fixed now on the edge tag. Can you change from using the latest tag to edge and print your logs then?
Anyways it seems like the error message is saying that it can't parse the /etc/resolv.conf file that you have mounted. Have you checked the contents of that file to see that it looks good?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Tested with edge, getting: |
|
@tchit I find it a bit unlikely that the logs of the container has got the wrong version number. These are long and unique shas and the one output in in your image is two years old. I wont say it's impossible that there's an error with the build but would like you to do some more testing before we go down that route. Can you try just dropping the volume mount for resolv.conf for now, and change the image from using the :latest tag to :edge? Then paste the logs here. @nwmcsween No idea what's going on for your setup. Can you share the docker-compose you're using, and some logs please? What version of the image are you running, with which provider? |
|
Also got the same issue after upgrading to latest version a few minutes ago: DNS resolution failed |
|
@WLines84 I need the same from you. Your container config/setup (docker run, docker compose, portainer, watchtower, ...) and logs. Where you find logs depends on how you run your container. |
|
I recently updated my docker-compose where I had the image set to :latest. I have some pre scripts that run that couldn't connect to what they need to, which prevented transmission from starting. Not sure if it's exactly the same issue as this, but and I can dive into it more later, but rolling back to |
|
im running it on docker-compose ###################Transmission devices:- /dev/net/tun- 1.0.0.1ipv4_address: 172.19.0.8logs: 11/16/2022 3:44:28 PM
|
Ok, so I'd like first to apologize because I am really a noob. Here is my log file with better formatting this time : I don't know how to check the version I am using? Thanks a lot |
|
Edit: it says revision |
|
Glad to hear you got it working 👍 |
|
Was hoping to dig a bit more into this today, but wasn't able to. But! Had a chat with a friend who's experiencing the same issue and he pointed to: https://askubuntu.com/questions/1405417/20-04-vs-22-04-inside-docker-with-a-16-04-host-thread-start-failures We compared host OS and Docker versions and were both on Ubuntu 20.04 hosts, but Docker versions diverged. He was on Can you try to upgrade your Docker installs, and report if that works. Or if it doesn't - what OS and Docker version are you running? Or... If upgrading docker is not feasible (part of NAS packages etc) you can try the seccomp option in the link. Adding |
|
Latest update broke mine too. I am on Unraid and cannot update the docker service. Using |
|
FYI @haugene I typically keep my Docker up-to-date, but there is a nasty bug in Mac version of Docker (see here, so I've stayed back on previous versions for now. Even with the -security_opt it still causes docker for mac to become unstabe for me and reverting to 4.1 fixes the issue. If you look at the bug reported in my link, this all goes back to something to do with VPNKIT. |
|
Hey boss, I hope this helps. My log from today using your docker-compose setup from docker hub with docker, docker-compose and transmission-openvpn all being fully up to date as of this posting (also its Docker on Windows v20.10.5): Starting container with revision: b33d0fe4c938259a0d4eb844e55468f387456121
One or more OVERRIDE_DNS addresses found. Will use them to overwrite /etc/resolv.conf
/etc/openvpn/start.sh: line 34: 15 Aborted nslookup ${HEALTH_CHECK_HOST:-"google.com"} > /dev/null 2>&1
WARNING: initial DNS resolution test failed
Creating TUN device /dev/net/tun
Using OpenVPN provider: EXPRESSVPN
Running with VPN_CONFIG_SOURCE auto
No bundled config script found for EXPRESSVPN. Defaulting to external config
Downloading configs from https://github.com/haugene/vpn-configs-contrib/archive/main.zip into /tmp/tmp.RWE5pQNXUv
curl: (6) getaddrinfo() thread failed to start
./etc/openvpn/fetch-external-configs.sh: line 18: config_repo_temp_dir: unbound variable |
|
I missed this part... Adding that to my docker-compose file did the trick! Thanks for the quick fix.
|
|
I have this too. Yesterday after updating it hit me. Running OMV but it broke the container. I cant make any change to my container without getting an error 400 message. Where do I add the security_opt? |
|
Thank you haugene! In case it helps anyone - I had one long running Ubuntu system mysteriously stop working on or about Thursday this week: Saw your note here about a docker upgrade potentially fixing - and that appear to fix things (version references): |
Hey. How would I go back to a previous working version? |
|
Use image tags. So specify image haugene/transmission-openvpn:4.1 to get
4.1 for example. Even 4.2 should work as this seems to be about the base
image update that came in 4.3
|
|
Thank you. I reverted and its working. Ill just turn off my auto updater containers for now. |
I was running into issues with the container starting when I updated to version 4.3. Upgrading my Docker version to 20.10.20 fixed my problem. Thank you! |
|
Thanks! Updating all packages on my Ubuntu server was long overdue anyway. My errors looked like this: Curl command from within the container: |
|
Judging by all of you who have tested both upgrading Docker and using the So we'll stay on ubuntu:22.04 as the base image for now and I've made a note of it in the main README. As time passes more and more users should be on newer versions of Docker and this will hopefully blow over. Closing this issue for now - but feel free to re-open or submit a new one if it re-appears or you find some other issue with the solution. |
|
In case this helps anyone I am using Dockers on Windows and neither of these workarounds helped (reverting to older Transmission image or updating docker-compose file with seccomp:unconfined). I ended up rolling back Docker for Windows version 14.15 to version 14.12 to resolve. |
|
Getting "DNS Resolution Failed". Came here and saw this thread. I have tried switching versions (4.0, 4.1, 4.2, 4.3, latest, dev). Added security_opt: - seccomp:unconfined to my docker-compose. Added DNS overrides. Made sure Docker is updated and even updated my OS. Still getting the same problem. Interestingly, if I use 4.0, I actually get a ping response from google but it still errors out with DNS Resolution Failed. Ubuntu 20.04.5 LTS My current yml. Logs : |
|
@dcliff9 no dns problems per log can be seen |
Thank you. Yes. That is correct. Nonetheless, I'm getting "DNS Resolution Failed" failures. The container gets marked as unhealthy after the 3rd failure. Pinging google.com from inside the container gives name resolution failures. When using 4.0, I do get this output which seems contradictory.
|
|
On Mac with Docker v20.10.22 and having the exact same issues. seccomp nor manually overriding dns either in docker compose or docker run does nothing to fix it.
Worth noting this worked for a little while when my Mac was using default ISP DNS and the whole docker application was running through the PIA desktop app. Since changing Mac DNS, now refuses to resolve on any Wi-Fi network even with the desktop VPN running. Any advice much appreciated! |
|
@haugene worth reopening maybe? None of the fixes have worked for me. |
|
Adding to @Nosh118 , I'm having the exact same issue |
|
I upgraded to Ubuntu 22.04 and have had this hanging issue ever since then, to the point that I've moved away from this image and using 2 separate VPN and qBittorrent images :( |
|
If I have understood this correctly you're all facing this issue with versions of the image that are 4.3 and above, right? It works with the 3.7.1, 4.0, 4.1 and 4.2 tags? If the move to Before then, I'm curious to see if a newer version of the ubuntu base image might fix something. It's a long shot but... |
|
I've been using your latest image for months now (update every week or so) but only started to see the issue when I upgraded my home Linux server from Ubuntu 20.04 to 22.04 where Docker (v23.0.1) is running and hosting your image. I didn't try downgrading your image to an earlier one to test. Let me try with the :kinetic tag now. All configured now and working, I'll do a test download of something to see how it behaves. Edit: seems to be working (tho the settings pages are all blank so cant change anything? Maybe a Flood WEB_UI thing?) - will keep an eye on it for a few days and see if I get the hanging again |
|
In addition to the |
|
I tried both focal and kinetic with same results. It was working fine yesterday, guess got updated with watchtower. Here is the loop log it gets stuck with: Starting container with revision: b33d0fe |
|
The commit from your logs are not from kinetic or focal @jrodmonaco, but the logs are exactly the same when running with those tag? EDIT: And what does your docker run/compose setup look like? |
|
On kinetic: still getting the hanging, web interface not responsive and even trying to stop/kill the container gives me a 500 error and its stuck again. |
|
Just an update, I upgraded my home linux server to ubuntu 22.10 (kinetic) and went back to using your :latest tag and everything seems fine now - so maybe an issue on my side with 22.04+docker interaction? (the docker version is the same - 23.0.1) |
|
Hey @haugene Been running into this issue with OMV6 (6.3.10-2 (Shaitan) Linux 6.1.0-0.deb11.6-amd64) and I am using Docker 23.0.6 with the Kinetic image tag. Here is my docker run And I am continuing to see Anything additional I can provide to help troubleshoot or do you have any suggestions for a workaround? |
|
2023-05-09T21:20:24.528526387Z curl: (6) Could not resolve host: www.privateinternetaccess.com https://haugene.github.io/docker-transmission-openvpn/faq/#error_resolving_host_address |
Where di dyou include this in unraid? I have yet to get this resolved. It constantly restarts. thank you for taking the time. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
stale
bot
added
the
inactivity
|
Feel free to re-open this issue if you think it deserves another look. |
|
Thank you for this comment @haugene, this fixed my problem. I've been struggling with this for an embarrassing amount of time.
In the end I just ran |
|
I am having the same issue on OMV7 with Rock5B. Pihole container runs fine. Not sure what's causing the issue. |
and others
Is there a pinned issue for this?
Is there an existing or similar issue/discussion for this?
Is there any comment in the documentation for this?
Is this related to a provider?
Are you using the latest release?
Have you tried using the dev branch latest?
Docker run config used
"env_variables" : [
{
"key" : "PATH",
"value" : "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
},
{
"key" : "OPENVPN_USERNAME",
"value" : "xxxxxxxxxxxx"
},
{
"key" : "OPENVPN_PASSWORD",
"value" : "xxxxxxxxxxxxxx"
},
{
"key" : "OPENVPN_PROVIDER",
"value" : "NORDVPN"
},
{
"key" : "GLOBAL_APPLY_PERMISSIONS",
"value" : "true"
},
{
"key" : "TRANSMISSION_HOME",
"value" : "/config/transmission-home"
},
{
"key" : "TRANSMISSION_RPC_PORT",
"value" : "9091"
},
{
"key" : "TRANSMISSION_RPC_USERNAME",
"value" : "xxxx"
},
{
"key" : "TRANSMISSION_RPC_PASSWORD",
"value" : "xxxxx"
},
{
"key" : "TRANSMISSION_DOWNLOAD_DIR",
"value" : "/data/completed"
},
{
"key" : "TRANSMISSION_INCOMPLETE_DIR",
"value" : "/data/incomplete"
},
{
"key" : "TRANSMISSION_WATCH_DIR",
"value" : "/data/watch"
},
{
"key" : "CREATE_TUN_DEVICE",
"value" : "true"
},
{
"key" : "ENABLE_UFW",
"value" : "false"
},
{
"key" : "UFW_ALLOW_GW_NET",
"value" : "false"
},
{
"key" : "UFW_DISABLE_IPTABLES_REJECT",
"value" : "false"
},
{
"key" : "PEER_DNS",
"value" : "true"
},
{
"key" : "PEER_DNS_PIN_ROUTES",
"value" : "true"
},
{
"key" : "WEBPROXY_ENABLED",
"value" : "false"
},
{
"key" : "WEBPROXY_PORT",
"value" : "8888"
},
{
"key" : "LOG_TO_STDOUT",
"value" : "false"
},
{
"key" : "HEALTH_CHECK_HOST",
"value" : "google.com"
},
{
"key" : "SELFHEAL",
"value" : "false"
},
{
"key" : "REVISION",
"value" : "de6ec44c4a92311ae0c5ddf72f42bda58cfde20b"
},
{
"key" : "TRANSMISSION_WEB_UI",
"value" : "transmission-web-control"
},
{
"key" : "NORDVPN_PROTOCOL",
"value" : "TCP"
},
{
"key" : "NORDVPN_COUNTRY",
"value" : "DE"
},
{
"key" : "NORDVPN_CATEGORY",
"value" : "P2P"
},
{
"key" : "TRANSMISSION_RPC_AUTHENTICATION_REQUIRED",
"value" : "true"
}
],
"exporting" : false,
"id" : "983339de25d62c75bb11f9ae2591b947ac5f96c12c7f6e4bca7c9cd099270c7c",
"image" : "haugene/transmission-openvpn:latest",
"is_ddsm" : false,
"is_package" : false,
"links" : [],
"memory_limit" : 0,
"name" : "haugene-transmission-openvpn2-copy",
"network" : [
{
"driver" : "bridge",
"name" : "bridge"
}
],
"network_mode" : "bridge",
"port_bindings" : [
{
"container_port" : 8888,
"host_port" : 32770,
"type" : "tcp"
},
{
"container_port" : 9091,
"host_port" : 32771,
"type" : "tcp"
}
],
"privileged" : false,
"shortcut" : {
"enable_shortcut" : false,
"enable_status_page" : false,
"enable_web_page" : false,
"web_page_url" : ""
},
"use_host_network" : false,
"volume_bindings" : [
{
"host_absolute_path" : "45e563424b4ea969f25932686cb930fffc58d64a57983a8756e31fb42ea174c9",
"mount_point" : "/config",
"type" : "rw"
},
{
"host_absolute_path" : "247afe71284bcaabcce112cc7f0ca6dcf79cd5ee34745e81efeaff348cb6cf53",
"mount_point" : "/data",
"type" : "rw"
},
{
"host_volume_file" : "/video/complete",
"mount_point" : "/data/completed/PROWLARR",
"type" : "rw"
},
{
"host_volume_file" : "/video/complete/PROWLARR",
"mount_point" : "/data/completed",
"type" : "rw"
},
{
"host_volume_file" : "/docker/transmission-openvpn/resolv.conf",
"mount_point" : "/etc/resolv.conf",
"type" : "ro"
},
{
"host_volume_file" : "/video/complete/series",
"mount_point" : "/data/completed2",
"type" : "rw"
}
]
}
Current Behavior
Since latest update, I am getting this error on my Synology :
Starting container with revision: de6ec44 | stdout
WARNING: initial DNS resolution test failed
Creating TUN device /dev/net/tun
Using OpenVPN provider: NORDVPN
Running with VPN_CONFIG_SOURCE auto
Provider NORDVPN has a bundled setup script. Defaulting to internal config
Executing setup script for NORDVPN
INFO: OVPN: Checking curl installation
dig: parse of /etc/resolv.conf failed
Expected Behavior
Return back to normal (it had been working flawlessly for years)
How have you tried to solve the problem?
Tried updating and applying
OVERRIDE_DNS_1=8.8.8.8
OVERRIDE_DNS_2=8.8.4.4
but it says the conf file is read only...
Log output
Starting container with revision: de6ec44 | stdout
WARNING: initial DNS resolution test failed
Creating TUN device /dev/net/tun
Using OpenVPN provider: NORDVPN
Running with VPN_CONFIG_SOURCE auto
Provider NORDVPN has a bundled setup script. Defaulting to internal config
Executing setup script for NORDVPN
INFO: OVPN: Checking curl installation
dig: parse of /etc/resolv.conf failed
HW/SW Environment
Anything else?
No response
The text was updated successfully, but these errors were encountered: