Node sync time keeps increasing - ver 3.2.1

My (non-archival, participant) node was running fine for a couple of days. Then, ‘Sync time’ in ‘goal node status’ has started increasing. I did various troubleshooting as follows but the same problem is still there. Can someone help me?

• To not cause any impact on mainnet, changed the node status to offline
• In config.json, set “DNSSecurityFlags”: 0 and “EnableBlockServiceFallbackToArchiver”: false
• restarted ‘algorand’ service, then, did fast sync

[/var/lib/algorand]$ goal -v

12885032961

3.2.1.stable [rel/stable] (commit #b6cbbf34)

go-algorand is licensed with AGPLv3.0

source code available at GitHub - algorand/go-algorand: Algorand's official implementation in Go.
[/var/lib/algorand]$ goal -v

12885032961

3.2.1.stable [rel/stable] (commit #b6cbbf34)

go-algorand is licensed with AGPLv3.0

source code available at GitHub - algorand/go-algorand: Algorand's official implementation in Go.

[/var/lib/algorand]$ goal node status

Last committed block: 17952864

Time since last block: 2.8s

Sync Time: 2689.5s

Last consensus protocol: GitHub - algorandfoundation/specs at bc36005dbd776e6d1eaf0c560619bb183215645c

Next consensus protocol: GitHub - algorandfoundation/specs at bc36005dbd776e6d1eaf0c560619bb183215645c

Round for next consensus protocol: 17952865

Next consensus protocol supported: true

Last Catchpoint:

Genesis ID: mainnet-v1.0

Genesis hash: wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=

Hi Cryptocurv,

This is due to a (benign) bug in the catchup logic. It should not affect the actual catchup or agreement. Regardless, it has been fixed and V3.2.2 has been prepared and I expect it to go to BetaNet Monday with a stable release coming another 48 hours later.

Ben

Hi Ben,

What would you recommend to check if my node is participating without an issue?

For example, is there a way to know if my node is misbehaving or not with regard to being ‘dishonest’ or ‘penalized’? When the issue started, I noticed bunch of pending txns on my node - goal node pendingtxns.

Thanks!

You can look through the logs to see that its keeping up to date and processing transactions correctly.

The node is definitely not being dishonest, though it may be attempting to request block more frequently than it needs to.

There is no concept of penalization besides the possibility of being ranked lower on a peer list by another node if your node is slow to return blocks.

Ben

Got it.

Thanks bunches, Ben!

Hi Ben,

i’ve got the same issue…

in logs everything seems ok

The result i see is just dramatic drop in traffic and connections.

But the nodes seems to be synchronized and shows the correct block even little before the algoexplorer with watch goal node status

Hi Scholtz,

Is your node a participant node? If so, is your pending txns increasing?

it is archival relay node

pending txns does not increase

Can you quantify dramatic drop?

The bug in question should only affect the nodes recognition that catchup is completed. The effect is that the sync counter keeps increasing and it requests more blocks than it needs to

image954×1050 57.4 KB

Perhaps its just because i restarted it in 2 months… Also for few minutes it was probably not synchronized.

Btw, this is my kubernetes setup AlgorandNodes/statefulset.yaml at main · scholtz/AlgorandNodes · GitHub

Small remark: since your node is apparently not a relay, it should be not ranked. As @Ben explained, participation nodes are currently not penalized @Cryptocurv .

However, it is very important for the network that participation nodes work properly.

You can either check the logs or use AlertHub (Metrika AlertHub) to monitor your node.

Hi Fabrice,

My node has been recovered and is working. Yes, I’m using AlertHub to monitor my account and voting status. Things look good there.

image918×494 16.7 KB

Thanks

i have upgraded today to 3.2.2 and everything seems to work perfectly…