-
Notifications
You must be signed in to change notification settings - Fork 896
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
can you rebuild docker.io/elementsproject/lightningd ? #4795
Comments
Sounds like something that we might want to look into. Can you try and see how resolution is configured in a non-lightningd container and a lightningd container (presumably using Depending on how these differ we might have a better idea on how to fix this up in the docker image. |
all pods have a however, the question of query with FQDN / without FQDN does not matter in my tests, DNS works in the container or it does not. testing with |
It seems indeed like the kubernetes DNS resolution may have some issues with alpine containers:
I'll look into how we can address that without requiring changes to the kubernetes config. |
yes, I've found many issues with this and many hint to musl and/or busybox. ... that is, to the "core" of Alpine and the reason why its so small and efficient. Yet your Dockerfile uses buster-slim ... so I am not sure this is it - unless this slimification switches to busybox and/or some other libc ...? That I can't tell. thanks for looking |
here is a Dockerfile based on that new Debian Bullseye - so far it does not appear to have this DNS issue btw: is there a particular reason why your Dockerfile builds static binaries? I did not do that and it runs fine so far
|
Issue and Steps to Reproduce
DNS lookups fail in the container, when running on a k3s cluster. As a consequence lightningd fails to connect to bitcoind.
I do have (many) containers that use the clusters DNS just fine... so its not the cluster per se. This far I tracked the issue down to versions of Alpine where DNS succeeds or fails depending on the Alpine version chosen. This test I did with running a alpine shell as a sidecar to the lightningd container - so I am right in the same pod (same host, same virtual nic, same packet filter rules that apply ...) - an I can toggle whether name lookups succeed or not.
From alpine I know there have been many updates on the resolving library in their busybox core ... I have no idea what Debian does or does not here, but given they have a newer build than current
elementsproject/lightningd:latest
points to, I think its worth doing.also: does it need to be
buster
? Perhaps lightningd works just fine on a newer release?The text was updated successfully, but these errors were encountered: