...and there's me wondering why my 2-core 4GB server has no down time and fully upgraded without problems.
Dash Core v18.0.1 Released
- Thread starter Pasta
- Start date
John Smithson 2
New member
VULTR does not permit to downgrade. So if we upgrade from 4GB to 8 GB there is no going back, and the cost remains high.
4GBs is enough, dashd doesn't require a super computer. $18/mo cloud compute instance on vultr is ample for a masternode.
vazaki3
Well-known member
The agents lost the masternodes battle (the masternodes that updated to 18.1 are now more than 80%) so they are trying to attack through the miners.
I hope their attack will not succeed.
Last edited:
You are correct! We locked in with a staggering 95% of miners signalling for the hard fork! I think that might be a record.
We now wait for 4032 blocks, about 7.35 days for the hard fork to activate on block 1737792, which is about 13th of September depending on your TZ.
And we have 88.5% of the Masternode upgraded, the rest will either upgrade in time or simply be forked off the block following the fork.
vazaki3
Well-known member
And how do you explain the drop in the percentage of the miners?
Is there any other reasonable explanation, apart from the "agents conspiracy theory"?
Is it just a coincidence that the percentage of the miners started falling below 80%, when the masternodes reached 80%?
Last edited:
The charts Qwizzie posts are inferior, that is why I always delete them, I only trust mnowatch as the source, there was no drop in miner signalling, it was a strong finish, perfect actually. I am surprised we locked in so soon, I was expecting it to take at least another month.
vazaki3
Well-known member
In what chart of mnowatch.org can we see that there was no drop in miner signalling?
It isn't published, last time I tried to install the Phez' fork explorer, but faced some issue, this time I did not bother, instead I had two simple scripts running on loop to monitor it.
Code:
unset oldblockcount;while : ;do blockcount=$(dash-cli getblockcount)&&fork=$(dash-cli getblockchaininfo)&& count=$(jq -r '.bip9_softforks.dip0024.statistics.count' <<<"$fork");if((blockcount!=oldblockcount));then echo -e "Block: $blockcount\tcount: $count";oldblockcount=$blockcount;fi;sleep 1;doneand
Next time we can look at adding fork explorer to the site.
vazaki3
Well-known member
Yes...with v18 the proposal fee fell to 1 dash, so more governance proposals will be posed, and thus more forks will occur.
Lets add a fork explorer in mnowatch.org
Figlmüller
Member
Looks like the latest update to dashd (v18) reintroduced the locale issues, causing the process to terminate with:
unless the locale is automatically set through an env variable on our machines (
Code:
std::terminate() called due to unhandled exception
Exception: type=std::runtime_error, what="locale::facet::_S_create_c_locale name not valid"unless the locale is automatically set through an env variable on our machines (
LC_ALL="C" && export LC_ALL)
Can you elaborate on this? Is this to start the QT wallet, or a headless node? What is your current locale?
The actual data is in the blockchain so it can be reviewed directly there. But this is my snapshot from every 15 minutes showing the number of blocks signaling in the window ("Count" column): https://keybase.pub/thephez/dash-18.0.1/dash-18-miner-update-progress.csv. You can see it charted here: https://docs.google.com/spreadsheet...03vCw2r9h5KyXR7FTyyIgmoVRg/edit#gid=452706455.
I don't see any substantial change in signaling near lock-in. In fact, all the miners could have stopped signaling the last day and it still would have locked-in because the threshold had already been achieved. The Dash_info chart can be a little misleading because it doesn't factor in the signaling windows.
Figlmüller
Member
Sorry, I was talking about dashd and dash-cli being used headless as masternodes on Linux.
All images use
en_US.UTF-8 as their locale and I have to override it to C by setting the LC_ALL env var.Using Debian LTS (currently 10).
Related issue in bitcoin
After about when dash/darkcoin stopped linking its deps dynamically, the issue was gone. Now it has returned.
Last edited:
bogdan_bdg
New member
After updating MN to 18.0.1 it got PoSe Banned. Checking the logs showed "possible database corruption". So I wiped it out and began resyncing. After two days it still wasn't resynced so I started checking deeper. What I found eventually out is that the CPU usage is not really an issue but.... apparently 4GiB of physical plus 8GiB of swap is not enough for it to complete the full sync. `dashd` keeps gradually allocating all available memory until it gets killed. This could also explain the "possible database corruption" in the first place I guess. A memory leak somewhere in the new version?
Figlmüller
Member
I also noticed that. On the first launch when building the block index, dashd would show around 5GB resident size, allocating around 10GB in total. Restarting dashd after the initial rebuild would let it return to normal levels and stop my monitoring from sending me SMS every 15 minutes x).
Also keep in mind, that Sentinel must be updated and now requires python3. You might need to rebuild your python venv!
Also note that configuring sentinel by referencing and parsing your dashd.conf is now deprecated and you're encouraged to set up environment variables instead.
Yep, you guessed it! A new version is coming soon, v18.0.2 which will address that issue. If you need to get around the issue for now, then just restart the dashd several times during syncing to reclaim that RAM before it crashes.