Recent disqualification query

[brad-pea]

Hi All,

Have been a long time node operator and everything has been running smoothly for many months. I check in on the node every so often (also get alerts if anything goes down etc…) but when checking just now it appears my node has been disqualified on all satellites. Looking at the logs I can see a complaint of “node is still considered to be online but encounter an error” … looking into it further it appears that this is / was because UDP port 28967 was not open… I did not believe this to be a requirement when I originally set up years ago and as I say all has been working fine and TCP 28967 opened ever since start up.

Is this a recent implementation / requirement - I notice there is QUIC which looks to be new too…

In summary, is it at all possible to get my node un disqualified or is starting again my only option ?

Thanks.

[Bivvo]

@brad-pea

Looking at the logs I can see a complaint of “node is still considered to be online but encounter an error”

Can you share the timestamp, please? Would be helpful to figure out if that’s a software issue or if you have overseen that issue for too long, which would have lead to your disqualification.

Pls also see this recent post; there’s no way back …

[Pac]

As far as I know that is not a requirement. Not yet at least.
A friend of mine still has their nodes misconfigured with regards to UDP, and they did not get disqualified.

@brad-pea Disqualification is usually due to Audit failures. They can be searched with commands such as:

docker logs YOUR_NODE_NAME 2>&1 | grep -E 'GET_AUDIT' | grep 'failed'

(this is for docker logs, the command needs to be changed if your logs are redirected to a file)

If it turns out to be a software bug, the support team may un-disqualify you, but past experience showed that this case is almost non-existant
When a node gets disqualified, it’s either because it did not replied correctly to audits or stayed offline for too long. Either way, there’s no way back.

I’m sorry

Now, many SNOs still don’t get why there’s no alert prior to being abruptly disqualified, that is a topic that has been discussed many times in the past, with no obvious consensus yet.

See:

Put the node into an offline/suspended state when audits are failing

Following up this thread regarding a problem I had on my node which led to a disqualification, I would kindly ask the development team to add a feature which would put the node “on hold” in case of audit fail to avoid being disqualified. The SNO operator will then have a certain number of days to fix the problem before being disqualified. Summarising the thread linked above: I got disqualified on 4 satellites in a matter of hours I had no clues at all on what was going on because the log was …

[ZBS]

QUIC is recommended but not required. If node got DQ is for some other reason or a bug.

Also the “node is still considered to be online but encounter an error” message, come from connection issue (like IP/port/DNS misconfigured). If TCP port is fine, check if your current IP is the same as the configured or if you use a DNS, check if it points to the correct IP

are you sure it got disqualified and not just suspended?

[brad-pea]

Thanks - I will create a new identity and start over. Do I need to uninstall / reinstall Storj Gui after doing that or do I just need to update the config.yaml file ?

Anything else required other can creating and signing a new identity?

Thanks

[Alexey]

You need to uninstall program, delete C:\Program Files\Storj folder and data from data location, then generate a new identity, sign it with a new authorization token, check it, and install storagenode again.

[brad-pea]

Thanks - done that and all back up and running!