Leader blocks not minted at 3 occasions: error or just bad luck?

Hi ,
I have recently (from epoch 259) started using CNCLI leaderlog to estimate when to mint blocks. CNCLI assigned me as a leader twice in epoch 259 and once now in epoch 262. However none have been registered as adopted, confirmed, missed or anything else (ref screenshot below)
Is this an error or just bad luck?
For information I successfully minted a block in epoch 251 so in that sense my pool seems properly configured and connected.

image

Cheers FLOW pool

To much bad luck if u ask me;
Check the functionability of the Producer

hmmm, ok… :thinking:
Any advice how to check the functionality of the producer?

Check if the Producer has IN/OUT peers, if it’s processing tx, if the KES are not expired, etc

PS: try to run again the cncli

./cncli.sh leaderlog force to see if the block was stollen

Cheers,

Thanks for suggestions, but my two relays are connected and the producer is processing TX:

image

image

I don’t think that is bad luck - the leaderlog runs the same algorithm as the node itself, it is very accurate and (at least for me) has never failed. Perhaps you’d like to check the logs for at the exact times that leaderlog predicted.

There are folks reporting relay crashes for yet unknown reasons since 1.26.2, which I’ve also seen with Docker. Since then I auto restart my nodes like this

  relay:
    image: nessusio/cardano-node
    container_name: relay
    restart: unless-stopped
    hostname: relay
    networks:
      cardano:
    ports:
      - "3001:3001"
    environment:
      CARDANO_TOPOLOGY: '{
          "Producers": [
            {
              "addr": "relays-new.cardano-mainnet.iohk.io",
              "port": 3001,
              "valency": 1
            },
            {
              "addr": "xxx.xxx.xxx.xxx",
              "port": 3001,
              "valency": 1
            }
          ]
        }'
      CARDANO_CUSTOM_PEERS: "xxx.xxx.xxx.xxx:3001"
      CARDANO_UPDATE_TOPOLOGY: "true"
    command: "run"
    volumes:
      - /mnt/disks/data00:/opt/cardano/data

Although you can resonably expect to win 17.4 blocks per year, the chances of not winning a block in any given epoch sits at 79%. This is a property of the Bernoulli distribution that actually works in favour of your potential delegators.

Hi and thanks for reply.
Exactly which logs should I check?

You can configure file logging in the config. Otherwise it would be however your system tracks the console output (i.e. sysout) for a given process.

Thanks for suggestions. Not really sure how to use “sysout”, but the producer node show this when using the command:
journalctl -e -f -u cnode.service

As far as I understand there are no signs of anything wrong registered when the block was assigned:
image

Did u installed chrony on your nodes? Perhaps u have a time sync issue

no I have not installed chrony

Hmm, then this could be the problem
It is recommended to use it

1 Like

ok thanks then I’ll try that.

Here is the link which I used it

thanks for link. One learns something new each day :slight_smile:

Yeah, there were other POs which had this issue and after chrony installation they minted the blocks succesfully;

Indeed if the nodes are not in sync with the network then the blocks can be mised

Good to know. Then I’ll cross my fingers and report back next time I am assigned a block…

1 Like

Hi again.
Today I was assigned a new block but this was not minted as the ones before and not registered in any of the categories below:
image

I have installed Chrony and also rotated my KES several times to assure that the cold.counter used is the latest (which I read somewhere could be an issue). As mentioned above I minted a block in epoch 251. I should also mention that I reinstalled the block node using CNTOOLS after this. Can this be the cause, i.e. perhaps be some problems with my keys, or any ideas what to do to fix this?

Oh dear - not again. The log file should be saying something, doesn’t it?

Your system clock is in synch, right?

image

What is your missing slots count?