Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
(VPN) cannot be resolved, possible DNS issues #70
running this and rtorrent on synology docker, both working fine for many months until last week when i started getting error -
Same error on both deluge and rtorrent. I have tried differnt VPN servers and receive the same error.
NAME_SERVERS addresses from my provider (express) and have always worked. no other addresses. also doesnt work with google or no value.
Same issue when changing setting STRICT_PORT_FORWARD to no
Any help very much appreciated.
EDIT: I have confirmed the tagged release "1.3.15+14+gb8e5ebe82-1-11" works fine. I don't know if one of the later ones might also work.
@binhex - I am not technically knowledgable enough to know what "dig" is or how to tell what your latest release is that doesn't use "dig." Can you assist?
For what it's worth - your container is quite popular among Synology users, so we all appreciate your work.
@napcae ok sure, i would like to get this issue resolved one way or another. firstly can you tell me what kernel you are running, you should be able to find that out by issuing:-
Can you also post the output of the following command (shows version info):-
i suspect you are running an earlier kernel and thus there is an incompatibility with the compiled version of dig and the kernel version (current theory as to why it affects synology users), just to be clear we are not talking about parameters for the dig command, this is a crash of the dig process.
i woud like to look into the crash some more, can you try running the following on your host once the container is running (assuming it stays up and running long enough):-
im hoping you will see some output from that, preferably with the crash, hoping that might give me more of a clue as to whats going on (i cant currently replicate the crash).
also can you try executing drill to see if this also crashes:-
I would also like to help, I run this on Synology:
docker run --rm -it --entrypoint dig binhex/arch-delugevpn:1.3.15_14_gb8e5ebe82-1-15
docker run --rm -it --entrypoint drill binhex/arch-delugevpn:1.3.15_14_gb8e5ebe82-1-15
I hope this can help you, ask for more if you need me to run other commands
docker exec -it drill
Also I'd like to mention that the container doesn't crash, deluge just won't come up, there is only a error message:
so the first interesting fact is that both of you are indeed running an earlier kernel (3.10/3.16)latest stable being 4.18.15 as this time, i dont see any issues on unraid (main platform i support and use myself) and this is probably due to the fact that unraid does indeed keep up with kernel releases, im not at my server right now so i cant tell you the exact version but i think its around 4.10.xx, and this matches with my current theory that the issue is related to earlier kernel versions running a later version of dig.
so onto what we can do to fix this, there are two options:-
i probably will start looking at drill as a replacement, as i can see from the above that drill does indeed work fine on both of your systems, if that gets too tricky to use then i will switch over to static dig.
so the image is now built, please can you guys test it, it has a tag name of "test", so pull down image using:-
then create container as per normal making sure to reference the new image and tag name:-
It works now, although:
Thanks for the fix!
I haven't changed the UID/GID yet but here's the logs from failed :latest.
018-10-19 11:22:44.406054 [info] System information Linux 51bc8f74218f 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 x86_64 GNU/Linux
2018-10-19 11:22:46,564 INFO success: start-script entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2018-10-19 11:22:46,568 DEBG 'deluge-script' stdout output:
2018-10-19 11:22:46,627 DEBG 'start-script' stdout output:
2018-10-19 11:22:46,633 DEBG 'start-script' stdout output:
2018-10-19 11:22:46,636 DEBG 'start-script' stdout output:
2018-10-19 11:22:46,643 DEBG 'start-script' stdout output:
2018-10-19 11:22:46,649 DEBG 'start-script' stdout output:
2018-10-19 11:22:46,653 DEBG 'start-script' stdout output:
2018-10-19 11:22:46,661 DEBG 'start-script' stdout output:
2018-10-19 11:22:46,670 DEBG 'start-script' stderr output:
2018-10-19 11:22:46,674 DEBG 'start-script' stdout output:
2018-10-19 11:22:46,674 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 139676000737544 for <Subprocess at 139676000737832 with name start-script in state RUNNING> (stdout)>
Lol. I do. I thought that it had to do with the update and that the DNS list was being fed from somewhere else. I'm not sure how that got inserted into the docker-compose and it was misleading that everything started reverting when I tagged the older branch. latest is working now. Thanks!