Stack: "ConnectionTimeout" when attempting to run stack setup on WSL 2

[rebeccaclavier]

General summary/comments (optional)

There seems to be some issue with setting up Stack on the new WSL 2 (as far as I'm aware WSL 1 doesn't suffer from the same issue). Thinking it may have something to do with Hyper-V's NAT but I'm not sure. wget https://s3.amazonaws.com/haddock.stackage.org/snapshots.json seems to work fine (the JSON is downloaded successfully) so I'm not sure where the error in Stack is coming in

Steps to reproduce

1. Start a WSL 2 distro instance
2. Install stack using the official binary and then run stack setup

Expected

The GHC is installed and ready to go

Actual

$ stack setup --verbose
Version 2.1.3, Git revision 636e3a759d51127df2b62f90772def126cdf6d1f (7735 commits) x86_64 hpack-0.31.2
2019-10-23 17:57:56.404263: [debug] Checking for project config at: /home/fluxe/stack.yaml
2019-10-23 17:57:56.404768: [debug] Checking for project config at: /home/stack.yaml
2019-10-23 17:57:56.405062: [debug] Checking for project config at: /stack.yaml
2019-10-23 17:57:56.405206: [debug] No project config file found, using defaults.
2019-10-23 17:57:56.414073: [debug] SELECT COUNT(*) FROM "last_performed" WHERE ("action"=?) AND ("timestamp">=?); [PersistInt64 1,PersistUTCTime 2019-10-22 16:57:56.4140244 UTC]
2019-10-23 17:57:56.414587: [debug] Run from outside a project, using implicit global project config
2019-10-23 17:57:56.414716: [info] Writing implicit global project config file to: /home/fluxe/.stack/global-project/stack.yaml
2019-10-23 17:57:56.414810: [info] Note: You can change the snapshot via the resolver field there.
2019-10-23 17:57:56.415042: [debug] Downloading snapshot versions file from https://s3.amazonaws.com/haddock.stackage.org/snapshots.json
2019-10-23 17:58:26.446965: [error] HttpExceptionRequest Request {
  host                 = "s3.amazonaws.com"
  port                 = 443
  secure               = True
  requestHeaders       = [("Accept","application/json"),("User-Agent","The Haskell Stack")]
  path                 = "/haddock.stackage.org/snapshots.json"
  queryString          = ""
  method               = "GET"
  proxy                = Nothing
  rawBody              = False
  redirectCount        = 10
  responseTimeout      = ResponseTimeoutDefault
  requestVersion       = HTTP/1.1
}
 ConnectionTimeout

Stack version

$ stack --version
Version 2.1.3, Git revision 636e3a759d51127df2b62f90772def126cdf6d1f (7735 commits) x86_64 hpack-0.31.2

Method of installation

• Official binary, downloaded from stackage.org or fpcomplete's package repository

Any ideas on what's going on here?

[mattaudesse]

Hey @rebeccaclavier,

We see these kinds of timeouts occasionally, and they're usually only temporary, but if you find you get the same result more often than not you may want to consider using a mirror - depending upon where you're located this can apparently make a huge difference.

Here's an example of how to configure a mirror for fetching snapshots:
https://docs.haskellstack.org/en/stable/install_and_upgrade/#china-based-users

The WSL 2 angle is interesting though... Unfortunately I'm not set up to help reproduce, but I agree that's a good place to start digging if stack setup --verbose fails reliably 100% of the time and wget always succeeds.

Would you please retry a few times and let us know if you see any different results?

[rebeccaclavier]

Tried multiple times on multiple days, same issue unfortunately. I'm in the UK, tried the Chinese mirror but I'm getting the error failed to parse field 'package-indices': failed to parse field 'hackage-security': key "hackage-security" not present.

EDIT: Never mind, I just worked out I needed to add the keys. That seems to work, but is there a mirror that's non-Chinese?

[mattaudesse]

Hey again @rebeccaclavier - apologies for the delayed response.

I've tried to track down some info RE: alternative mirrors but couldn't find much.

Perhaps @borsboom would be a good person to ask?

[ghost]

Is there any update on this? I too ran into this problem with stack setup on WSL-2. Reverting to WSL-1 fixed all the problems.

I do remember something about WSL-2 and IP addresses:
https://docs.microsoft.com/en-us/windows/wsl/wsl2-ux-changes

Anyways, if there is anything I can do to help fix this problem, I am more than happy to do it. I just don't know where I'd start.

[mattaudesse]

Note: I've asked to get some more eyes on this via Slack - hopefully one of the core devs can shed some light.

Thanks again for reporting and sorry it's taking awhile to sort out @JonathanGallagher + @rebeccaclavier.

[mattaudesse]

Hey again - so, one suggestion I heard was to try using http-conduit rather than stack to see if the same problem is reproducible without any extra moving pieces.

Would one of you please try adapting this example code to fetch https://s3.amazonaws.com/haddock.stackage.org/snapshots.json and see how it goes under WSL-2?

Thanks!

[jakzale]

I had a similar issue on my machine. I believe it is connected to how WSL 2 handles network and DNS, as WSL 2 gets connected through a Hyper-V adapter.

Setting DNS manually as described in WSL 2 Troubleshooting resolved the issue.

[mattaudesse]

Cool, nice find and thanks for sharing @jakzale.

It seems like manually fiddling with symlinks and backups might get frustrating/brittle, but probably much less so than not being able to reach stackage.

I wonder if there's a clean way to extend the resolve.conf that's being generated for you automatically (I do this with dnsmasq on FreeBSD, for instance). If not it might suffice to just plug into Google's DNS servers like so:

# /etc/resolve.conf

nameserver 8.8.8.8
nameserver 8.8.4.4

If other folks find this helps we should probably make note of it in the docs.

[zcg0696]

@mattaudesse
I had same issue with "casa.fpcomplete.com/v1/pull", using Google's DNS did solved my problem.

[lukad]

I'm having the same problem and changing my dns changes absolutely nothing. I was already using 8.8.8.8. I also tried 8.8.4.4 and my ISP dns.

~ $ host -v casa.fpcomplete.com
Trying "casa.fpcomplete.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33734
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;casa.fpcomplete.com.           IN      A

;; ANSWER SECTION:
casa.fpcomplete.com.    36      IN      A       18.210.104.222
casa.fpcomplete.com.    36      IN      A       35.153.43.183
casa.fpcomplete.com.    36      IN      A       23.22.87.210

Received 85 bytes from 8.8.8.8#53 in 19 ms
Trying "casa.fpcomplete.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42299
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;casa.fpcomplete.com.           IN      AAAA

;; AUTHORITY SECTION:
fpcomplete.com.         426     IN      SOA     ns-1359.awsdns-41.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Received 119 bytes from 8.8.8.8#53 in 20 ms
Trying "casa.fpcomplete.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57317
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;casa.fpcomplete.com.           IN      MX

;; AUTHORITY SECTION:
fpcomplete.com.         659     IN      SOA     ns-1359.awsdns-41.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Received 119 bytes from 8.8.8.8#53 in 18 ms

I'm pretty sure that dns is not culprit. I just had to run stack build a couple of times because every run it would get stuck on another dependency.

Edit:

Just tried this on my linux machine and had the same problem, so it's probably unrelated to wsl. Maybe it's just a flaky server?

[nartamonov]

I managed to solve the problem by manually writing in /etc/resolv.conf:

nameserver 8.8.8.8
nameserver 8.8.4.4

Now stack upgrade, update and setup work fine. Windows 10 build 2004, WSL2.

[Kudostoy0u]

@nartamonov
@mattaudesse
The new nameserver worked perfectly.
I just did sudo vim /etc/resolv.conf, and replaced the whole thing with

nameserver 8.8.8.8
nameserver 8.8.4.4

Everything started working after that.