[GH-ISSUE #1097] Too many open files (os error 24) using multiple resolver instances #604

New issue

Closed

opened 2026-03-15 23:23:48 +03:00 by kerem · 2 comments

kerem commented

2026-03-15 23:23:48 +03:00

Owner

Originally created by @Edu4rdSHL on GitHub (May 6, 2020).
Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1097

Describe the bug
I'm having the problem Too many open files when creating a resolver from parts using https://docs.rs/trust-dns-resolver/0.19.5/trust_dns_resolver/struct.Resolver.html. I'm sing the following code:

pub fn get_resolver(resolvers_ips: &Vec<Ipv4Addr>, opts: &ResolverOpts) -> Resolver {
    match Resolver::new(
        ResolverConfig::from_parts(
            None,
            vec![],
            NameServerConfigGroup::from_ips_clear(
                &[IpAddr::V4(
                    resolvers_ips[rand::thread_rng().gen_range(0, resolvers_ips.len())].clone(),
                )],
                53,
            ),
        ),
        *opts,
    ) {
        Ok(resolver) => resolver, 
        Err(e) => {
            error!("Failed to create the resolver. Error: {}\n", e);
            std::process::exit(1)
        }
    }
}

To Reproduce
I call the get_resolver() function everytime I need to do a lookup. The idea is mainly that we use a list of resolver IPs and they are picked randomly.

I suspect that the problem is the Resolver::new, ResolverConfig::from_parts
and NameServerConfigGroup::from_ips_clear calls everytime. Is there an option to just change the resolver IP? That will avoid the need to create a new resolver everytime but just use references.

Expected behavior
No Too many open files (os error 24) error.

System:

OS: ArchLinux
Architecture: x86_64
Version: Not apply.
rustc version: 1.42.0

Version:
Crate: Resolver
Version: 0.19.5

Additional context
The number of resolvers created are up to 500.

Originally created by @Edu4rdSHL on GitHub (May 6, 2020). Original GitHub issue: https://github.com/hickory-dns/hickory-dns/issues/1097 **Describe the bug** I'm having the problem `Too many open files` when creating a resolver from parts using https://docs.rs/trust-dns-resolver/0.19.5/trust_dns_resolver/struct.Resolver.html. I'm sing the following code: ```rust pub fn get_resolver(resolvers_ips: &Vec<Ipv4Addr>, opts: &ResolverOpts) -> Resolver { match Resolver::new( ResolverConfig::from_parts( None, vec![], NameServerConfigGroup::from_ips_clear( &[IpAddr::V4( resolvers_ips[rand::thread_rng().gen_range(0, resolvers_ips.len())].clone(), )], 53, ), ), *opts, ) { Ok(resolver) => resolver, Err(e) => { error!("Failed to create the resolver. Error: {}\n", e); std::process::exit(1) } } } ``` **To Reproduce** I call the get_resolver() function everytime I need to do a lookup. The idea is mainly that we use a list of resolver IPs and they are picked randomly. I suspect that the problem is the `Resolver::new`, `ResolverConfig::from_parts` and `NameServerConfigGroup::from_ips_clear` calls everytime. Is there an option to just change the resolver IP? That will avoid the need to create a new resolver everytime but just use references. **Expected behavior** No `Too many open files (os error 24)` error. **System:** - OS: ArchLinux - Architecture: x86_64 - Version: Not apply. - rustc version: 1.42.0 **Version:** Crate: [Resolver](https://docs.rs/trust-dns-resolver/0.19.5/trust_dns_resolver/struct.Resolver.html) Version: 0.19.5 **Additional context** The number of resolvers created are up to 500.

kerem closed this issue

2026-03-15 23:23:54 +03:00

kerem commented

2026-03-15 23:23:59 +03:00

Author

Owner

@bluejekyll commented on GitHub (May 6, 2020):

Is the Resolver being dropped (either directly or by going out of scope) between each call of get_resolver?

@bluejekyll commented on GitHub (May 6, 2020): Is the Resolver being dropped (either directly or by going out of scope) between each call of get_resolver?

kerem commented

2026-03-15 23:24:04 +03:00

Author

Owner

@Edu4rdSHL commented on GitHub (May 6, 2020):

Hey @bluejekyll, thank you for your quick response. This was just a problem with the OS configuration having a very low number of open files limit.

Closing and sorry.

@Edu4rdSHL commented on GitHub (May 6, 2020): Hey @bluejekyll, thank you for your quick response. This was just a problem with the OS configuration having a very low number of open files limit. Closing and sorry.

kerem referenced this issue

2026-03-16 02:14:21 +03:00

[PR #663] [MERGED] cs0.16 and r0.11 alpha.1 #1582