Error in second node

Node Operators troubleshooting
1

Hi. I have a node on a raspberry pi 4 with 1TB working properly. Today I have put a second disk with 2TB, which I have mounted exactly the same as the first except that I have changed the ports. I have an error in this second node which in the log shows me: Got a signal from the OS: “terminated”
Error: debug: http: Server closed What could be the cause of this error and how to solve it so that the node is Online? Thank you

> sudo docker logs --tail 20 nodo1
> 2020-09-08T14:12:01.628Z        INFO    preflight:localtime     local system clock is in sync with trusted satellites' system clock.
> 2020-09-08T14:12:01.628Z        INFO    bandwidth       Performing bandwidth usage rollups
> 2020-09-08T14:12:01.629Z        INFO    Node 1hBbdAp6UjmxAiN8AnTnwNsJEnRsXpfTPVoUeMeQ5PQQw4mdhQ started
> 2020-09-08T14:12:01.629Z        INFO    Public server started on [::]:28967
> 2020-09-08T14:12:01.629Z        INFO    Private server started on 127.0.0.1:7778
> 2020-09-08T14:12:01.629Z        INFO    trust   Scheduling next refresh {"after": "6h52m59.090345583s"}
> 2020-09-08T14:20:39.947Z        INFO    Got a signal from the OS: "terminated"
> Error: debug: http: Server closed
> 2020-09-08T14:24:20.920Z        INFO    Configuration loaded    {"Location": "/app/config/config.yaml"}
> 2020-09-08T14:24:20.940Z        INFO    Operator email  {"Address": "@macronukes.com"}
> 2020-09-08T14:24:20.940Z        INFO    Operator wallet {"Address": "0x7"}
> 2020-09-08T14:24:22.062Z        INFO    Telemetry enabled
> 2020-09-08T14:24:22.102Z        INFO    db.migration    Database Version        {"version": 43}
> 2020-09-08T14:24:23.630Z        INFO    preflight:localtime     start checking local system clock with trusted satellites' system clock.
> 2020-09-08T14:24:24.513Z        INFO    preflight:localtime     local system clock is in sync with trusted satellites' system clock.
> 2020-09-08T14:24:24.513Z        INFO    bandwidth       Performing bandwidth usage rollups
> 2020-09-08T14:24:24.516Z        INFO    trust   Scheduling next refresh {"after": "5h20m29.829853535s"}
> 2020-09-08T14:24:24.518Z        INFO    Node 1hBbdAp6UjmxAiN8AnTnwNsJEnRsXpfTPVoUeMeQ5PQQw4mdhQ started
> 2020-09-08T14:24:24.519Z        INFO    Public server started on [::]:28967
> 2020-09-08T14:24:24.521Z        INFO    Private server started on 127.0.0.1:7778
2

I would remove any private info in your post.

Also is this second node running on the same network?

3

So you want to run 2 nodes in parallel? You also need a second identity otherwise both nodes will get DQed quickly. If you haven’t done that I would recommend taking the second node offline asap.

4

Thanks. I remove personal information.

The node is on the same network, but while node0 (which works correctly) is on port 28900, node1 (which gives an error) is on port 28901

6

Can you show your start command?

7

Hi. The second node has a different identity than the first

8

Yes, for two nodes.

Node0:
> docker run -d --restart unless-stopped --stop-timeout 300
> -p 28900:28967
> -p 14000:14002
> -e WALLET=“0x”
> -e EMAIL="nodo0@macronukes.com"
> -e ADDRESS=“macronukes.mooo.com:28900”
> -e STORAGE=“0.9TB”
> --mount type=bind,source="/home/ubuntu/.local/share/storj/identity/nodo0",destination=/app/identity
> --mount type=bind,source="/mnt/nodo0",destination=/app/config
> --name nodo0 storjlabs/storagenode:latest

Node1:
> docker run -d --restart unless-stopped --stop-timeout 300
> -p 28901:28967
> -p 14001:14002
> -e WALLET=“0x7”
> -e EMAIL="nodo1@macronukes.com"
> -e ADDRESS=“macronukes.mooo.com:28901”
> -e STORAGE=“1.8TB”
> --mount type=bind,source="/home/ubuntu/.local/share/storj/identity/nodo1",destination=/app/identity
> --mount type=bind,source="/mnt/nodo1",destination=/app/config
> --name nodo1 storjlabs/storagenode:latest

9

Nothing pops out that could cause any issues, Did you open the ports for the second node? Are you running a firewall on the PI?

10

Yep the commands looks correct. So just the usual stuff then. Ports forwarded? Identity signed?

11

Thanks to all for responses.

The problem was that the identity was not correctly signed.