How long should gLiveView show a block as "Adopted"?

Staking & Delegation Operate a Stake Pool
1

I’ve had a block listed as “adopted” for about 24 hours now. Is this normal? I would assume “Adopted” was supposed to last just a few seconds, not days.
clcli is still syncing so I can’t view the leaderlogs yet.
Thanks!

2

How do u sync the cncli?

u must run ./cncli.sh sync (it will sync faster)

PS: the infos from glive are hystorical so, u will see till u will restart the node (if there are from a past epoch)

3

I think it’s just the default service. I’ll try the sync command and get back to you.

And I have restarted the node because I was adding the relay to my topo so it connects in both directions. The 2 adopted blocks are still there.

4 
/opt/cardano/cnode/scripts$ ./cncli.sh sync
 2021-04-27T19:00:46.193Z WARN  cardano_ouroboros_network::protocols::chainsync > rollback to slot: 6962466
 2021-04-27T19:00:46.193Z INFO  cardano_ouroboros_network::protocols::chainsync > block 4613144 of 5645891, 81.71% synced

It just sits here looking like it’s doing nothing, but it’s using up 100% of the CPU core it’s running on.
Previously when I ran it manually (and without the sync command) it was spitting out an update every couple of minutes, but it would change by 0.01% every hour.
When I run ./cncli.sh leader log in another terminal it give me this:
/opt/cardano/cnode/scripts$ ./cncli.sh leaderlog
~ CNCLI Leaderlog started ~
CNCLI still syncing [97.2933 %], checking again in 60s
CNCLI still syncing [97.2931 %], checking again in 60s
CNCLI still syncing [97.2930 %], checking again in 60s
CNCLI still syncing [97.2928 %], checking again in 60s
CNCLI still syncing [97.2925 %], checking again in 60s
CNCLI still syncing [97.2924 %], checking again in 60s
CNCLI still syncing [97.2924 %], checking again in 60s
So it looks like it’s doing something…

5

SOLVED! putting vrf.vkey in the private folder and restarting ./cncli sync made it jump by 0.5% every couple of seconds.

edit: nevermind, it’s back to going super slow.

1 Like
6

Try to update the cncli… are u using the latest version?

7

I think I am but I don’t see a version number anywhere so I’m following the update instructions on the repo.

1 Like
8

updated to 2.0.3 from 2.0.2
Now when I try to run ./cncli.sh sync I get this:
/opt/cardano/cnode/scripts$ ./cncli.sh sync
2021-04-27T22:05:18.347Z WARN cardano_ouroboros_network::protocols::chainsync > rollback to slot: 6962466
2021-04-27T22:05:18.348Z INFO cardano_ouroboros_network::protocols::chainsync > block 4613144 of 5646437, 81.70% synced
/opt/cardano/cnode/scripts$
it just quits on its own now.

edit: and always the same block numbers

9

renamed guild-db to guild-db.old and restarted the cncli service.
now it seems to be rebuilding it from scratch, and it going MUCH faster. additionally, the leaderlog service logs sync percentage are actually going UP now instead of down. maybe my db was just corrupted.

only downside is those blocks are gone from gLiveView but as I understand it that’s just reading the leaderlog and they’re still there, just not seen yet. edit: I guess it’s also possible that they were never there to begin with, and just part of that corrupt db?

RE-RE-RE-EDIT:
yeah that did it. synced in less than an hour. Now I’m seeing the leader countdown and everything else.
Apparently I missed a block and had one stolen. Guess I need to look into that, too.

1 Like
10

The same happened to me. Removing the old db fixed it but do you know why it happened in first place?

1 Like
11

no clue, sorry.

1 Like