What does this mean for the satellite?

Node Operators troubleshooting
, ,
1

It just says 0% by online but 100% by the rest. I did have a couple of power glitches in my house but my total downtime is ~1h

Capture
Capture823Ă—263 16.9 KB

2

This is mean that something is preventing your node to be available from outside for this satellite, i.e. your node is considered as totally offline.
You may use these scripts to see when your node was offline:

The next step is to fix your node’s availability, i.e. check your firewall to do not block incoming connections to the node’s port and do not block outgoing connections from any port of your device to any address and port, your router to do not block incoming/outgoing connections with “smart” functions like DDoS protection, its firewall, throttling, and finally - your ISP (some ISP doing a “smart” protection for you, blocking “suspicious connections” and/or p2p).

3

I updated my image to show all of the satellites. This is the only one having issues.

4

Then you need to check why is it blocked by your network.
You may also search for “ping satellite failed” errors except “rate limit” (these ones are consequence of a previous such error) in your logs, i.e.

docker logs storagenode 2>&1 | grep "ping satellite failed" | grep -v "rate limit" | tail
5

Here’s the output from the command:

for item in `curl -sL http://localhost:14002/api/sno | jq '.satellites[].id' -r`; do     curl -s http://localhost:14002/api/sno/satellite/$item |     jq '{id: .id, auditHistory: [.auditHistory.windows[] | select(.totalCount != .onlineCount)]}'; done

Result:

{
  "id": "12tRQrMTWUWwzwGh18i7Fqs67kmdhH9t6aToeiwbo5mfS2rUmo",
  "auditHistory": []
}
{
  "id": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE",
  "auditHistory": [
    {
      "windowStart": "2023-07-17T12:00:00Z",
      "totalCount": 1,
      "onlineCount": 0
    }
  ]
}
{
  "id": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6",
  "auditHistory": []
}
{
  "id": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S",
  "auditHistory": []
}
jq: error (at <stdin>:1): Cannot iterate over null (null)
jq: error (at <stdin>:1): Cannot iterate over null (null)

There’s 1 different from the rest in there. I don’t know if the ids are private so I’ll keep them out for now but let me know.
It says 2023-07-17 which is the same date that I posted about my drive randomly unmounting. The node was offline for an hour that day because of that.

– Edit –
As for:

sudo docker logs storagenode 2>&1 | grep "ping satellite failed" | grep -v "rate limit" | tail

There’s no output for this one.

6

satellites ids are public, include your node-id, but well

This is mean that your node is new (it has only one audit request) and managed to be offline exactly when the first audit request is to come from this satellite.

This is could mean that either you re-created your container since 2023-07-17T12:00:00Z, or your node was online during the start and this offline event was less than 1 hour since the last successful check-in (the node is trying to check-in on the satellites every hour by default).
Or, if you redirected your logs to the file, then the command should be different:

cat /mnt/storj/storagenode/storagenode.log | grep "ping satellite failed" | grep -v "rate limit" | tail

where /mnt/storj/storagenode/storagenode.log is the path to the node’s logs file on your host.

7

I updated it to have ids then.

Yes, my node is only 2 days old. I started it on the 17th.

At one point yesterday I did do the following:

sudo docker stop -t 300 storagenode
sudo docker rm storagenode
- redid the run command here
sudo docker start storagenode

This was only to update the run command as follows:
From:

-p 127.0.0.1:14002:14002 \

To:

-p 14002:14002 \

This was to allow the dashboard to be viewed on any of my local devices.

The following command results in a no such file found error:

cat /mnt/storj/storagenode/storagenode.log | grep "ping satellite failed" | grep -v "rate limit" | tail
8

since you did not redirect logs to the file, the old log has been deleted with the container, so now you do not have any errors.
You need to wait for the next audit from that satellite. If your node would start to respond, your online score will slowly recover, but to fully recover your node should be online for the next 30 days. However for the new node it can take less time due to the small amount of audits.

of course, if the path is not what you have used for your node’s data location and also if you did not redirect to this file using instructions from my previous message.

9

But isn’t Saltlake shutting down anytime soon?

10

I do not see this satellite in this announcement

11

I thought all satellites and test data had the same fate, my mistake

12

You can just wait until this satellite sends more audits. You may be suspended in the mean time, but 2 more online audits and you’re fine again. There is barely any ingress from this satellite at the moment anyway. It should resolve itself.

2 Likes
13

The node is working fine from what I can see. So all I need to really do is wait and recover? It’s been overnight and it’s still at 0% so idk how long until that recovery begins.

15

The node is working fine from what I can see and I left it overnight.

16

Audits are infrequent on nodes with little data. You only had one for that satellite so far. So it might be a few days until you see another one. Do you see any message at the top of your dashboard about the node being disqualified or suspended on that satellite?

1 Like
17

There’s nothing about my node being suspended or disqualified, just the 0% in red like it the screenshot above.

18

Then you need only wait, when your node would start answer on audit requests.