starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 11:15:54 +03:00

[GH-ISSUE #2169] Handle sockets that have been shut down #909

New issue

Closed

opened 2026-03-16 00:50:34 +03:00 by kerem · 5 comments

kerem commented

2026-03-16 00:50:34 +03:00

Owner

Originally created by @dlon on GitHub (Mar 9, 2024).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2169

Describe the bug
This error is logged indefinitely after a socket used by a ServerFuture has been shut down: [WARN] error receiving message on udp_socket: Socket is not connected (os error 57).

To Reproduce
Create a new ServerFuture and register a UDP socket using ServerFuture::register_listener. Call pid_shutdown_sockets() to shut down all sockets owned by the server process.

Expected behavior
The server should stop trying to receive data and return an error. Alternatively, the socket should be replaced.

System:

OS: macOS
rustc version: any

Version:
Crate: server
Version: 0.23.0

Originally created by @dlon on GitHub (Mar 9, 2024). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/2169 **Describe the bug** This error is logged indefinitely after a socket used by a `ServerFuture` has been shut down: `[WARN] error receiving message on udp_socket: Socket is not connected (os error 57)`. **To Reproduce** Create a new `ServerFuture` and register a UDP socket using `ServerFuture::register_listener`. Call `pid_shutdown_sockets()` to shut down all sockets owned by the server process. **Expected behavior** The server should stop trying to receive data and return an error. Alternatively, the socket should be replaced. **System:** - OS: macOS - rustc version: any **Version:** Crate: server Version: 0.23.0

kerem closed this issue

2026-03-16 00:50:39 +03:00

kerem commented

2026-03-16 00:50:45 +03:00

Author

Owner

@djc commented on GitHub (Mar 9, 2024):

Why are closing all of the process sockets like that? What is the purpose of doing so?

@djc commented on GitHub (Mar 9, 2024): Why are closing all of the process sockets like that? What is the purpose of doing so?

kerem commented

2026-03-16 00:50:50 +03:00

Author

Owner

@dlon commented on GitHub (Mar 9, 2024):

I've seen sockets being closed/shutdown randomly on a few machines, but I can't tell you why. It might be something that the OS is doing. Regardless, it probably makes no sense to continue to receive/send on them, right?

@dlon commented on GitHub (Mar 9, 2024): I've seen sockets being closed/shutdown randomly on a few machines, but I can't tell you why. It might be something that the OS is doing. Regardless, it probably makes no sense to continue to receive/send on them, right?

kerem commented

2026-03-16 00:50:55 +03:00

Author

Owner

@bluejekyll commented on GitHub (Mar 9, 2024):

Seems like we should be treating this error differently, but, if the server socket is closing, that would imply the server can no longer be used. It would need to reopen the Socket. What is closing the socket?

To be clear, the socket registered as part of "register_listener" should be live as long as the server itself and never be closed until the server is shutdown.

@bluejekyll commented on GitHub (Mar 9, 2024): Seems like we should be treating this error differently, but, if the server socket is closing, that would imply the server can no longer be used. It would need to reopen the Socket. What is closing the socket? To be clear, the socket registered as part of "register_listener" should be live as long as the server itself and never be closed until the server is shutdown.

kerem commented

2026-03-16 00:51:00 +03:00

Author

Owner

@dlon commented on GitHub (Mar 11, 2024):

Would it make sense to simply break in the case where ENOTCONN is returned here? (This probably needs to be handled for the non-UDP cases as well.)

I suspect that this issue might occur when the process is suspended under some circumstances. Can't tell you what they are since I haven't been able to reproduce this myself, so I'm just speculating.

Arguably, this case should be handled regardless, since any process (running as root) can call pid_shutdown_sockets to close the sockets. There's no way to gracefully handle this at the moment.

@dlon commented on GitHub (Mar 11, 2024): Would it make sense to simply break in the case where `ENOTCONN` is returned [here](https://github.com/hickory-dns/hickory-dns/blob/main/crates/server/src/server/server_future.rs#L96)? (This probably needs to be handled for the non-UDP cases as well.) I suspect that this issue might occur when the process is suspended under some circumstances. Can't tell you what they are since I haven't been able to reproduce this myself, so I'm just speculating. Arguably, this case should be handled regardless, since any process (running as root) *can* call `pid_shutdown_sockets` to close the sockets. There's no way to gracefully handle this at the moment.

kerem commented

2026-03-16 00:51:05 +03:00

Author

Owner

@djc commented on GitHub (Mar 11, 2024):

Yes, breaking out of the loop for that scenario seems reasonable. Would you be able to send a PR for that?

@djc commented on GitHub (Mar 11, 2024): Yes, breaking out of the loop for that scenario seems reasonable. Would you be able to send a PR for that?

kerem referenced this issue

2026-03-16 02:25:12 +03:00

[PR #909] [MERGED] Bump smallvec from 0.6.10 to 1.0.0 #1781