Yes, it is strange… I don’t have any idea… but can u try to search in one relay node? But As I told u above… none of these slots were created so… probably you will not find anything
This is my config… do u see any strange in yours?
Yes, it is strange… I don’t have any idea… but can u try to search in one relay node? But As I told u above… none of these slots were created so… probably you will not find anything
This is my config… do u see any strange in yours?
Thank you again for continuing to help give me support… I do see a couple of differences…?
"TraceTxInbound": false,
"TraceTxOutbound": false,
"TraceTxSubmissionProtocol": false,
"TraceHandshake": false,
"ViewMode": "SimpleView",
"cardano.node-metrics": [
"EKGViewBK"
],
"cardano.node.metrics.connectedPeers": [
"EKGViewBK"
],
"cardano.node.metrics.ChainDB": [
"EKGViewBK"
],
"cardano.node.metrics.Forge": [
"EKGViewBK"
],
"cardano.node.peers": [
"EKGViewBK"
],
"mapSubtrace": {
"#ekgview": {
"contents": [
[
{
"contents": "cardano.epoch-validation.benchmark",
"tag": "Contains"
},
[
{
"contents": ".monoclock.basic.",
"tag": "Contains"
}
]
],
[
{
"contents": "cardano.epoch-validation.benchmark",
"tag": "Contains"
},
[
{
"contents": "diff.RTS.cpuNs.timed.",
"tag": "Contains"
}
]
],
[
{
"contents": "#ekgview.#aggregation.cardano.epoch-validation.benchmark",
"tag": "StartsWith"
},
[
{
"contents": "diff.RTS.gcNum.timed.",
"tag": "Contains"
}
]
]
],
"subtrace": "FilterTrace"
},
"benchmark": {
"contents": [
"GhcRtsStats",
"MonotonicClock"
],
"subtrace": "ObservableTrace"
},
"cardano.epoch-validation.utxo-stats": {
"subtrace": "NoTrace"
},
"cardano.node-metrics": {
"subtrace": "Neutral"
},
"cardano.node.metrics": {
"subtrace": "Neutral"
}
}
},
"SocketPath": "/opt/cardano/cnode/sockets/node0.socket",
"NetworkName": "mainnet",
"EnableLogging": true,
"EnableLogMetrics": false
}
Are u using cntools right?
Also ur relays have those differences?
Cheers,
Yes using cntools, and yes, relays config files look to be the same.
Ok
I have this config on all my nodes… if u want to use it u can replace yours… bkp urs and try this one
Or u can try to ran again the prerequisits
cd “$HOME/tmp”
curl -sS -o prereqs.sh https://raw.githubusercontent.com/cardano-community/guild-operators/master/scripts/cnode-helper-scripts/prereqs.sh
chmod 755 prereqs.sh
./prereqs.sh -f
. “${HOME}/.bashrc”
check/write from ur keyboard “ “ - the forum change the format
and check if ur config file has been downloaded again
I will try your config and also redo the pre-reqs and even the node installation from scratch and just copy over my keys. Something must be wrong but I do not understand what it could be. I have also gone through the steps to confirm my vrfkey is properly registered using these instructions and my key matches exactly what is on the ledger:
I think only the configuration file only should be replace
Nevertheless, an attempt must be made to determine the cause. Yesterday we had the same problem, that an announced block has not been realized.
on the cncnli script, do you have the correct POOL ID?
Nevertheless, an attempt must be made to determine the cause.
Yes, I would very much like to understand the cause. We have now missed 3 blocks with no explanation. How do we investigate further?
on the cncnli script, do you have the correct POOL ID?
I am using the latest CNCNLI script and populating every parameter at the command line:
Hello - Question for you all while I continue to try and investigate this…
Is the Epoch Nonce value unique to my pool? Or common? Is everyones Nonce value the same for Epoch 252?
Hello everyone -
I am excited to announce that this morning my pool DID mint a block. The issue, although I am unsure why, is that CNCLI was calculating the wrong epoch nonce when running the leaderlogs which was producing an incorrect leader schedule. I discovered this when I built a new block producing node over the weekend and when I ran cncli for the first time on that node it returned a different Nonce value and indicated that we had not yet ever missed any blocks.
I would like to know more about how nonce is determined to avoid this in the future, but for now I am happy that things appear to be working!
Thank you everyone for your help, especially @Alexd1985 who is always very active on these forums.
Hi mcvetyty,
I’ve got the same issue. My pool has minted blocks, but cncli-leaderlogs
scripts are not showing the correct nonce value.
I’m using the Coincashew instructions here
My sqllite database is 100% synced using cncli-sync
and the block height looks good compared to mainnet. I ran the cardano-cli query ledger-state
and dumped ledger-state.json
to same directory where I run the commands. But, nonce is still not correct.
Did you ever solve that problem?
Thanks
Hi there - I did solve it, but not in the most graceful or efficient way. I ended up rebuilding the pool on a new server from scratch. After that the nonce and everything else worked correctly. Sorry I couldn’t be of more assistance…
Thanks… Funny, but I got mine working just now, too.
I wiped out the cncli.db files and resynced again. This time it synced in about 30 mins as compared to the last time, when it took many hours. I increased my swap file size to 10GB, so that probably helped.
So, I think it boils down to the sqllite db file. I don’t even know if the ledger-state.json file is being used any more. The coincashew guide never mentions the ledger-state.json file, so I doubt it.
No, there is a faster and better way than ledger dump now. See the usage instructions on Github.
Hi georgem,
Can you tell me more? I don’t see anything in the cncli usage docs that refers to ledger-state or some better way.
In my case, I can run the cncli leaderlogs scripts without having a ledger-state.json file in the same directory where the scripts run.
This requirement does not appear to be necessary. Am I missing something?
Thanks!
Did you read this?
Yep, I am using the leaderlog command as described, so I think I’m all set.
Thanks