Missed block

[Anti.biz]

Can someone please tell me what happened? Is it a false alarm?

{"host":"block","pid":"3741687","loc":null,"at":"2022-03-04T17:22:57.89Z","ns":["cardano.node.KeepAliveClient"],"sev":"Info","env":"1.34.0:c23d5","data":{"outboundG":0.124358388388,"kind":"KeepAliveClient AddSample","rtt":0.242788247,"address":"ConnectionId {localAddress = 192.168.0.10:36553, remoteAddress = 194.233.92.68:6000}","sampleTime":"1026451.561875313","inboundG":0.124358388388},"msg":"","thread":"164945","app":[]}
{"host":"block","pid":"3741687","loc":null,"at":"2022-03-04T17:22:58.00Z","ns":["cardano.node.LeadershipCheck"],"sev":"Info","env":"1.34.0:c23d5","data":{"utxoSize":6016578,"kind":"TraceStartLeadershipCheck","delegMapSize":1169370,"credentials":"Cardano","slot":54848287,"chainDensity":4.6236213e-2},"msg":"","thread":"416","app":[]}
{"host":"block","pid":"3741687","loc":null,"at":"2022-03-04T17:22:58.00Z","ns":["cardano.node.Forge"],"sev":"Info","env":"1.34.0:c23d5","data":{"val":{"kind":"TraceNodeNotLeader","slot":54848287},"credentials":"Cardano"},"msg":"","thread":"416","app":[]}
{"host":"block","pid":"3741687","loc":null,"at":"2022-03-04T17:22:59.00Z","ns":["cardano.node.LeadershipCheck"],"sev":"Info","env":"1.34.0:c23d5","data":{"utxoSize":6016578,"kind":"TraceStartLeadershipCheck","delegMapSize":1169370,"credentials":"Cardano","slot":548

[georgem1976]

I see 2 possible reasons for that:

1. Corrupted cncli database
2. Wrong VRF key

To fix the first problem, you need to stop the cncli sync service, delete the database and start the cncli sync service.

For the second problem, you need to check the registered VRF key hash ad the hash of the VRF key used to start the service. They should match.

[Anti.biz]

How do you check the VRF key hash and the hash of the VRF key to start the service?

Also my pool just made 2 blocks.

[SKULL] 🕱

[georgem1976]

If your stake pool minted 2 blocks and they were adopted, you don;t have to check the VRF key, it means it’s OK. This is good, because correcting this takes more time.
Recreate the cncli sync database, this is the most common reason, and this is also why I listed it as the first possible problem (because it happens more frequently).

[Anti.biz]

@georgem1976

stake pool minted 2 blocks and they were adopted, you don;t have to check the VRF key, it means it’s OK. This is good, because correcting this takes more time.
Recreate the cncli sync database, this is the most common reason

What are the steps to fix the cncli sync database?

[georgem1976]

Exactly what I wrote in my first comment:

To fix the first problem, you need to stop the cncli sync service, delete the database and start the cncli sync service.

[Anti.biz]

How do you stop the cncli sync service?

Which database to delete?

[georgem1976]

I can tell you how it is on my servers, but this will not help you, because I am not using the default paths from guild tools and I am not using the default service they provide, I created my own service for that.
You have to check in your “env” file used by the guild tools, I believe the path is in the “BLOCKLOG_DIR” variable. I believe the default setting is to keep the cncli database and blocklog database in the “guild-db” folder (probably /opt/cardano/cnode/guild-db).
The service should be called “cnode-cncli-leaderlog” and the database you have to delete should be “/opt/cardano/cnode/guild-db/blocklog/blocklog.db”, if you are using the default paths / settings.

[Anti.biz]

so after i delete it how do I re sync it? and stop the service?

[georgem1976]

Ok, so it seems you are using the defaults. You will probably need to do this:

1. Stop the service by running:

sudo systemctl stop cnode-cncli-leaderlog.service

2. Delete the database:

rm  /opt/cardano/cnode/guild-db/blocklog/blocklog.db

3. Start the service:

sudo systemctl start cnode-cncli-leaderlog.service

It will probably take a few minutes after the start, but after that the problem should be fixed.

[Anti.biz]

@georgem1976

sudo systemctl start cnode-cncli-leaderlog.service

alright ran the commands thanks!

You wouldnt happen to know the new leaderlog command for 1.34?

[georgem1976]

Of course I know it. It should be like this, but you have to provide the correct path to the files in the command and the correct pool ID (this is for SKULL, it seems to be your stake pool):

cardano-cli query leadership-schedule --mainnet --genesis /opt/cardano-cnode/<your_path_to_config_files>/mainnet-shelley-genesis.json --stake-pool-id bbd852e7fb67e8f182def1f99d22a51c76b40222ab47d0682223e606 --vrf-signing-key-file /opt/cardano-cnode/your_path_here/vrf.skey --current

This is for the current epoch. For the next one (after 70% progress, so about 1.5 days before epoch’s end), you can replace --current with --next and it will give you the allocated slots for the next epoch.

[Anti.biz]

[georgem1976]

You need to set the environment variable CARDANO_NODE_SOCKET_PATH in your .bashrc file. Something like this (you have to check the exact path in your case):

export CARDANO_NODE_SOCKET_PATH=/opt/cardano/cnode/db/node0.socket 

You can also execute this in command line before running the leadership schedule command.

[Anti.biz]

how do I refresh my bashrc?

[georgem1976]

source ~/.bashrc

Or logout and login again.

[Anti.biz]

[georgem1976]

@georgem1976

export CARDANO_NODE_SOCKET_PATH=/opt/cardano/cnode/db/node0.socket 

@Anti.biz you missed the “export”, which is very important.

[Anti.biz]

thanks appreciate your help

[Anti.biz]

trying to run this , I missed a block on my new block producer that I transitioned to in the cloud. I ran the steps again but cant execute this command, any help is appreciated. @georgem1976

I figured it out my bashrc was wrong