superhighway84 hangs on first launch / can't seem to retrieve default database

[a8underscore]

I tried with the binary version and one built from git.

my system is amd64, ipfs version 0.10.0, go version go1.17.5 linux/amd64

[vielmetti]

go version go1.17.5 darwin/arm64 ipfs version 0.10.0

When I start superhighway84 it hangs just as @a8underscore reports.

When I subsequently start up ipfs with ipfs daemon and then start superhighway84, I get this:

> ./superhighway84 
2021/12/27 00:07:49 lock /Users/emv/.ipfs/repo.lock: someone else has the lock
panic: lock /Users/emv/.ipfs/repo.lock: someone else has the lock

goroutine 1 [running]:
log.Panicln({0x1400063ff40, 0x1, 0x1})
    /opt/homebrew/Cellar/go/1.17.5/libexec/src/log/log.go:368 +0x98
main.main()
    /Users/emv/src/github.com/mrusme/superhighway84/superhighway84.go:53 +0x318

[mrusme]

Check this conversation on Reddit, you might be having the same issue and could give creating a new DB a try.

@vielmetti that's because you're trying to share the same repo for two IPFS nodes. Check the current README.md for more info on that! :-)

[vielmetti]

@mrusme I was able to get the UI to load when I gave it a new DB to try.

The software isn't "hung" per se - there something going on at the IPFS layer, apparently connecting to 100s of sites around the world perhaps looking for the IPFS database. A little snippet from "nettop".

superhighway84.17130
   tcp4 192.168.1.196:4001<->211.252.167.145:54110
   tcp4 192.168.1.196:4001<->ec2-54-80-220-253.compute-1.amazonaws.com:4001
   tcp4 192.168.1.196:4001<->host-157-100-76-29.ecua.net.ec:1595
   tcp4 192.168.1.196:4001<->117.146.55.184:42650
   tcp4 192.168.1.196:4001<->58.144.221.30:4001

[vielmetti]

Perhaps related in a general way to https://github.com/ipfs/go-ipfs/issues/6383

[a8underscore]

Creating a new DB got the UI to show for me

[mrusme]

I just tested it on a fresh installation on a macOS machine and it worked out instantly. However, obviously that machine is in the same network, so, yeah.

One thing that can be performed for testing purposes is running the following IPFS command and see what it tells you: ipfs dag get bafyreifdpagppa7ve45odxuvudz5snbzcybwyfer777huckl4li4zbc5k4

You might need to run the IPFS daemon before running the ipfs dag command. If the ipfs dag command returns with some merkle-issue, try ipfs daemon in a separate tab (it will stay in the foreground) and run the ipfs dag command again.

If connections work, it should tell you something like:

{"access_controller":"/ipfs/bafyreidvlncmgs5phhz3542tio2u3exzxsoisi2ahk4qfrs6qt3xjubzxe","name":"superhighway84","type":"docstore"}

If this command won't return/keep waiting, there's a general issue with your IPFS connectivity I would assume, as these commands are using the IPFS daemon and not superhighway84 for communication.

Will investigate this further on my own by running a couple of VPS instances.

[mrusme]

I've set up an Ubuntu instance on Vultr and managed to sync the default database from my local nodes to it. I kept it running, so there are more nodes available for you to sync the default database from.

Please keep me posted if this does the trick for you.

[a8underscore]

I'll try again tomorrow, hopefully the new vultr node helps, thank you

On Sun, Dec 26, 2021, 11:53 PM ◤◢◤◢◤◢◤◢ @.***> wrote:

I've set up an Ubuntu instance on Vultr and managed to sync the default database from my local nodes to it. I kept it running, so there are more nodes available for you to sync the default database from.

Please keep me posted if this does the trick for you.

— Reply to this email directly, view it on GitHub https://github.com/mrusme/superhighway84/issues/1#issuecomment-1001405285, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOP4E33THDVS37YEZ2R76HDUTALQJANCNFSM5KZVSXAA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[Jay4242]

Check this conversation on Reddit, you might be having the same issue and could give creating a new DB a try.

@vielmetti that's because you're trying to share the same repo for two IPFS nodes. Check the current README.md for more info on that! :-)

Would it be possible to detect if an IPFS daemon is already providing an API server and use that?

[a8underscore]

the GUI starts for me now! thanks for the help

[mrusme]

Would it be possible to detect if an IPFS daemon is already providing an API server and use that?

Hm, I don't believe so. OrbitDB seems to integrate tightly with the IPFS Node. I understand what you're thinking about doing, but I believe that OrbitDB would need to support that in first place - which from what I saw it does not.

On a side-note, the go-orbit-db package that I'm using here is not an official library from the OrbitDB guys. It's developed by @berty and kind of follows the official OrbitDB library (which is JS). While the package works, it really lacks of documentation and using is basically means diving into the code and finding out on your own. I haven't done that so far for what you're suggesting. :)