starred/hickory-dns

Fork 0

mirror of https://github.com/hickory-dns/hickory-dns.git synced 2026-04-25 03:05:51 +03:00

[GH-ISSUE #653] trust-dns seems to leak udp connections #266

New issue

Closed

opened 2026-03-07 23:07:14 +03:00 by kerem · 4 comments

kerem commented

2026-03-07 23:07:14 +03:00

Owner

Originally created by @kpcyrd on GitHub (Jan 9, 2019).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/653

Describe the bug
I might be doing something wrong here, but it seems trust-dns doesn't close udp sockets correctly:

[*] #73 resolving...
[*] #74 resolving...
[*] #75 resolving...
[*] #76 resolving...
[*] #77 resolving...
[*] #78 resolving...
thread 'main' panicked at 'Runtime::new: Os { code: 24, kind: Other, message: "Too many open files" }', libcore/result.rs:1009:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

If you add a sleep to the loop and run watch -n1 lsof -nPi you can see that the binary is opening a lot of udp sockets but never closes them.

To Reproduce
A dirty reproducer extracted from my code:

use futures::{future, Future};
use trust_dns::rr::{DNSClass, Name};
use trust_dns::rr::RecordType;
use tokio::runtime::Runtime;
use trust_dns::client::ClientHandle;
use trust_dns::client::{Client, ClientConnection, SyncClient};
use trust_dns::udp::UdpClientConnection;


fn resolve_with<T>(conn: T, name: Name, query_type: RecordType)
where
    T: ClientConnection,
{
    let client = SyncClient::new(conn);
    let (bg, mut client) = client.new_future();

    let query = future::lazy(move || {
        tokio::executor::spawn(bg);
        client
            .query(name, DNSClass::IN, query_type)
    });

    let reply = query.and_then(|_response| {
        // println!("{:?}", response);
        Ok(())
    });

    let mut rt = Runtime::new().expect("Runtime::new");
    rt.block_on(reply).expect("block_on");
}

fn main() {
    let name = "google.com".parse::<Name>().expect("Name::from_str");
    let rt = RecordType::A;

    let mut i = 0;
    loop {
        println!("[*] #{} resolving...", i);
        let addr = "1.1.1.1:53".parse().unwrap();
        let sock = UdpClientConnection::new(addr).unwrap();
        resolve_with(sock, name.clone(), rt);
        i += 1;
    }
}

Expected behavior
The program should close udp sockets after use. Creating the UdpClientConnection inside the loop is probably one of the reasons it's running out of file descriptors, but this shouldn't case a leak of the file descriptor.

System:

OS: Linux
Architecture: x86_64
rustc version: 1.31.1

Version:
Crate: trust-dns
Version: 0.15.0

Originally created by @kpcyrd on GitHub (Jan 9, 2019). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/653 **Describe the bug** I might be doing something wrong here, but it seems trust-dns doesn't close udp sockets correctly: ``` [*] #73 resolving... [*] #74 resolving... [*] #75 resolving... [*] #76 resolving... [*] #77 resolving... [*] #78 resolving... thread 'main' panicked at 'Runtime::new: Os { code: 24, kind: Other, message: "Too many open files" }', libcore/result.rs:1009:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. ``` If you add a sleep to the loop and run `watch -n1 lsof -nPi` you can see that the binary is opening a lot of udp sockets but never closes them. **To Reproduce** A dirty reproducer extracted from my code: ```rust use futures::{future, Future}; use trust_dns::rr::{DNSClass, Name}; use trust_dns::rr::RecordType; use tokio::runtime::Runtime; use trust_dns::client::ClientHandle; use trust_dns::client::{Client, ClientConnection, SyncClient}; use trust_dns::udp::UdpClientConnection; fn resolve_with<T>(conn: T, name: Name, query_type: RecordType) where T: ClientConnection, { let client = SyncClient::new(conn); let (bg, mut client) = client.new_future(); let query = future::lazy(move || { tokio::executor::spawn(bg); client .query(name, DNSClass::IN, query_type) }); let reply = query.and_then(|_response| { // println!("{:?}", response); Ok(()) }); let mut rt = Runtime::new().expect("Runtime::new"); rt.block_on(reply).expect("block_on"); } fn main() { let name = "google.com".parse::<Name>().expect("Name::from_str"); let rt = RecordType::A; let mut i = 0; loop { println!("[*] #{} resolving...", i); let addr = "1.1.1.1:53".parse().unwrap(); let sock = UdpClientConnection::new(addr).unwrap(); resolve_with(sock, name.clone(), rt); i += 1; } } ``` **Expected behavior** The program should close udp sockets after use. Creating the UdpClientConnection inside the loop is probably one of the reasons it's running out of file descriptors, but this shouldn't case a leak of the file descriptor. **System:** - OS: Linux - Architecture: x86_64 - rustc version: 1.31.1 **Version:** Crate: trust-dns Version: 0.15.0

kerem

2026-03-07 23:07:14 +03:00

closed this issue
added the
crate:client

question
labels

kerem commented

2026-03-07 23:07:30 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 10, 2019):

Ah... The SyncClient isn't meant to be used in Futures/Tokio context, it handles all of that internally. The new_future function really should be private, but is part of the a Trait interface. I might see if that can be hidden so that it doesn't lead people down the wrong path. Sadly we don't have any examples for this, we should add some. Here are some test cases though that should better show how to use the SyncClient:

Construct: https://github.com/bluejekyll/trust-dns/blob/master/tests/integration-tests/tests/client_tests.rs#L85
Use: https://github.com/bluejekyll/trust-dns/blob/master/tests/integration-tests/tests/client_tests.rs#L102

I hope that helps!

@bluejekyll commented on GitHub (Jan 10, 2019): Ah... The `SyncClient` isn't meant to be used in Futures/Tokio context, it handles all of that internally. The new_future function really should be private, but is part of the a Trait interface. I might see if that can be hidden so that it doesn't lead people down the wrong path. Sadly we don't have any examples for this, we should add some. Here are some test cases though that should better show how to use the SyncClient: Construct: https://github.com/bluejekyll/trust-dns/blob/master/tests/integration-tests/tests/client_tests.rs#L85 Use: https://github.com/bluejekyll/trust-dns/blob/master/tests/integration-tests/tests/client_tests.rs#L102 I hope that helps!

kerem commented

2026-03-07 23:07:35 +03:00

Author

Owner

@kpcyrd commented on GitHub (Jan 10, 2019):

Oh, I see! After looking at the differences I think this was because I scheduled the background task on the default executor. Since the default executor is never shutdown the socket is never closed.

I think I remember why I did it this way though: I was actually looking for an async Client but couldn't find one. In addition I don't have a reference to the Runtime since I'm running the resolve inside a hyper connector. Creating a new Runtime inside a tokio Runtime causes a panic.

Is there a reason the background task is needed? It would be easier for me if creating a Client simply returns a FutureClient that I can chain with and_then, without needing a reference to Runtime or Handle.

Thanks!

@kpcyrd commented on GitHub (Jan 10, 2019): Oh, I see! After looking at the differences I think this was because I scheduled the background task on the default executor. Since the default executor is never shutdown the socket is never closed. I think I remember why I did it this way though: I was actually looking for an async `Client` but couldn't find one. In addition I don't have a reference to the `Runtime` since I'm running the resolve inside a hyper connector. Creating a new Runtime inside a tokio Runtime causes a panic. Is there a reason the background task is needed? It would be easier for me if creating a Client simply returns a `FutureClient` that I can chain with `and_then`, without needing a reference to `Runtime` or `Handle`. Thanks!

kerem commented

2026-03-07 23:07:40 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 10, 2019):

If you want an Async client, here's the best example I have: https://github.com/bluejekyll/trust-dns/blob/master/tests/integration-tests/tests/client_future_tests.rs#L66

Also, there was a UdpConnection leak in the Resolver library. That may also effect the Client library, but I don't currently plan on backporting that. I'll be publishing 0.16 alpha releases soon.

@bluejekyll commented on GitHub (Jan 10, 2019): If you want an Async client, here's the best example I have: https://github.com/bluejekyll/trust-dns/blob/master/tests/integration-tests/tests/client_future_tests.rs#L66 Also, there was a UdpConnection leak in the Resolver library. That may also effect the Client library, but I don't currently plan on backporting that. I'll be publishing 0.16 alpha releases soon.

kerem commented

2026-03-07 23:07:46 +03:00

Author

Owner

@bluejekyll commented on GitHub (Jan 19, 2019):

FYI, I'm going to close this, 0.16.0.alpha.1 has the UDP connection leak fix from the Resolver 0.10.2 release.

@bluejekyll commented on GitHub (Jan 19, 2019): FYI, I'm going to close this, 0.16.0.alpha.1 has the UDP connection leak fix from the Resolver 0.10.2 release.

kerem referenced this issue

2026-03-15 22:26:45 +03:00

[GH-ISSUE #266] Enable IPv6-specific tests by default, disable explicitly when running on Travis CI #425