yesod devel got stuck in "recompiling" mode forever right upon the start

[develop7]

Repro:

1. stack new testsod yesod-simple; cd testsod
2. stack build --fast; stack build yesod-bin if necessary
3. stack exec -- yesod devel
4. Navigate http://localhost:3000/

Expected: regular behavior — a generated project shows up

Instead: the web page is permanenly stuck in "The application isn’t built" mode.

Here's output of the yesod devel command:

develop7@t-rex ~/t/testsod> stack exec -- yesod devel
Yesod devel server. Enter 'quit' or hit Ctrl-C to quit.
Application can be accessed at:

http://localhost:3000
https://localhost:3443
If you wish to test https capabilities, you should set the following variable:
  export APPROOT=https://localhost:3443

ExitSuccess
Type help for available commands. Press enter to force a rebuild.
Starting devel application
Devel application launched: http://localhost:3000
devel.hs: Network.Socket.getAddrInfo: does not exist (Name or service not known)

Note the latest line, devel.hs: Network.Socket.getAddrInfo: does not exist (Name or service not known). I was trying to dig into this by catching the exception from GHCi, but the trace was less than useful.

UPD: I've ran into this before while running stackage-server with yesod devel, symptoms were exactly the same. But only in Linux (openSUSE Tumbleweed, for the record). It wasn't the case for Mac OS X 10.13.2.

Bugreport script output

[psibi]

My guess is that some other application is running on port 3000. Can you verify if that's the case (using neststat or something like that) ?

[develop7]

@psibi wouldn't yesod devel fail altogether in https://github.com/yesodweb/yesod/blob/master/yesod-bin/Devel.hs#L270 then?

[develop7]

@psibi also that's not the case

>   netstat -ltnp | grep 3000
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:3000            0.0.0.0:*               LISTEN      14382/yesod

[psibi]

What does ps -e | grep yesod says ? Also what's the yesod version you are using ?

[develop7]

@psibi

>  ps -e | grep yesod
14382 pts/9    00:00:00 yesod

https://gist.github.com/develop7/812244fdfb5a6f01429368b190f03d21#file-gistfile1-txt-L217

[snoyberg]

I'm guessing you're not running PostgreSQL locally, and that's the source of the error message.

[develop7]

@snoyberg umm, the project has been generated with yesod-simple template and therefore shouldn't depend on postgres, should it?

[snoyberg]

Sorry, you're right. I was following this from the stackage-server PR that referenced it.

[MaxGabriel]

I made a PR to network, now merged into master, that adds more detail to this error message

[develop7]

With the patched network lib (had to backport @MaxGabriel's patches to 2.6.3.2) the error message looks like this:

Devel application launched: http://localhost:3000
devel.hs: Network.Socket.getAddrInfo (called with preferred socket type/protocol: AddrInfo {addrFlags = [AI_PASSIVE,AI_NUMERICSERV,AI_NUMERICHOST], addrFamily = AF_UNSPEC, addrSocketType = Stream, addrProtocol = 0, addrAddress = <assumed to be undefined>, addrCanonName = <assumed to be undefined>}, host name: Just "t-rex", service name: Just "28678"): does not exist (Name or service not known)

where t-rex is the my desktop's hostname. True, while resolveip t-rex doesn't work for me, I'm not sure it actually needs to be a dealbreaker, as we probably want this to bind on something like 127.0.0.1: development reverse proxy isn't supposed to be available from LAN anyway, is it? I'll cook a PR.

[StevenXL]

@develop7 Is the issue that you are experiencing related at all to #1517? The error messages are not exactly the same, as #1517 makes no mention of Network.Socket.getAddrInfo. If it is the same issue, I'd say we close this one. Thoughts?

[develop7]

@StevenXL I am affected by the #1517 too and can't reproduce this issue now as resolveip t-rex succeeds for me (fixed it by specifying a static hostname for desktop in router's DNS server)

[jezen]

Since this issue now can’t be reproduced, I’ll close it.