Missed block

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

image

{"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

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.

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.

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).

What are the steps to fix the cncli sync database?

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.

How do you stop the cncli sync service?

Which database to delete?

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.

1 Like

image
image

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

image

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
  1. Delete the database:
rm  /opt/cardano/cnode/guild-db/blocklog/blocklog.db
  1. 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.

1 Like

image
alright ran the commands thanks!

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

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.

1 Like

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.

image

how do I refresh my bashrc?

source ~/.bashrc

Or logout and login again.

image

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

1 Like

thanks appreciate your help

1 Like

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