Using CNCLI leaderlog script we can see blocks allocated in the next epoch and the node successfully processes the blocks on schedule.
After running the cncli leaderlog, gLiveView “BLOCKS” section successfully updates to show Leader 1 and displays the countdown. The block is minted correctly as confirmed on pooltool and adapools, but gLiveView never updates the “adopted” or “confirmed” fields.
This has happened for 3 successive blocks.
Thanks for the reply. I ran ./deploy-as-systemd.sh
It prompted for topology updater, Ptsendtip and leaderlog as you mentioned. I selected N.
It then automatically installed everything from that point without further prompts.
I rebooted the computer and gLiveView wouldn’t work. I found the reason was systemd had started two cardano-node services.
I killed the node service relating to cnode (cncli presumably) and deleted the 2x systemd files that had been created in /etc/systemd/system/
So back to normal at the moment.
Is there any way I can start cncli with systemd without it starting up a duplicate node instance? Or would I have to delete my existing coincashew systemd service and just use the cncli one?
Will do. I purposefully avoided the coincashew cncli section originally, as I like a simple, paired back approach.
So I installed using prereqs and ran the scripts manually which works well, except for the gLiveView not updating to confirm.
To confirm, if I set up cncli.sync as a systemd service, this will cause gLiveView to update blocks correctly? I have tried leaving cncli.sync running in a terminal perpetually, during the moment a block was minted, and gLiveView still didn’t update to confirm the block. The block was successfully minted per pooltool and adapools.
Yes I think you’re on to something with the cncli-validate service + cncli sync
“validate Continously monitor and confirm that the blocks made actually was accepted and adopted by chain (deployed as service)”
I’m fairly confident cncli init will work to one-off update, each time it is manually run. I’ll have to get back to you on that later.
If I want to stop gLiveView looking at cncli info, reverting it to EKG? instead, how would I do that?
So redoing ./deploy-as-systemd.sh
No cnode or related processes appear until computer restart.
Upon restart there are two cardano-node processes and one cnode process. There are none of the below processes.
sudo systemctl status cnode-cncli-sync.service
sudo systemctl status cnode-cncli-leaderlog.service
sudo systemctl status cnode-cncli-validate.service
sudo systemctl status cnode-logmonitor.service
Perhaps they require the node to be fully started which is problematic when two instances exist?
The node was installed using coincashew guide.
cncli installed using prereqs command, but no sysemd configs. Only running sync and leaderlog manually.
I notice in the coincashew guide they only enable cncli sync as systemd (and sendtip). Unless sendtip is somehow read by gLiveView, it seems neither would cause gLiveView to update adopted/confirmed blocks.
A series of cncli scripts will appear in /opt/cardano/cnode/scripts
Navigating to this directory in terminal you can run ./cncli.sh sync
followed by ./cncli.sh leaderlog (after 1.5 days remain in the epoch)
gLiveView will then show the countdown timer to the block. Pooltool and adapools will confirm the block if your block producer processes it successfully.