Error: rpc: dial tcp 127.0.0.1:7778: connect: connection refused

Node Operators troubleshooting
1

I constantly get:
docker exec -it storagenode /app/dashboard.sh 2024-06-01T07:56:51Z INFO Anonymized tracing enabled {"Process": "storagenode"} 2024-06-01T07:56:51Z INFO Identity loaded. {"Process": "storagenode", "Node ID": "127BbGcBVnFPih3QipmNfvyD9sRQaLSEdmBXGeQCefY8ohC2za"} Error: rpc: dial tcp 127.0.0.1:7778: connect: connection refused
I don’t run mulitple nodes.

2

Please check your logs for the real problem: How do I check my logs? - Storj Docs

3

This was written in logs:

docker logs --tail 20 storagenode
2024-06-01 11:23:57,414 INFO stopped: storagenode-updater (exit status 0)
2024-06-01 11:23:58,417 INFO stopped: processes-exit-eventlistener (terminated by SIGTERM)
2024-06-01 11:24:28,385 INFO Set uid to user 0 succeeded
2024-06-01 11:24:28,396 INFO RPC interface 'supervisor' initialized
2024-06-01 11:24:28,396 INFO supervisord started with pid 1
2024-06-01 11:24:29,400 INFO spawned: 'processes-exit-eventlistener' with pid 11
2024-06-01 11:24:29,405 INFO spawned: 'storagenode' with pid 12
2024-06-01 11:24:29,410 INFO spawned: 'storagenode-updater' with pid 13
2024-06-01T11:24:29Z    INFO    Anonymized tracing enabled      {"Process": "storagenode-updater"}
2024-06-01T11:24:29Z    INFO    Running on version      {"Process": "storagenode-updater", "Service": "storagenode-updater", "Version": "v1.104.5"}
2024-06-01T11:24:29Z    INFO    Downloading versions.   {"Process": "storagenode-updater", "Server Address": "https://version.storj.io"}
2024-06-01T11:24:29Z    INFO    Anonymized tracing enabled      {"Process": "storagenode"}
2024-06-01T11:24:29Z    INFO    Operator email  {"Process": "storagenode", "Address": "vukmrovicandrija@gmail.com"}
2024-06-01T11:24:29Z    INFO    Operator wallet {"Process": "storagenode", "Address": "0x582e0Fce6bc6ea7f08b175eFF5760744Ff114a76"}
2024-06-01T11:24:29Z    ERROR   failure during run      {"Process": "storagenode", "error": "Error opening database on storagenode: group:\n--- stat config/storage/blobs: no such file or directory\n--- stat config/storage/temp: no such file or directory\n--- stat config/storage/trash: no such file or directory", "errorVerbose": "Error opening database on storagenode: group:\n--- stat config/storage/blobs: no such file or directory\n--- stat config/storage/temp: no such file or directory\n--- stat config/storage/trash: no such file or directory\n\tmain.cmdRun:67\n\tmain.newRunCmd.func1:33\n\tstorj.io/common/process.cleanup.func1.4:393\n\tstorj.io/common/process.cleanup.func1:411\n\tgithub.com/spf13/cobra.(*Command).execute:983\n\tgithub.com/spf13/cobra.(*Command).ExecuteC:1115\n\tgithub.com/spf13/cobra.(*Command).Execute:1039\n\tstorj.io/common/process.ExecWithCustomOptions:112\n\tmain.main:34\n\truntime.main:267"}
Error: Error opening database on storagenode: group:
--- stat config/storage/blobs: no such file or directory
--- stat config/storage/temp: no such file or directory
--- stat config/storage/trash: no such file or directory
2024-06-01 11:24:29,471 INFO exited: storagenode (exit status 1; not expected)
4

This is mean either:

  1. If it’s a worked node - please check your paths. Do not follow the next steps. Stop here. Check everything
  2. If this is a new node (only in this case) - please perform a setup step once. Please note - you must not run it more than once, otherwise your node can be disqualified.
2 Likes
5

Thank you very much, removing container and then setuping and running solved. :smiley:

1 Like
6

if I use the key twice it’s DQ’d, and I need to new identity for the node? Back to step 5?

7

If you mean the identity, then - yes. Moreover you will lose all clones, including the original node.

If you mean the SETUP step - not neccessarily, if you provided correct paths, it must fail with the error. If you did remove also a protection file, then you would be able to run it in the second time and the protection file will be regenerated for the provided identity in the provided storage location. It would also re-create all folders structure if it was missing.

So, basically DQ may happen by running the SETUP step in the second time only in case if the paths are wrong. Because if the node has had data before and was running, but then it’s failed for some reason and you wrongly specified any of paths, the node may not find the protection file or the content wouldn’t match the identity and will fail.
So if you wouldn’t be careful and just run the SETUP step with incorrect paths, then start the worked node with the same incorrect paths, the node will be disqualified for losing data (because the node will not find a previous data in a new empty storage location).