Is it possible to recontinue, or do I have to setup up a new node?
If your node is suspended you can still recover by keeping it online and successfully completing audits. While the node is suspended, it won’t receive ingress, but still gets egress and audits.
If you are not aware of the reason your node got suspended, I would first try to figure out what failed (too much downtime, failed audits, etc) and resolve that issue.
If all issues that resulted in the suspension are fixed and you keep your node running, it should eventually recover from the suspension and start working normally. Otherwise, it will eventually get disqualified which is permanent.
3 Likes
Hello @pasatmalo,
Welcome to the forum!
If you have a suspended node because of a low online score (less than 60%), then you need to fix this issue and keep your node online for the next 30 days to fully recover. Each downtime event requires additional 30 days to recover.
If you have a suspended node because of a low suspension score (below 60%), you need to figure out what’s causing this:
and fix this issue. It unlikely will fix itself.
This suspension score is growing back with every successful audit, so your node is failing audits for unknown reasons (if they are known, the audit score will be affected instead).
Thus this situation is more dangerous than being offline (except being offline for more than 30 days), failing audits usually lead to a disqualification at the end.
Ouch. The suspension score is affected. You need to figure out ASAP, what’s causing this.
Those ones which have zero likely will be disqualified pretty soon unless you fix the underlaying issue with audits.
This makes not wizer
C:\Program Files\Storj\Storage Node\storagenode.log:29744147:2024-05-02T09:01:11+02:00 ERROR piecestore download failed
{“Piece ID”: “Z7S5X3UJSD3FUTW5QJCB43YQSEG4EXC522CI4TTZPAO4JXJMDEPA”, “Satellite ID”: “12EayRS2V1kEsWESU9QMRseFhdxYxKic
siFmxrsLZHeLUtdps3S”, “Action”: “GET_REPAIR”, “Offset”: 0, “Size”: 52992, “Remote Address”: “5.161.116.155:56864”, “err
or”: “order created too far in the future: OrderCreation 2024-05-02 09:01:21.8609835 +0000 UTC > SystemClock 2024-05-02
09:01:11.149274 +0200 CEST m=+146659.064554801”, “errorVerbose”: "order created too far in the future: OrderCreation 2
024-05-02 09:01:21.8609835 +0000 UTC > SystemClock 2024-05-02 09:01:11.149274 +0200 CEST m=+146659.064554801\n\tstorj.i
o/common/rpc/rpcstatus.Errorf:90\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).verifyOrderLimit:47\n\tstorj.io/s
torj/storagenode/piecestore.(*Endpoint).Download:622\n\tstorj.io/common/pb.DRPCPiecestoreDescription.Method.func2:302\n
\tstorj.io/drpc/drpcmux.(*Mux).HandleRPC:33\n\tstorj.io/common/rpc/rpctracing.(*Handler).HandleRPC:61\n\tstorj.io/commo
n/experiment.(*Handler).HandleRPC:42\n\tstorj.io/drpc/drpcserver.(Server).handleRPC:167\n\tstorj.io/drpc/drpcserver.(
Server).ServeOne:109\n\tstorj.io/drpc/drpcserver.(*Server).Serve.func2:157\n\tstorj.io/drpc/drpcctx.(*Tracker).track:35
"}
Could you check if the time is set correctly on the node? If it is not corrected automatically using NTP or similar, it will be inaccurate after a while.
1 Like
PERHAPS, a new NTP interception is introduced on the firewall.
Mvh
Bjørn Arne Restad
Mobil: (+47) 41 45 45 45
1 Like
Ok. So you have a big time discrepancy with the World Clocks. Please sync them. If you uses Windows, you need to use an external tools, because the integrated time sync is tolerate to a few minutes difference, which is for the crypto world a fatality: https://www.timesynctool.com/