[Bug network/984] Respond to changed resolv.conf in gethostbyname

["swormuth at icloud dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=984

swormuth at icloud dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |swormuth at icloud dot com

--- Comment #14 from swormuth at icloud dot com ---
I am having the same issue with CrashPlan.  The backup engine service fails
because there is no connection on boot.  Here is the text from the support
representative.  Any thoughts would be appreciated.

==========================================================================

Thanks for your patience on this. Our inquiry wound it's way to the Tier 3
Engineers and the Engineering department. What you are experiencing is a bug in
Linux... depending on who you ask. RedHat thinks it is working as expected,
everyone else thinks it's a bug. Go figure!

Here's what is going on (just a warning, things get pretty jargon-y):

When a process (like CrashPlan), makes its first DNS request, glibc reads the
list of DNS servers from /etc/resolv.conf. If networks are chosen after boot,
or dynamically with DHCP, the /etc/resov.conf may be empty. This means that
applications that don't re-initialize their name severs will be stuck with
nothing, and will not be able to resolve addresses.

RedHat's stance on this is that it is up to the application to handle this
re-initialization logic. For short lived programs (ping for example), this
isn't a big deal because once they are run again, there is usually a name
server for resolution. For long-running daemons, such as the CrashPlan Engine,
they never re-intialize the name servers, and cannot connect. Restarting the
service with a connection, and therefore a nameserver, gets things rolling
again - which is why you notice that a restart resolves the issue.

Notably, Debian based distros use a patched version of glibc that takes care of
this problem.

Unfortunately, as only a very small subset of our users experience this
problem, we have no intentions of changing the logic of our product to account
for how RedHat distributions handle initial name resolution. That leaves you
with 3 options, all of which are beyond CrashPlan's scope of support:

Rebuild glibc with Debian's patch.
Configure NetworkManager to use a local dnsmasq instance.
Switch distros to a Debian-based solution (Debian, Ubuntu, Mint, etc.)
Likewise, CrashPlan may not be the product that fits your use case - and that
is what the trial period is for! We want you to have a backup solution that
works for you.

You may find the glibc bug page interesting, though to be honest I can't make
heads or tails out of it!:

https://sourceware.org/bugzilla/show_bug.cgi?id=984
Though not satisfying, within the context of CrashPlan support I must consider
this ticket resolved, and will mark it as solved. If you have any additional
questions, please let me know!

-- 
You are receiving this mail because:
You are on the CC list for the bug.