I believe that if the port has pre ious connections still in the CLOSE_WAIT state (could be a previous run of the same app) the port cannot be opened.
Linux also has a REUSE_PORT option that allows multiple processes to bind to the same port and it balances the incoming requests automatically. On Nov 18, 2025, at 3:36 AM, 'Brian Candler' via golang-nuts <[email protected]> wrote:
When the problem occurs, I suggest you look at "ss -natp" ("netstat -natp" on older systems) and see if you really do have two listening sockets on the same port and address.
If you do, that seems like a kernel bug / some sort of race. What kernel version is the VM running? (The kernel on the physical host shouldn't really make any difference).
On Tuesday, 18 November 2025 at 03:11:24 UTC Zhang Jie (Kn) wrote:
Hello everyone, Over the past year, I've encountered two strange issues with net.ListenTCPand listener.Accept. Without explicitly enabling reuseport, multiple service processes on the same machine, all searching for available ports starting from 9000, managed to successfully call listenon the same IP and port. At least when calling net.ListenTCP, it returned err == nil, and the error only appeared during listener.Accept. However, at the time, we weren't explicitly checking the returned error or printing the error message. Instead, when we found the returned conn == nil, we kept retrying listener.Acceptin a for-loop. We've reproduced this issue twice within a year. The environment was a virtual machine allocated on a physical host with a Linux 5.4 kernel, and it was very difficult to reproduce. Our immediate fix was to add the error checking logic and print the specific error. While handling this issue, we also ran into the problem with netError.Temporary(). I completely agree with Ian's insight: "Whether an error is temporary depends on what you were doing at the time." For the specific case of listener.Accept(), even if netError.Temporary()returns true, retrying doesn't necessarily mean the service can remain available. Errors always manifest in wildly different ways. In our specific flawed usage scenario, the service had already successfully registered with the name service, and other services had already discovered it and started sending requests. However, because the listenwasn't actually successful (the IP:port was held by another process), it resulted in persistent access failures. But if we don't use Temporary(), asking developers to enumerate all possible temporary errors that can be retried isn't a very straightforward task. Could several categorical functions, similar to IsTimeout, be provided to allow developers to combine them freely? For example, something like if ne.IsTimeout() || ne.IsXXX() || ne.IsYYY().
On Friday, April 22, 2022 at 6:39:39 AM UTC+8 Caleb Spare wrote:
On Thu, Apr 21, 2022 at 7:16 AM 'Bryan C. Mills' via golang-nuts
<[email protected]> wrote:
>
> Even ENFILE and EMFILE are not necessarily blindly retriable: if the process has run out of files, it may be because they have leaked (for example, they may be reachable from deadlocked goroutines).
> If that is the case, it is arguably better for the program to fail with a useful error than to keep retrying without making progress.
>
> (I would argue that the retry loop in net/http.Server is a mistake, and should be replaced with a user-configurable semaphore limiting the number of open connections — thus avoiding the file exhaustion in the first place!)
ENFILE might be caused by a different process entirely, no?
>
> On Wednesday, April 20, 2022 at 10:49:20 PM UTC-4 Ian Lance Taylor wrote:
>>
>> On Wed, Apr 20, 2022 at 6:46 PM 'Damien Neil' via golang-nuts
>> <[email protected]> wrote:
>> >
>> > The reason for deprecating Temporary is that the set of "temporary" errors was extremely ill-defined. The initial issue for https://go.dev/issue/45729 discusses the de facto definition of Temporary and the confusion resulting from it.
>> >
>> > Perhaps there's a useful definition of temporary or retriable errors, perhaps limited in scope to syscall errors such as EINTR and EMFILE. I don't know what that definition is, but perhaps we should come up with one and add an os.ErrTemporary or some such. I don't think leaving net.Error.Temporary undeprecated was the right choice, however; the need for a good way to identify transient system errors such as EMFILE doesn't mean that it was a good way to do so or could ever be made into one.
>>
>> To frame issue 45729 in a different way, whether an error is temporary
>> is not a general characteristic. It depends on the context in which
>> it appears. For the Accept loop in http.Server.Serve really the only
>> plausible temporary errors are ENFILE and EMFILE. Perhaps the net
>> package needs a RetriableAcceptError function.
>>
>> Ian
>>
>>
>>
>> > On Wednesday, April 20, 2022 at 6:02:34 PM UTC-7 [email protected] wrote:
>> >>
>> >> In Go 1.18 net.Error.Temporary was deprecated (see
>> >> https://go.dev/issue/45729). However, in trying to remove it from my
>> >> code, I found one way in which Temporary is used for which there is no
>> >> obvious replacement: in a TCP server's Accept loop, when deciding
>> >> whether to wait and retry an Accept error.
>> >>
>> >> You can see an example of this in net/http.Server today:
>> >> https://github.com/golang/go/blob/ab9d31da9e088a271e656120a3d99cd3b1103ab6/src/net/http/server.go#L3047-L3059
>> >>
>> >> In this case, Temporary seems useful, and enumerating the OS-specific
>> >> errors myself doesn't seem like a good idea.
>> >>
>> >> Does anyone have a good solution here? It doesn't seem like this was
>> >> adequately considered when making this deprecation decision.
>> >>
>> >> Caleb
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
>> > To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1024e668-795f-454f-a659-ab5a4bf9517cn%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1826b3b5-c147-4015-9769-984fd84eacb3n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/86d641cd-4503-4568-b491-f82b5fa705c9n%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/F299663A-558E-494F-BAE3-82871EC936B5%40me.com.
|
