Pkg: unable to connect to


I’m having this issue under Julia 1.8.2. A clean Julia install has not been able to solve it.

(@v1.8) pkg> up
┌ Warning: could not download
│   exception = HTTP/2 301 (Failed to connect to port 443 after 27 ms: Connection refused) while requesting
└ @ Pkg.Registry /cache/build/default-amdci4-6/julialang/julia-release-1-dot-8/usr/share/julia/stdlib/v1.8/Pkg/src/Registry/Registry.jl:68
    Updating registry at `~/.julia/registries/General`
Unhandled Task ERROR: IOError: FDWatcher: bad file descriptor (EBADF)
 [1] try_yieldto(undo::typeof(Base.ensure_rescheduled))
   @ Base ./task.jl:871
 [2] wait()
   @ Base ./task.jl:931
 [3] wait(c::Base.GenericCondition{Base.Threads.SpinLock})
   @ Base ./condition.jl:124
 [4] _wait(fdw::FileWatching._FDWatcher, mask::FileWatching.FDEvent)
   @ FileWatching ~/packages/julias/julia-1.8/share/julia/stdlib/v1.8/FileWatching/src/FileWatching.jl:535
 [5] wait(fdw::FileWatching.FDWatcher)
   @ FileWatching ~/packages/julias/julia-1.8/share/julia/stdlib/v1.8/FileWatching/src/FileWatching.jl:563
 [6] macro expansion
   @ ~/packages/julias/julia-1.8/share/julia/stdlib/v1.8/Downloads/src/Curl/Multi.jl:166 [inlined]
 [7] (::Downloads.Curl.var"#40#46"{Int32, FileWatching.FDWatcher, Downloads.Curl.Multi})()
   @ Downloads.Curl ./task.jl:484
    Updating git-repo ``
  No Changes to `~/.julia/environments/v1.8/Project.toml`
  No Changes to `~/.julia/environments/v1.8/Manifest.toml`
[ Info: We haven't cleaned this depot up for a bit, running Pkg.gc()...
      Active manifest files: 1 found
      Active artifact files: 0 found
      Active scratchspaces: 0 found
     Deleted no artifacts, repos, packages or scratchspaces

(@v1.8) pkg>

Are you able to download in the browser or using curl on the command line, e.g. with curl -L

No, I can’t. By the way, issue is being observed since last Sunday on three different computers, each one under very distinct network installation.

(base) ciro@pc-ciro:~$ curl -L
curl: (7) Failed to connect to port 443: Connection refused
(base) ciro@pc-ciro:~$

Confirmed that is not allowing connections. I’ve moved this to a new topic since it’s an unrelated issue. That server may be having issues.

1 Like

Server is back. Thanks.

Yep, I pinged @staticfloat and he fixed it. Full disk. Thanks for the report!


Just to let know seems to be dead again. @staticfloat

(@v1.9) pkg> up Revise
┌ Warning: could not download
│   exception = RequestError: HTTP/2 301 (Could not resolve host: while requesting

Looks like DNS issue. Output from dig

➜ dig

; <<>> DiG 9.16.1-Ubuntu <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58241
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 512
;          IN      A

;; Query time: 1630 msec
;; WHEN: Wed Mar 08 14:19:53 -03 2023
;; MSG SIZE  rcvd: 49

I’m having the same issue right now. Seems to be only with; other domains, like, are working fine.

@staticfloat ^

Hmmm, I’m not having the issue. When you have this issue, can you please show the output of the following:

$ dig @
$ curl -vL

@staticfloat, sorry for the long delay. I just saw your reply today, as I came back because I’m having the same issue again.

user@hostname ~ [60]> dig @

; <<>> DiG 9.18.13 <<>> @
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17250
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 1232
;		IN	A


;; Query time: 380 msec
;; WHEN: Sat Apr 22 10:27:35 -03 2023
;; MSG SIZE  rcvd: 102

user@hostname ~> curl -vL
*   Trying
* Connected to ( port 443 (#0)
* ALPN: offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: none
*  CApath: /var/cache/ca-certs/anchors
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-AES256-GCM-SHA384
* ALPN: server accepted h2
* Server certificate:
*  subject:
*  start date: Mar  5 16:17:08 2023 GMT
*  expire date: Jun  3 16:17:07 2023 GMT
*  subjectAltName does not match
* SSL: no alternative certificate subject name matches target host name ''
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
curl: (60) SSL: no alternative certificate subject name matches target host name ''
More details here:

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

For some reason curl is not resolving the domain to the same server? My system/router resolver seems to be pointing to the correct address:

user@hostname ~> nslookup

Non-authoritative answer:	canonical name =

Are you certain you haven’t done something like overridden the resolver in /etc/hosts or similar?

1 Like

Oh, yeah! This is the old address I’ve set in /etc/hosts previously when the domain was failing to resolve. Removing the line fixed the issue.

Sorry for disturbing you.