One of them:
http://163.172.47.168:10900/network/peering
And the other, the main node:
http://194.71.225.76:10900/network/peering
Last written block was: Block #479,602
1 Like
What tells you that? In fact, your identity is no longer into the blacksmith window.
Following command can tell you what are the latest found challenges:
grep -a "Done:" $HOME/.config/duniter/duniter_default/duniter.log
Otherwise, you should see such logs, saying that’s it’s computing:
Matched X zeros
You should check the logs to understand what’s wrong.
Not related, but did you set up a different prefix on your two nodes for them not to compute the same hashes?
What is Blacksmith window??
About not writing more blocks, I get this info on my Firefox Cesium tab (on the network section). There only one of my two nodes is shown and his block number is not the latest… I’m attaching an screenshot.
I have not results:
grep -a “Done:” $HOME/.config/duniter/duniter_default/duniter.log
I think so. In fact I’ve set up my second node some days ago and I think all went OK. About the prefix, it seems it’s OK here, isn’t it?
endpoints 0 “BASIC_MERKLED_API berta.calbasi.net 194.71.225.76 fe80::216:3eff:fe77:b7bc%eth0 10900” 1 “BASIC_MERKLED_API marx.calbasi.net 163.172.47.168 10900”
You can get this info here:
http://194.71.225.76:10900/network/peering (the first node).
But my second node don’t say anything about it:
This is the window where the identities are counted in to adjust the PoW difficulty. Your identity didn’t wrote a block since then (a set/number of blocks (166 right now)) and is no longer counted as a blacksmith right now.
You can get it with `silkaj diffi`:
Current block: n°481395, generated on December 8, 2021 1:38 PM
Generation of next block n°481396 possible by at least 22/33 members
Common Proof-of-Work difficulty level: 107, hash starting with `000000[0-4]*`
| uid | match | Î diffi | ÎŁ diffi |
|------------------+----------------------+--------------+-----------|
| kosnik | 00000000000000000000 | 3.0 Ă— 10^177 | 2355 |
| Jnoel | 00000000000000000000 | 8.0 Ă— 10^88 | 1178 |
| Robisar | 00000000000000000000 | 3.4 Ă— 10^56 | 750 |
| Tchois | 00000000000000000000 | 4.4 Ă— 10^40 | 536 |
| fdrubigny | 00000000000000000000 | 2.6 Ă— 10^32 | 429 |
| vincentux | 00000000000000000000 | 2.4 Ă— 10^24 | 322 |
| ofontes | 00000000000000000000 | 1.2 Ă— 10^24 | 321 |
| DamageCo | 0000000000000[0-7]* | 3.6 Ă— 10^16 | 216 |
| vit | 0000000000000[0-8]* | 3.2 Ă— 10^16 | 215 |
| cgeek | 0000000000000[0-8]* | 3.2 Ă— 10^16 | 215 |
| poka | 0000000000000[0-9]* | 2.7 Ă— 10^16 | 214 |
| TomAs | 0000000* | 2.7 Ă— 10^8 | 112 |
| ji_emme | 0000000* | 2.7 Ă— 10^8 | 112 |
| elois | 0000000* | 2.7 Ă— 10^8 | 112 |
| tierce | 000000[0-1]* | 2.3 Ă— 10^8 | 110 |
| Boussaakat-hich | 000000[0-2]* | 2.2 Ă— 10^8 | 109 |
| Ando | 000000[0-2]* | 2.2 Ă— 10^8 | 109 |
| chronophonix | 000000[0-2]* | 2.2 Ă— 10^8 | 109 |
| moul | 000000[0-3]* | 2.0 Ă— 10^8 | 108 |
| pielonet | 000000[0-3]* | 2.0 Ă— 10^8 | 108 |
| Al1Nicolas | 000000[0-3]* | 2.0 Ă— 10^8 | 108 |
| ThierryLacaze | 000000[0-3]* | 2.0 Ă— 10^8 | 108 |
| Felipe | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
| Attilax | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
| pafzedog | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
| Mententon | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
| b_presles | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
| jytou | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
| CClement | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
| Eric | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
| Spartacus | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
| Tonychevalier974 | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
| Damery | 000000[0-4]* | 1.8 Ă— 10^8 | 107 |
Your node are simply out of sync, you can check the block number on /blockchain/current.
Yes, it seems configured. May be the out of sync is related to the fact that you added a second node.
And, how can i resync them?
Ps: I think it was better work with 2 nodes to balance the work, but I was maybe wrong, wasn’t I?
2021-12-08T13:44:20+01:00 - e[32minfoe[39m: Block resolution: 2 potential blocks after current#480968...
2021-12-08T13:44:20+01:00 - e[31merrore[39m: Error: ruleNumber
at Function.checkBlock (/opt/duniter/app/lib/blockchain/DuniterBlockchain.js:63:19)
at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-08T13:44:20+01:00 - e[31merrore[39m: Error: ruleNumber
at Function.checkBlock (/opt/duniter/app/lib/blockchain/DuniterBlockchain.js:63:19)
at process._tickCallback (internal/process/next_tick.js:68:7)
2021-12-08T13:44:20+01:00 - e[32minfoe[39m: Fork resolution: 86 potential block(s) found...
2021-12-08T13:44:20+01:00 - e[32minfoe[39m: Fork resolution: block #480981-00000013 is known as incorrect. Skipping.
2021-12-08T13:44:20+01:00 - e[32minfoe[39m: Fork resolution: block #480980-00000020 is known as incorrect. Skipping.
2021-12-08T13:44:20+01:00 - e[32minfoe[39m: Fork resolution: block #480979-00000015 is known as incorrect. Skipping.
Your node is stuck to solve the fork. I suggest you run a sync from scratch.
duniter sync g1.duniter.org # or any other endpoint/node
This is not really balancing, but having more power to find a block when there is no difficulty handicap.
Is it an usual situation? How is it possible my two servers are stuck, and not just one of them?
Well, then I think it’s not very interesting having 2 servers running Duniter, loading resources to do it, for just more power in some limited scenarios, is it?
Yes, the fork resolution can get stuck sometime. That happen the two nodes get stuck. Btw, they are not stuck on the same block. That’s probably not the same issue. It’s probably related to the fact that they got network issue since having multiple nodes sharing the same identity could cause network issues into s2s (server-to-server) connection.
Right, from a computation point of view, that’s up to your objectives. You can specialize the node to some actions. One would compute blocks, but would not allow the clients to request its client API. The other node would not compute blocks, but would serve a client API. That’s up to you once you know what are the possibilities and your objectives 
I’ve tried several times, but I’m always having this error, near 78-80%
Progress:
Milestones: [||||||||||||||||||||] 100 %
Download: [|||||||||||||||| ] 80 %
Apply: [||||||||||||||| ] 78 %
Sandbox: [ ] 0 %
Peers: [ ] 0 %
Status: Peers.../usr/bin/duniter: line 15: 3616 Killed $NODE "$DUNITER_DIR/bin/duniter" "$@"
Any ideas?
This is an OOM (out of memory) kill. Your system probably doesn’t have enough RAM/swap to have a full synchronisation running till the end. The kernel is killing processes which takes too much memory. You can check with htop the memory usage when you reach this application percentage (from 75%).
The more the currency growth, the more the initial synchronization requires RAM. There is no effort rigt now on Duniter v1 side to reduce its RAM usage during the initial sync. One option could be that you stop some services which eats memory on your machine during duniter sync command. The other option is having more RAM/(swap).
That’s it! The other option would be using the sync method suggested in other thread, downloading a file and synchronizing with him…
At last, my server can do the job, after 4 attempts. Now I think it’s working again…
Ps: I’ve disabled duniter in my second server, to avoid this issue.