Can't connect to portal network locally

[Perelyn-sama]

I'm following the instructions in the trin book on how to run a portal node locally and connect it.

As the book dictates, I first run

RUST_LOG=debug cargo run -- \
    --web3-http-address http://127.0.0.1:8547 \
    --web3-transport http \
    --discovery-port 9009 \
    --bootnodes default \
    --mb 200 \
    --no-stun

which I assume works but when I try to connect to the portal node with the next command in the book:

cargo run -- --bootnodes default

I get

Error: rocksdb error IO error: While lock file: /Users/mac/Library/Application Support/trin/trin_0xcf2a02/rocksdb/LOCK: Resource temporarily unavailable

Caused by:
    IO error: While lock file: /Users/mac/Library/Application Support/trin/trin_0xcf2a02/rocksdb/LOCK: Resource temporarily unavailable

[carver]

Maybe you have another instance of trun running, already? Maybe you thought one quit out, but it is still running in the background somehow? I don't really know Mac, but on linux I'd be looking at htop or pgrep to figure out if there are any running instances of trin that are still holding a lock on the DB.

[njgheorghita]

@Perelyn-sama Is this still an issue? Let's close it if you're no longer experiencing this issue

[Perelyn-sama]

I still get the error

[njgheorghita]

I'm able to duplicate this issue. The problem seems to be that when running two nodes concurrently, unless you specify a private key using the --unsafe-private-key flag, Trin will try to use the same private key for both nodes. Since two nodes with the same private key would be using the same data dir for storage, the second trin instance is unable to acquire the rw lock on the storage directory.

I'm not sure that this is a problem worth solving at the moment. Imo, the best way forward is simply to handle this errorl in the case we are not able to acquire the rwlock, and output a log describing the situation. That trin is unable to acquire the rwlock, which means you probably have another node operating on the same private key, and you should use the --unsafe-private-key option if you'd like to run a second (or 3rd, or 4th) node concurrently.