V12 Release

AjM

Well-known Member
Foundation Member
Jun 23, 2014
1,335
571
283
Finland
Yep, it's default. It's just me - I like things to be explicitly defined in config :)
Ok, my mn:s does not have this in any conf, and they work ok so far, except jumping cpu usage about 10-30%
 

qwizzie

Well-known Member
Aug 6, 2014
1,550
728
183
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
 

Lukas_Jackson

Member
Nov 9, 2014
160
70
88
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
Yes, but MNs shutdown long after that spikes.
 

qwizzie

Well-known Member
Aug 6, 2014
1,550
728
183
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
 

djcrypto

Member
May 27, 2014
180
94
88
What's in debug.log? Any errors?
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.
 

djcrypto

Member
May 27, 2014
180
94
88
UdjinM6 djcrypto

I have similar issues with my dashd, although I suspect it may be because my VPSs can't handle the demands of V12. I have 256 memory with 256 swap. I am upgrading to 512/512 and seeing if that helps. Crypto, what are your VPS specs?
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.
 

Lebubar

Active Member
Mar 15, 2014
250
214
103
@UdjinM6, just another crash of one MN.

This one is good, I saved the debug.log.
Just told me where I can send it to you.
 

moli

Grizzled Member
Aug 5, 2014
3,261
1,837
1,183
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
https://dashtalk.org/threads/please-update-to-v12-0-45.5912/#post-63791
 
  • Like
Reactions: qwizzie

moli

Grizzled Member
Aug 5, 2014
3,261
1,837
1,183

qwizzie

Well-known Member
Aug 6, 2014
1,550
728
183
4 of 5 masternodes went off again all at about same time
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
 
  • Like
Reactions: studioz

duffman

New Member
Jan 17, 2015
16
31
13
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. :D
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
 

aleix

Well-known Member
Foundation Member
Apr 4, 2014
144
135
193
Same problem here. After a while updated and ok, some of my masternodes are shown as a "inactive" in dashninja....
 

Lebubar

Active Member
Mar 15, 2014
250
214
103
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 :
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...
The other :
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 message really often about mncache.dat...
 
Last edited by a moderator:
  • Like
Reactions: UdjinM6

Solarminer

Well-known Member
Apr 4, 2015
762
921
163
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.
 
Last edited by a moderator:

moocowmoo

Bovine Bit-flipper
Foundation Member
Jun 15, 2014
483
603
263
masternode.me
Dash Address
XmoocowYfrPKUR6p6M5aJZdVntQe71irCX
This is better:

@reboot /root/dashd -shrinkdebugfile
*/20 * * * * /root/dashd -shrinkdebugfile
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.
 

oaxaca

Well-known Member
Foundation Member
Jul 8, 2014
573
832
263
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.
Already running is what you want. No harm, no foul?
 

Solarminer

Well-known Member
Apr 4, 2015
762
921
163
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)
 

Lebubar

Active Member
Mar 15, 2014
250
214
103
I believe it is because the CPU usage is over xx% for a x minutes and the server operator kills the instance.
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 :
o_O, just saw a .46 on dashninja
 

Solarminer

Well-known Member
Apr 4, 2015
762
921
163
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 :
o_O, 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.

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.
 

Funxy

New Member
Feb 19, 2015
13
14
3
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.