[DOCS-5700] Call res_init() after a failure of getaddrinfo() Created: 08/Nov/12  Updated: 30/Oct/23  Resolved: 03/Nov/17

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Improvement Priority: Minor - P4
Reporter: David Hows Assignee: Kay Kim (Inactive)
Resolution: Done Votes: 4
Labels: groom
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-12099 getaddrinfo(hostname:port) - Temporar... Closed
Related
related to SERVER-10375 DNS failures can cause a primary-less... Closed
is related to SERVER-12741 mongod on glibc should regularly call... Closed
Participants:
Days since reply: 10 years, 21 weeks, 1 day ago

 Description   

We should call res_init() on Linux systems after failure in getaddrinfo().

Handle cases when the DNS resolver has been changed by resetting the cache.

Should ideally be fixed in glibc but do not think they will as outlined http://sourceware.org/bugzilla/show_bug.cgi?id=3675

====== DOCS CHANGE =======

This is a minor issue effecting DNS on RedHat derivative linux distributions due to an implementation choice in GLIBC in those distributions. The issue is, if you make changes to the DNS resolver underneath MongoDB you will need to restart your database under any RHEL based Linux.

This does not effect Debian derivatives as they use a patched version of GLIBC.



 Comments   
Comment by João Abecasis [ 24/Sep/13 ]

I've just been bit by a issue that would probably have been solved by this.

We're using 10gen/mongodb provided packages and the upstart configuration starts the server in run levels 2, 3, 4 and 5 with no other dependencies. In our case a slow dhcp seems to be racing with mongodb startup to the point where a broken (or non-existing) resolv.conf is sometimes picked up.

In our case, delaying server startup until the network is up, or later in the boot process, would probably help as well.

Comment by Julian Dunn [ 26/Feb/13 ]

I wouldn't characterize it as "recommends". It's a workaround, certainly, but RedHat's own documentation states that "using both services can result in unexpected behavior".

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/usingnscd-sssd.html

Comment by Akshay Kumar [ 26/Feb/13 ]

It is what RedHat recommends for SSSD and is an immediate fix for the problem at hand.

Comment by Julian Dunn [ 26/Feb/13 ]

Well, that's certainly possible, but I just don't think it's a good idea to prescribe to customers what name service caching daemon(s) they have to run in order to use MongoDB. nscd and sssd are known to not coexist well together.

Comment by Akshay Kumar [ 26/Feb/13 ]

What about something like this so you you are using NSCD only for host entries and SSSD handles the rest?

enable-cache hosts yes
enable-cache passwd no
enable-cache group no
enable-cache netgroup no

Comment by Julian Dunn [ 26/Feb/13 ]

Unfortunately, Akshay, nscd conflicts with sssd which is what we use for unified authentication with Active Directory. So this isn't really a solution.

Comment by Akshay Kumar [ 26/Feb/13 ]

You can avoid the whole problem by just running nscd which is already a dependency for NetworkManger, nss-ldap, NIS+ among other things. nscd will discover /etc/resolv.conf changes and invalidate the database.

check-files hosts yes

in nscd.conf

Maybe even add nscd as a package dependency for the mongodb rpms.

Generated at Thu Feb 08 07:50:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.