Hello ,
I need some help:
node was built with coincashew
coincashew auditing script successfull.
yesterday i was slotleader but the slot 98586175 was not adopted (first block ever minted).
Node is online since two years. several new nodes seems to work.
Node 8.1.1 installed. two relay nodes and one core.
Chrony installed.
KES 60 days left
First : the slot was sceduled for 22:47 but the slot was calculated 3 hours later 00:40, this was somewhat irritating.
In the moment i was leader in glifeview two "missed shlot leader checks occurred and the core had no TX traffic for estimated 2 minutes.
The net was not weak, relays had a lot of tx and normal communication to core.
besides: since several month a had some forks (weekly around 500), independent of the nodes i used, this seems a lot to me.
Ticker FMS
Could someone help me.
Florian
f
Hi
Have you checked the logs on your bp to see if there is a clue of what happened?
First : the slot was sceduled for 22:47 but the slot was calculated 3 hours later 00:40, this was somewhat irritating.
What do you mean by this?
not yet, I will check later today , yesterday it was too late
I performed a Cli query cardano-cli query leadership-schedule several times
the result was stable 22:47 2023-07-23 . The block was calculated 00:40 UTI (german time) 2023-07-24.
i have read that synchronisation is pivotal with regard to slotleader checks. My idea was, that , even thought chrony is installed, a time-synchronisation problem could be the issue. I will also check KES opCertExpectedKESEvolutions
sudo journalctl --unit=cardano-node -g InvalidKesSignature
could you please recommend any further query
best regards
Sorry, I’m still not sure what you mean by this?
The logs should give you some clues.
You can also run this to check your kes:
CARDANO_NODE_SOCKET_PATH=/path/to/node.socket cardano-cli query kes-period-info --mainnet --op-cert-file /path/to/op.cert/
1 Like
Upgrade the nodes to 8.1.2
the time stamp thing was misleading in my mind. Slot leader check is UTI (London time) and my bare bone is Berlin UTI + 2 (not 3) , this theme is solved.
Log for 22:47 UTI :
Could you help me in interpretation. slot number was 98586175
i think It seems to be a KES (qKesOnDiskOperationalCertificateNumber)-problem and i made new kes keys and a new node.cert. This also restored my leader 1 to 0.
But also it seems to be a relay core communication theme? here i do not have a good idea. Could you help me out? This would be an explanation for missing TX for some seconds/minutes.
with new KES keys
"qKesCurrentKesPeriod": 761,
"qKesEndKesInterval": 823,
"qKesKesKeyExpiry": "2023-10-25T09:44:51Z",
"qKesMaxKESEvolutions": 62,
"qKesNodeStateOperationalCertificateNumber": null,
"qKesOnDiskOperationalCertificateNumber": 23,
"qKesRemainingSlotsInKesPeriod": 7993691,
"qKesSlotsPerKesPeriod": 129600,
"qKesStartKesInterval": 761 it hopefully works next time, BUT
should i change “qKesNodeStateOperationalCertificateNumber”: null in 0 (zero)? if so, how to do this
could you recommend something else to do?
best regards and thanks in advance
Check this out:
As you have not yet made a block “qKesOnDiskOperationalCertificateNumber” should be 0.
