HAppS web app crashes with error "Main: getNameInfo: does not exist (Temporary failure in name resolution)"

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run the open source app demoed at happstutorial.com:5001 (available on
hackage)
2. Wait a couple of days
3. It will probably crash.

This problem has been discussed on irc. Apparently the root cause of the
problem is not in HAppS but the haskell network library. 

The #happs irc chat below pretty much describes the problem and some
reasonable workarounds.

<thomashartman1> My app seems to be crashing at least once a day. It is
                 logging the error: Main: getNameInfo: does not exist
                 (Temporary failure in name resolution)                 [13:07]
<thomashartman1> Anyone seen this / have advice?                        [13:08]
<Saizan> if i recall correctly it's a bug in the network library related to
         ipv6                                                           [13:13]
<thomashartman1> should I handle this with a try/catch or ...?
<thomashartman1> the current behavior is the app just stops.            [13:14]
<thomashartman1> http://tuukka.iki.fi/tmp/happs-2008-03-08.html seems to
                 discuss the problem... I'm digesting...                [13:16]
<Saizan> yeah, that's the conversation i remembered,

http://www.haskell.org/ghc/docs/latest/html/libraries/network/src/Network.html#a
ccept
         still lacks a catch                                            [13:24]
<thomashartman1> I see lots of griping but no workaround. I think the thing to
                 do is file a bug at the happs bug tracker and do a cron
                 script that starts the app if it's not running every minute.
                                                                        [13:25]
<thomashartman1> also discussed at
                 http://tuukka.iki.fi/tmp/haskell-2008-03-09.html
                                                                        [13:26]
<Saizan> it's a bug of the network package, not of happs
<thomashartman1> right.
<thomashartman1> but it affects happs users for sure.
<thomashartman1> I want people to take happstutorial.com:5001
<thomashartman1>  and do something real with it...
<thomashartman1> be it ever so trivial.
<Saizan> right, but the only reasonable way to fix this is in network   [13:28]
<thomashartman1> yes, but till then at least there should be a workaround.
*** guenni (n=guenni@HSI-KBW-085-216-102-073.hsi.kabelbw.de) has joined
    channel #happs
<Saizan> yes, one could put a catch around the accept call and ignore
         thoserequests                                                  [13:30]
<Saizan> putting a proxy in front of the application should help too, i
         imagine                                                        [13:31]
<thomashartman1> this would involve patching HAppS source right?        [13:33]
<Saizan> yes                                                            [13:34]
<thomashartman1> I wish I knew a way to reproduce this error.
<thomashartman1> Why does HAppS need to resolve dns names anyway?
<Saizan> it's not happs, it's the accept primitive that returns an HostName
                                                                        [13:35]
<thomashartman1> do you know which package that's in?
<thomashartman1> By the way I'm just gonna copy this entire conversation and
                 paste it into the bug report I'm about to file.
<thomashartman1> And yes, I agree it's technically not a happs bug.     [13:36]
<thomashartman1> but... whatever.
<Saizan> "that" what?                                                   [13:38]
<Saizan> however the HostName is also inserted in the Request record    [13:39]
<Saizan> but we could reimplement a non-buggy Network.accept using the lower
         lever Network.Socket.accept and getNameInfo i suppose          [13:40]
<thomashartman1> by "that" I meanth, which package the "accept" call is in.
                                                                        [13:41]
<thomashartman1> sounds reasonable.                                     [13:42]
<Saizan> the relevant accept is in HAppS.Server.HTTP.Listen it seems, in the
         HAppS-Server package 

Original issue reported on code.google.com by thomasha...@gmail.com on 5 Jul 2008 at 8:45

[GoogleCodeExporter]

I don't see the problem with just using Network.Socket.accept for most cases.  I
guess it could be exposed in 'Network', but thats not a big deal.  Does anyone 
at
libraries@h.o consider this a bug in Network?

At any rate, this is certainly what causes my hackage-server process to 
terminate
when DNS is unreachable.  You see a couple arp requests (Who has 
DDD.NNN.SSS.XXX tell
HHH.AAA.PPP.SSS) and once those time out the program terminates immediately - 
no need
to wait a day and forget about operating without a working DNS.

Original comment by Thomas.D...@gmail.com on 24 Sep 2008 at 2:26

[GoogleCodeExporter]

To summarize the problem for casual readers:

- a connection is made to the web server
- the name lookup on the remote address fails
- getNameInfo(3) returns EAI_FAIL
- Network.Socket.getNameInfo throws an IO exception
- Network.accept does not catch the exception
- HAppS does not catch the exception
- the program exits

Note that the exception can only be produced when Network.accept is given a 
socket
with family AF_INET6.  On IPv4 sockets, name-lookup failure results in a normal
return with hostname = inet_ntoa addr.

I agree that the most reasonable solution is to use Network.Socket.accept.  
(Just
catching the exception from Network.accept would require dropping any connection
whose remote address can't be mapped to a name.)

Ideally, I think HAppS.Server.HTTP.Types.Request should be changed to allow 
both the
IP address and a hostname::(Maybe String) to be recorded, but this would 
require a
fair bit of meddling with the present code.  A simple compromise would be for 
name
lookup failure to result in the substitution of IP-address-as-String for the 
missing
hostname, as already happens in the case of IPv4.

It would also be quite nice to have the option of *not* looking up hostnames at 
all.

Original comment by butt...@gmail.com on 11 Nov 2008 at 9:34

[GoogleCodeExporter]

I will share a "probable" workaround for this problem. It isn't a fix, in a 
sense
that the underlying issue with Network isn't resolved. Rather, the workaround 
is to
turn off ipv6 support in the network package, which I believe is one of the 
haskell
core libraries. This is a "proable" fix because I can't reproduce the bug at 
will.
However, reading the source code and judging by the error message, it seems very
likely that it resolves the problem. If happstutorial.com stops crashing every 
couple
of days in the error logs, then I will know for sure. Also I will do some work 
to see
if I can reproduce the bug at will now :)

To reinstall network myself ipv6 support:

download tarred source from
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/network-2.2.0.1   

make the following change

network-2.2.0.1>darcs diff
diff -rN old-network-2.2.0.1/Network.hs new-network-2.2.0.1/Network.hs
22c22
< #define IPV6_SOCKET_SUPPORT 1
---
> # /* define IPV6_SOCKET_SUPPORT 1 */

reinstall via cabal install. (I have cabal 1.6, the latest, not sure if that's
necessary but I think it might be.)

This workaround was the idea of Matt Elder. Matt not only came up with the 
idea, but
was extremely generous with time diagnosing the problem and handholding. 

Thanks, Matt.

Original comment by thomasha...@gmail.com on 8 Jan 2009 at 1:49

[GoogleCodeExporter]

Followup with suggested patch to Network library at 

http://www.haskell.org/pipermail/libraries/2009-January/011103.html

Original comment by thomasha...@gmail.com on 8 Jan 2009 at 4:23

[GoogleCodeExporter]

To reproduce this bug (on ubunu hardy), you can just comment out the lines of
/etc/resolv.conf to disable dns, and then attempt to load happstutorial.com in a
browser. The "disable ipv6" fix does seem to me to work.

Original comment by thomasha...@gmail.com on 11 Jan 2009 at 1:00