mdns: mdns lookup error: failed to bind to any unicast udp port mdns.go:139

[fiatjaf]

Version information:

go-ipfs version: 0.4.18-
Repo version: 7
System version: amd64/linux
Golang version: go1.11.1

Type:

Bug

Description:

When I start the daemon I always see this error. I would like mdns to work in the near future, but haven't tried using it yet. Since I'm seeing this error, I assume it doesn't work.

[Stebalien]

This error happens when you're running another daemon using mDNS. The fix is to, apparently, set the REUSEPORT option on our mDNS listener.

[fiatjaf]

Apparently I was indeed.

[fiatjaf]

This happened because of a bug in my systemd configurations. I would prefer to not having two IPFS daemons running at the same time on the same ports. Isn't it better to not start one if other is already running?

[Stebalien]

We run multiple daemons all the time, e.g., when testing or when multiple users are using the same machine. However, you shouldn't be able to run multiple daemons with the repo path. I believe we also fail on start if another daemon is using our API port.

[Kcchouette]

I have this bug after ~20 minutes of starting IPFS through go-ipfs (ipfs version 0.4.20).

I don't know if I have another daemon mDNS, but I only have one instance ipfs started and have this problem.

[Stebalien]

Closing in favor of libp2p/go-libp2p#623 (which includes "allow multiple MDNS applications" as a requirement).

[ravenlandpush]

I have this bug after 20 minutes of starting ipfs too. Please fix this, this 'bug' is encountered in situations even when there is a single IPFS daemon running on port 4001 with no other daemon running.

Although restarting go-ipfs resolves the error, it stands to reason if port 4001 is seen as 'filtered' or if ipfs-go is capable of detecting that it cannot bind to the port, it should take some action like reforking itself so that it is bound, instead of just sit their polling the error for eternity doing nothing.'

I could write something to fix this by logging to a file with nohup or something like nmap port detection, but , much like ipfs pin jobs, this is not a 'solution' to the cause, it's a patch to the problem. What is the best proposition to fix this at present?

Surely there is better approach, or a way to fix this, its fairly critical is it not? If some ipfs servers are likely literally sitting offline unbeknownst of this issue or what it means. Is there not a failsafe way to ensure that port gets re-used in ipfs configuration?

Best wishes,
Adam

[Stebalien]

I don't think we're talking about the same issue. This issue is about not being able to bind to to the multicast address for local MDNS. Please open a new issue so we can figure out what's going wrong.