Yep, it's default. It's just me - I like things to be explicitly defined in config
V12 Release
- Thread starter eduffield
- Start date
Ok, my mn:s does not have this in any conf, and they work ok so far, except jumping cpu usage about 10-30%Yep, it's default. It's just me - I like things to be explicitly defined in config
the only thing i can think of thats different with two days ago is that a lot of masternodes all of a sudden got activated at once,
maybe that somehow caused huge spikes, overloading some masternodes ?
edit : also minersday post on top of this page looks interesting
maybe that somehow caused huge spikes, overloading some masternodes ?
edit : also minersday post on top of this page looks interesting
I hope when enforcement goes on again it will be on both version and protocol and only those masternodes will get paid with both correct version number and protocol number.
Because a lot of splits are showing up on dashninja.pl, almost like people are trying out things and it wouldnt be fair to have them get paid as they are not active in the DS mixing
process (they get rejected during DS)
correct version / correct protocol
0.12.0.45 / 70103
incorrect version / protocol
0.11.2.23 / 70076
0.11.2.22 / 70103
0.11.2.23 / 70103
0.12.0.44 / 70103
0.12.0.44 / 70076
0.12.0.45 / 70076
Because a lot of splits are showing up on dashninja.pl, almost like people are trying out things and it wouldnt be fair to have them get paid as they are not active in the DS mixing
process (they get rejected during DS)
correct version / correct protocol
0.12.0.45 / 70103
incorrect version / protocol
0.11.2.23 / 70076
0.11.2.22 / 70103
0.11.2.23 / 70103
0.12.0.44 / 70103
0.12.0.44 / 70076
0.12.0.45 / 70076
Somehow I got past this issue after reindexing. However, the MNs go offline after a few hours. I noticed the "Disk write" graph spiked just before the CPU usage dropped to 0, which I assume is when Dash crashed.
My VPS is 512MB /20GB SSD/1tb bandwidth. Crashed after a few hours. I noticed a Disk write spike on the graph just before the CPU usage went to 0.
txindex : maintains an extra index of old, spent transaction ids so they will be found by the getrawtransaction JSON-RPC method.
reindex : rebuild block and transaction indices from the downloaded block data.
you must run once with -txindex=1 -reindex=1 to rebuild block-chain indices
https://bitcoin.stackexchange.com/q...ction-detail-in-bitcoin-version-0-8-and-above
no, it means 1781 masternodes have updated to v12 and 655 are still on v11, together they form 2436 enabled masternodes. At least thats how i see it...
4 of 5 masternodes went off again all at about same time
im also with vultr
what can cause that ?
im also with vultr
what can cause that ?
i think my masternodes on VULTR previously also crashed very close after each other, currently they are active again for two hours now.. more or less.
I have no idea whats causing it, its at least not provider related as it happened both on VULTR and Digital Ocean
Hmmm... What do clouds smell like?
Mr. Chairman, thank you for the new release. It is quite a show you are having here. I did not expect less from you.
I may have stumbled upon a wonderful loop (or someone is performing a stress test on the network):
Mr. Chairman, thank you for the new release. It is quite a show you are having here. I did not expect less from you.
I may have stumbled upon a wonderful loop (or someone is performing a stress test on the network):
Code:
2015-08-18 21:10:44 mnp - Masternode ping, vin: CTxIn(COutPoint(35191e0591a2aa89b8d42469cd2f3ceb1741e3f3a4b69ebaf0bed3c10f95d0ce, 0), scriptSig=)
2015-08-18 21:10:44 CMasternodePing::CheckAndUpdate - New Ping - 7e1737c7eecd61a5556650c93d9f461b600d1f23d95f8db3516bf32cd911c716 - 0000000000128c19d0ede3b48ea5506878691ed93d93ef3fd1c127570051be07 - 1439932027
2015-08-18 21:10:44 CMasternodePing::CheckAndUpdate - Masternode ping accepted, vin: CTxIn(COutPoint(35191e0591a2aa89b8d42469cd2f3ceb1741e3f3a4b69ebaf0bed3c10f95d0ce, 0), scriptSig=)
2015-08-18 21:10:44 sending: inv (37 bytes) peer=17
2015-08-18 21:10:44 sending: inv (37 bytes) peer=22
2015-08-18 21:10:44 sending: inv (37 bytes) peer=26
2015-08-18 21:10:44 sending: inv (37 bytes) peer=37
2015-08-18 21:10:44 sending: inv (37 bytes) peer=38
2015-08-18 21:10:44 sending: inv (37 bytes) peer=89
2015-08-18 21:10:44 sending: inv (37 bytes) peer=94
2015-08-18 21:10:44 sending: inv (37 bytes) peer=2
2015-08-18 21:10:44 sending: inv (37 bytes) peer=14
2015-08-18 21:10:44 sending: ping (8 bytes) peer=2
2015-08-18 21:10:44 received: dseep (116 bytes) peer=26
2015-08-18 21:10:44 received: inv (37 bytes) peer=94
2015-08-18 21:10:44 got inv: mn ping 7e1737c7eecd61a5556650c93d9f461b600d1f23d95f8db3516bf32cd911c716 have peer=94
2015-08-18 21:10:44 received: pong (8 bytes) peer=2
2015-08-18 21:10:44 received: dseep (116 bytes) peer=22
2015-08-18 21:10:44 received: dseep (116 bytes) peer=22
2015-08-18 21:10:44 received: dseep (116 bytes) peer=22
2015-08-18 21:10:44 received: dseep (116 bytes) peer=38
2015-08-18 21:10:44 received: dseep (116 bytes) peer=38
2015-08-18 21:10:44 received: dseep (116 bytes) peer=2
2015-08-18 21:10:44 dseep - relaying CTxIn(COutPoint(d8faddfeb6bc965e2d5f33bfbe3e620a36204151497c4348f17cbb0ca360267a, 0), scriptSig=)
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=2
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=14
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=15
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=17
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=22
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=26
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=37
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=38
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=89
2015-08-18 21:10:44 sending: dseep (116 bytes) peer=94
2015-08-18 21:10:44 received: ping (8 bytes) peer=2
2015-08-18 21:10:44 sending: pong (8 bytes) peer=2
2015-08-18 21:10:44 sending: ping (8 bytes) peer=89
2015-08-18 21:10:44 received: notfound (37 bytes) peer=22
2015-08-18 21:10:44 received: dseep (116 bytes) peer=22
2015-08-18 21:10:44 received: inv (37 bytes) peer=89
2015-08-18 21:10:44 got inv: mn ping 7e1737c7eecd61a5556650c93d9f461b600d1f23d95f8db3516bf32cd911c716 have peer=89
2015-08-18 21:10:44 received: dseep (116 bytes) peer=15
2015-08-18 21:10:44 received: inv (37 bytes) peer=15
2015-08-18 21:10:44 got inv: mn ping 4675d6508dbae0ff0577ad68eb4290ef0c4dc004c257994f2e52f2f9109b0c00 new peer=15
2015-08-18 21:10:44 askfor mn ping 4675d6508dbae0ff0577ad68eb4290ef0c4dc004c257994f2e52f2f9109b0c00 0 (00:00:00) peer=15
2015-08-18 21:10:44 Requesting mn ping 4675d6508dbae0ff0577ad68eb4290ef0c4dc004c257994f2e52f2f9109b0c00 peer=15
2015-08-18 21:10:44 sending: getdata (37 bytes) peer=15
2015-08-18 21:10:44 received: mnp (147 bytes) peer=15
there is some activity going on in github : https://github.com/dashpay/dash/commits/v0.12.0.x
i wouldnt be surprised if we get another update soon.
i wouldnt be surprised if we get another update soon.
Well we all agree that we have stability problem
6 out of 15 offline tonight.
As say before some movements on github were detected, we all know that it will take max 48h for the dev team to correct those glitch. We are with you.
Edsit:
If debug.log are needed I got a lot.
Edit 2:
One say :
The other :
Last message really often about mncache.dat...
6 out of 15 offline tonight.
As say before some movements on github were detected, we all know that it will take max 48h for the dev team to correct those glitch. We are with you.
Edsit:
If debug.log are needed I got a lot.
Edit 2:
One say :
Code:
2015-08-18 20:30:19 Verifying mncache.dat format...
2015-08-18 20:30:20 Loaded info from mncache.dat 1126ms
2015-08-18 20:30:20 Masternodes: 2407, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 34, nDsqCount: 8189
2015-08-18 20:30:20 Writting info to mncache.dat...
Code:
2015-08-18 20:51:45 receive version message: /DashJ:0.12.2/Dash Wallet:4.18.11.1.22b/: version 70076, blocks=321577, us=127.0.0.1:9999, peer=2932
2015-08-18 20:51:47 Verifying mncache.dat format...
Code:
2015-08-18 21:18:54 Verifying mncache.dat format...
Last edited by a moderator:
This is better:
@reboot /root/dashd -shrinkdebugfile
*/20 * * * * /root/dashd -shrinkdebugfile
I don't think the masternode stopping issue is RAM. I am running 256MB virtual machines running Ubuntu 64bit on my own server without problems. Linux uses almost all the system ram even if it doesn't need it. My own server nodes have not stopped with the new release or last release. The other nodes running on a remote server tend to crash every 5-15 days or so with last release. I believe it is because the CPU usage is over xx% for a x minutes and the server operator kills the instance. I tried using crontab, but somehow the remove server didn't allow it to run. I ended up making a script to try to start nodes every 10 minutes. Since dashd won't start twice, you can just keep trying to start it and it will only start an instance if it isn't running. See my script below. Copy and past into a start.sh file and chmod +x start.sh. You can run with ./start.sh but you would need to keep a ssh window open. I installed screen(sudo apt-get install screen) and run with screen -dmS /start.sh.
Keep in mind this doesn't ever stop. You need to be quick updating your nodes(I was able to update without shutting down), or kill the process before you update. To stop screen -X -S 123123 quit. 123123 is the process id you can get from typing screen -ls.
/home/ is the full directory for your dashd
#To Start: screen -dmS /start.sh
#To Stop: screen -X -S 123123 quit (find 123123 from screen -ls)
while true; do
/home/dashd
sleep 600
done
Or even better, might be to add -shrinkdebugfile. If your daemon stopped because of a large debug file, this would fix it. Might be more difficult to diagnose a different problem.
Keep in mind this doesn't ever stop. You need to be quick updating your nodes(I was able to update without shutting down), or kill the process before you update. To stop screen -X -S 123123 quit. 123123 is the process id you can get from typing screen -ls.
/home/ is the full directory for your dashd
#To Start: screen -dmS /start.sh
#To Stop: screen -X -S 123123 quit (find 123123 from screen -ls)
while true; do
/home/dashd
sleep 600
done
Or even better, might be to add -shrinkdebugfile. If your daemon stopped because of a large debug file, this would fix it. Might be more difficult to diagnose a different problem.
Last edited by a moderator:
no good on a running dashd
$ dashd -shrinkdebugfile
Error: Cannot obtain a lock on data directory /home/ubuntu/.dash. Dash Core is probably already running.
I'm saying running it every 20 minutes does not shrink the logfile.
edit: Oh I see. To restart if down. I just use monit.
Notes for those with problems keeping nodes running. This helped me.
- Delete the debug.log (mine were over 100MB, and it seemed to crash nodes in less than an hour until I deleted them)
- Restart remote nodes once after they completed reindexing. ./dashd stop - wait and confirm process is stopped (30 seconds or so)
- Start nodes from local wallet one at a time. Seems that when I did a start-many, only a few remote nodes took the command. I used start-alias instead.
- Delete the remote node wallet if it won't stop or above doesn't work. (This worked for one of my nodes)
I don't think so because VULTR don't do this, I'm even mining of the VPS on VULTR and I'm using 100% of the cpu without problem.
And even on VULTR my daemon crash.
Edit :
, just saw a .46 on dashninja
Hmmm. Maybe it is just some instability with the remote server or dash .23/.45 client. Switched to a lower cost host about the same time as the previous release and had the problems. The start script worked for me so I haven't spent any more time figuring it out. I am pretty sure it isn't a ram problem since my home servers use less ram and don't stop.I don't think so because VULTR don't do this, I'm even mining of the VPS on VULTR and I'm using 100% of the cpu without problem.
And even on VULTR my daemon crash.
Edit :
On the old clients (pre .23) I was running a cpu miner too on Digital Ocean along with a node and didn't have problems. So DO wasn't stopping processes back then. Could be now though.
Maybe we have a fix with the .46 coming. 0.3% is what? 5 nodes. Must be some testing going on.
That will not re-start dash if it dies. That will only start dash if the OS is rebooted.
You probably want the entry above PLUS use something like monit (https://mmonit.com/monit/)
After months working away fine my 2 MN's on Vultr (upgraded to V12) died last night. Also having difficulties running the cli commands. Looks like it's not installed correctly "file not found" despite file existing in same directory as dashd. Any help appreciated.