Web UI hangs indefinitely when opening it in a browser after starting the js ipfs daemon

[pcowgill]

After using js-ipfs to start a daemon, it says the web UI will be available here http://127.0.0.1:5002/webui, but when you go to that page in a browser it never finishes loading.

[pcowgill]

I considered using IPFS Desktop as an alternative, but that's an upcoming feature for js-ipfs ipfs/ipfs-desktop#601

In the meantime, is cating files from the terminal my best bet?

[achingbrain]

Does this still happen for you? I can't replicate it.

[pcowgill]

@achingbrain Yep. Trying it in Chrome with the latest version of the js-ipfs master branch.

Initializing IPFS daemon...
js-ipfs version: 0.41.2
System version: x64/darwin
Node.js version: 12.14.1
Swarm listening on /ip4/127.0.0.1/tcp/4002/p2p/QmRGuGpzcEoQRFFJsK8Eh7uLeKuFM9C2xFv3R3cMmVzVQi
Swarm listening on /ip4/192.168.7.42/tcp/4002/p2p/QmRGuGpzcEoQRFFJsK8Eh7uLeKuFM9C2xFv3R3cMmVzVQi
Swarm listening on /ip4/169.254.98.207/tcp/4002/p2p/QmRGuGpzcEoQRFFJsK8Eh7uLeKuFM9C2xFv3R3cMmVzVQi
Swarm listening on /ip4/127.0.0.1/tcp/4003/ws/p2p/QmRGuGpzcEoQRFFJsK8Eh7uLeKuFM9C2xFv3R3cMmVzVQi
API listening on /ip4/127.0.0.1/tcp/5002/http
Gateway (read only) listening on /ip4/127.0.0.1/tcp/9090/http
Web UI available at http://127.0.0.1:5002/webui
Daemon is ready

[pcowgill]

@hugomrdias Can you reproduce this?

[hugomrdias]

no works here

[pcowgill]

Maybe it's a Mac issue? Does @alanshaw have a Mac to try it on?

[pcowgill]

Thoughts on how we can move forward with this?

@Schwartz10 Can you check if you can reproduce this issue? Thanks!

[achingbrain]

Maybe it's a Mac issue?

No, I have a Mac, I've tried with multiple browsers, it all seems fine.

Thoughts on how we can move forward with this?

If you can figure out how to replicate it reliably it can certainly be fixed.

[pcowgill]

Steps to reproduce this

git clone this repo at commit bfba767 (which is master at the time I'm writing this)

Mac OS 10.15.3
Chrome Version 80.0.3987.149

Using nvm to pick node versions, run:
nvm use 10.18.1

npm v6.13.7
yarn version 1.22.4

cd into js-ipfs after clunning, run yarn to run lerna bootstrap

Open a zsh terminal

➜ js-ipfs git:(master) ./packages/ipfs/src/cli/bin.js daemon

Initializing IPFS daemon...
js-ipfs version: 0.41.2
System version: x64/darwin
Node.js version: 10.18.1

Web UI available at http://127.0.0.1:5002/webui

Navigate to URI output when running the js ipfs daemon, and it hangs forever.

[pcowgill]

After loading for a long time, the URL changes to this, but the spinner is there and an error message shows up:

[pcowgill]

@Schwartz10 tried it and it took ~5 minutes to load but eventually loaded when using node.js 12.14.1. But it taking that long still probably counts as a bug.

I just tried with node.js 12.16.1, and the results weren't different for me.

The only other strange thing I can think of that's specific to my config is that I am using 1.1.1.1 as my DNS resolver. Any chance that could be related? When using 1.1.1.1 on my mobile device on airplanes I've had to disable it to get the internet to work.

I've tried running the daemon without a VPN connection, so that's not the problem.

[pcowgill]

@Schwartz10 and I chatted. We think the most likely explanation is that you're using a set of peers that already can serve the file corresponding to that Qmexhq2sBHnXQbvyP2GfUdbnY7HCagH2Mw5vUNSBn2nxip CID that either currently or always points to the web UI content (depending on whether you're using MFS or not).

Maybe js-ipfs should ship pointing to a known usually-live peer that can resolve Qmexhq2sBHnXQbvyP2GfUdbnY7HCagH2Mw5vUNSBn2nxip?

[pcowgill]

When @Schwartz runs swarm peers, here are his results:

./packages/ipfs/src/cli/bin.js swarm peers
/dns4/node0.preload.ipfs.io/tcp/443/wss/p2p/QmZMxNdpMkewiVZLMRxaNxUeZpDUb34pWjZ1kZvsd16Zic

and here are mine:

➜  js-ipfs git:(master) ./packages/ipfs/src/cli/bin.js swarm peers 
/ip6/::1/tcp/4001/p2p/QmQa5ADTm4tJft7Yf5KzpkhCULtskARhRfnNRRU4ouhCEt
/ip4/162.243.248.213/tcp/4001/p2p/QmSoLueR4xBeUbY9WZ9xGUUxunbKWcrNFTDAadQJmocnWm
/ip4/104.236.76.40/tcp/4001/p2p/QmSoLV4Bbm51jM9C4gDYZQ9Cy3U6aXMJDAbzgu2fzaDs64
/ip4/104.236.179.241/tcp/4001/p2p/QmSoLPppuBtQSGwKDZT2M73ULpjvfd3aZ6ha4oFGL1KrGM
/ip4/104.131.131.82/tcp/4001/p2p/QmaCpDMGvV2BGHeYERUEnRQAwe3N8SzbUtfsmvsqQLuvuJ
/ip4/178.62.61.185/tcp/4001/p2p/QmSoLMeWqB7YGVLJN3pNLQpmmEk35v6wYtsMGLzSr5QBU3
/ip4/178.62.158.247/tcp/4001/p2p/QmSoLer265NRgSp2LA3dPaeykiS1J6DifTC88f5uVQKNAd
/ip4/128.199.219.111/tcp/4001/p2p/QmSoLSafTMBsPKadTEgaXctDQVcqN88CNLHXMkTNwMKPnu

[Schwartz10]

Just to add on to what @pcowgill said with some more explicit observations (and this may have already been obvious to everyone), we ran a series of tests - the problem isn't the web UI itself, it's that Paul's js-ipfs instance can't resolve the content behind Qmexhq2sBHnXQbvyP2GfUdbnY7HCagH2Mw5vUNSBn2nxip before timing out.

[pcowgill]

The only other strange thing I can think of that's specific to my config is that I am using 1.1.1.1 as my DNS resolver. Any chance that could be related? When using 1.1.1.1 on my mobile device on airplanes I've had to disable it to get the internet to work.

^ This definitely isn't the problem, given that the web UI is working for me with go-ipfs

[pcowgill]

Did this info help with reproducing the issue? Thanks!

[jacobheun]

I wasn't able to reproduce but I am also connected to the preload nodes, if you're losing connection to the preload nodes that may be the issue. @pcowgill are you still having this issue?

[jacobheun]

Closing this, please reopen if you're still encountering this.

[Kavelaa]

well... I have the same problem...

[Kavelaa]

ok..I solve this problem.
In my /.jsipfs/config, attribute "Gateway" was undefined, then I copy the "Gateway"'s content from go-ipfs's config, and jsipfs daemon, it actually works.
I think you could try.

[LehaoLin]

After 2 hours trial, I solve this problem finally. I find that there are some attributes missing in js-ipfs's config, compared with go-ipfs.
My solution is
In /.jsipfs/config, add:

  "Mounts": {
    "IPFS": "/ipfs",
    "IPNS": "/ipns",
    "FuseAllowOther": false
  },
  "Gateway": {
    "HTTPHeaders": {
      "Access-Control-Allow-Headers": [
        "X-Requested-With",
        "Range",
        "User-Agent"
      ],
      "Access-Control-Allow-Methods": [
        "GET"
      ],
      "Access-Control-Allow-Origin": [
        "*"
      ]
    },
    "RootRedirect": "",
    "Writable": false,
    "PathPrefixes": [],
    "APICommands": [],
    "NoFetch": false,
    "NoDNSLink": false,
    "PublicGateways": null
  },
  "API": {
    "HTTPHeaders": {}
  },
  "Peering": {
    "Peers": null
  },
  "Provider": {
    "Strategy": ""
  },
  "Reprovider": {
    "Interval": "12h",
    "Strategy": "all"
  },
  "Plugins": {
    "Plugins": null
  }

[wa1one]

@LehaoLin can confirm the issue. Why was this closed?

[luzzif]

This is still an issue for me, plase reopen.