docker-emulatorjs
docker-emulatorjs copied to clipboard
[BUG] Downloads Fail on hosts with IPv4/IPv6 dual stack
Is there an existing issue for this?
- [X] I have searched the existing issues
Current Behavior
When you attempt to download the initial resources the system seems to try and connect to localhost:5001 , however on hosts with dual stack (IPv4/IPv6) networks the connection gives an error connecting to port 5001 on ::1 (IPv6 localhost) because the API server is not binding to the IPv6 host.
Expected Behavior
API server binds to port 5001 on both IPv4 and IPv6
Steps To Reproduce
- Deploy in dual stack environment
- Attempt to download resources
- Receive error due to failure to connect on port 5001 to host ::1
Environment
- OS: K8S v1.27.6
CPU architecture
x86-64
Docker creation
name: emulatorjs-deployment
namespace: emulatorjs
labels:
app: emulatorjs
spec:
selector:
matchLabels:
app: emulatorjs
replicas: 1
revisionHistoryLimit: 0 # Default to 10 if not specified
strategy:
type: Recreate
template:
metadata:
labels:
app: emulatorjs
spec:
containers:
- name: emulatorjs
image: linuxserver/emulatorjs
ports:
- name: web
containerPort: 80
protocol: TCP
- name: config
containerPort: 3000
protocol: TCP
env:
- name: PUID
value: "1000"
- name: PGID
value: "1000"
- name: TZ
value: "America/New_York"
volumeMounts:
- name: local-conf
mountPath: /etc/sysctl.d/local.conf
subPath: local.conf
- name: emulatorjs-data
mountPath: /data
- name: emulatorjs-config
mountPath: /config
livenessProbe:
httpGet:
path: /
port: 80
scheme: HTTP
initialDelaySeconds: 120
periodSeconds: 90
securityContext:
fsGroup: 1000
volumes:
- name: emulatorjs-data
persistentVolumeClaim:
claimName: emulatorjs-data
- name: emulatorjs-config
persistentVolumeClaim:
claimName: emulatorjs-config
- name: local-conf
configMap:
name: local-conf
Container logs
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready
[ls.io-init] done.
node:internal/deps/undici/undici:11372
Error.captureStackTrace(err, this);
^
TypeError: fetch failed
at Object.fetch (node:internal/deps/undici/undici:11372:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
cause: Error: connect ECONNREFUSED ::1:5001
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1555:16) {
errno: -111,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '::1',
port: 5001
}
}
Node.js v18.18.2
Removing ::1 temporarily from /etc/hosts allows you to bypass the issue, however since Kubernetes controls that file it must be done manually each time you deploy the software.
Can this be replicated with docker? We've not experienced the same issue in testing. K8s isn't a supported platform by us : https://docs.linuxserver.io/misc/support-policy/#reasonable-endeavours-support
I have not replicated it in docker, however I found a fix for the issue. If the API line in /data/.ipfs/config is updated to read: "API": ["/ip4/127.0.0.1/tcp/5001","/ip6/::1/tcp/5001"], then the issue is resolved.
At this point I have made that change manually which is persistent. Obviously it would be more ideal for that to be in the upstream if the change does not impact your Docker build.
I can confirm that this is an issue with docker running a ULA IPv6 address. As a workaround I just disabled IPv6 in my container with
sysctls: - net.ipv6.conf.all.disable_ipv6=1
Disabling IPv6 is not an option in our environment because it would impact other containers which use it. I am using the patch I suggested for now.On Dec 2, 2023, at 2:17 PM, RedPine404 @.***> wrote: I can confirm that this is an issue with docker running a ULA IPv6 address. As a workaround I just disabled IPv6 in my container with sysctls: - net.ipv6.conf.all.disable_ipv6=1
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
Would you consider patching the API line in /data/.ipfs/config is updated to read: "API": ["/ip4/127.0.0.1/tcp/5001","/ip6/::1/tcp/5001"] to prevent this issue?
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.