Yep, it's default. It's just me - I like things to be explicitly defined in configIf i remember it right, txindex=1 is default in the v12.
Maybe UdjinM6 can comment on this, is the txindex=1 mandatory in dash.conf, i thought it was only in v11?
Yep, it's default. It's just me - I like things to be explicitly defined in configIf i remember it right, txindex=1 is default in the v12.
Maybe UdjinM6 can comment on this, is the txindex=1 mandatory in dash.conf, i thought it was only in v11?
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![]()
Yes, but MNs shutdown long after that spikes.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
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.What's in debug.log? Any errors?
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.
https://dashtalk.org/threads/please-update-to-v12-0-45.5912/#post-63791I 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
txindex : maintains an extra index of old, spent transaction ids so they will be found by the getrawtransaction JSON-RPC method.Explain this one please: txindex=1
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...
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.4 of 5 masternodes went off again all at about same time
im also with vultr
what can cause that ?
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
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...
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...
2015-08-18 21:18:54 Verifying mncache.dat format...
This is better:does nobody use crontab -e
@reboot dashd
no good on a running dashdThis is better:
@reboot /root/dashd -shrinkdebugfile
*/20 * * * * /root/dashd -shrinkdebugfile
Already running is what you want. No harm, no foul?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.Already running is what you want. No harm, no foul?
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.I believe it is because the CPU usage is over xx% for a x minutes and the server operator kills the instance.
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 :
, just saw a .46 on dashninja
That will not re-start dash if it dies. That will only start dash if the OS is rebooted.does nobody use crontab -e
@reboot dashd