gLiveView has OP Cert Disk disk|node|chain 2 | 2 |?


My server is running node 8.7.2 and I have gLiveView v1.28.3 and I have a question mark displayed for the chain on the BP. KES is still current. gLiveView in verbose mode is not displaying pool percentage, delegation or operator cost either. I jumped from 8.1.2 to 8.7.2 and rebuilt all servers … Everything seems fine …

OP Cert Disk disk|node|chain 2 | 2 |?

I’m not using P2P for the BP and the BP it is connected to my relays and the relays are in P2P mode to the outer world. BP and relays are all NSYNC and current.

I use bare metal hardware and it is not slow …

Thank you,


I have a very similar question and hoping someone from Guild Operators team help out here:

  • this is my healthy rotation on preprod and disk|node|chain seem to be in alignment 7 | 7 | 7
    Screenshot 2024-01-05 at 11.09.08 AM

  • But on my mainnet it shows 18|17|17
    Screenshot 2024-01-05 at 11.18.56 AM

Does this indicate an issue? Maybe i entered the incorrect counter value? Cant find any good documents that explain the disk|node|chain values

Same for me, I just upgraded to 8.7.2 and v1.28.3 from 8.1.1
Cert is still valid, but this indicator is showing 9 | 9 | ?
Am trying to understand if there is something I need to be aware of or take action on.

I see 5 | 5 | ?

what is the question mark?

I am running 8.1.2 with gLiveView 1.28.3


Hey Folks,

I never resolved this. Anyone have a good answer on how to configure gLiveView in verbose mode?

Thx, Bumpy McFly

Same for me. Node 8.7.3 on Core Mainnet for block producer.
Didn’t found a solution so far.


Exactly the same thing here — two question marks for disk|chain after a recent gLiveView upgrade and an upgrade to 8.7.3. I guess the underlying problem had always been there and just surfaced now.

The kes / node / vrf files are all current and there are no error messages w.r.t. the files in the logs. The current|remaining|exp numbers look fine and unsurprising.

This kind of spirals back to my usual question about how likely it is that a pool with a 30k+ stake and a 30k pledge produces precisely zero blocks in 2.5 years of operation.

I doesn’t seem to affect the block production. I upgraded 2 weeks ago and minted one block on node 8.7.3 with 128k ADA live stake and 16K pledge. Running full speed for about 6 months now and 6 blocks minted so far.

Struggled in the beginning and found out my block producer was not running as a block producer (core - mainnet) but as a relay node (relay - mainnet) => see at top in GliveView. Got some great help on this forum from the community.

Also be sure your node.cert is valid when turning KES.

You need to set your node.cert path in the env file (it’s down near the bottom). If you’ve setup via the Coincashew guide, then it is in a differen file path that gLiveView expects by default.

30k stake is quite low, so there is a low chance to get a block. 2.5 yrs without a block is bad luck, but it all comes down to luck (unless there is something wrong with your pool setup).

Have you been checking your leaderlogs each epoch?

Actually, this was a bug in So even though I did get the node.cert path (which is what I call that file) resolved correctly, the cardano-cli and jq failed. Here’s what was needed:

--- a/scripts/cnode-helper-scripts/
+++ b/scripts/cnode-helper-scripts/
@@ -539,7 +539,7 @@ getOpCert () {
     op_cert_tsv=$(jq -r '[
     .qKesNodeStateOperationalCertificateNumber //"?",
     .qKesOnDiskOperationalCertificateNumber //"?"
-    ] | @tsv' <<<"$(${CCLI} ${NETWORK_ERA} query kes-period-info ${NETWORK_IDENTIFIER} --op-cert-file "${opcert_file}" | grep "^[{ }]")")
+    ] | @tsv' <<<"$("${CCLI}" "${NETWORK_ERA}" query kes-period-info "${NETWORK_IDENTIFIER}" --socket-path "${CARDANO_NODE_SOCKET_PATH}" --op-cert-file "${opcert_file}" | awk '/^[{]/{o=1}o;/^[}]/{o=0}')")
     read -ra op_cert_arr <<< ${op_cert_tsv}
     isNumber ${op_cert_arr[0]} && op_cert_chain=${op_cert_arr[0]}
     isNumber ${op_cert_arr[1]} && op_cert_disk=${op_cert_arr[1]}


  • It requires --socket-path. (Perhaps an environment variable was missing or a default location where cardano-cli would look for it doesn’t match reality on my system.)
  • The grep filtering missed an additional header line before the JSON data in the output, which was causing jq to fail. It’s sad that cardano-cli doesn’t keep its /dev/stdin clean in pure JSON; additional plain text information should go to /dev/stderr for optional filtering / inspection…

Now it gives me the right on-disk certificate number. \o/ The on-chain certificate stays at ?, because (obviusly) no blocks → no on-chain certificates. /o\

1 Like