Err... looks like it's off by 1
It's just a cosmetic rpc output bug though, "mnbudget projection" shows correct list for next budget to be payed.Tnx for noticing, we'll fix it! :smile:
V12 Release
- Thread starter eduffield
- Start date
It's just a cosmetic rpc output bug though, "mnbudget projection" shows correct list for next budget to be payed.Tnx for noticing, we'll fix it! :smile:
Since some people are saying v.53 is crashing sometimes, i made the 'mn_watch.sh' masternode restarting-script already here on this topic a bit more versatile. Instead of just restarting dashd it now spits out the time it crashed as well as the last 30 lines of debug.log to a file before restarting dashd.
Its kind of redoing whats already been done, but now it nice 'n compact without sifting trough the 10mb debug.log
1. The script is in my homedir where i keep all the stuff so its written as such. You may need to alter some paths if you keep your stuff elsewhere.
2. The script appends to the file crash.log, if not exist it is created.
3. the command 'date' spits out UTC time. Its possible to alter this to your own timezone. Do a google on it.
Im a noobish linux user so the script may appear wonky, but hey, it works, right?
Dont ask hard questions cuz i may not be able to answer them
#!/bin/bash
if [ -z `pidof dashd` ]; then
echo "Crashed!" >> crash.log
date >> crash.log
echo -e "\n" >> crash.log
tail -n 30 ./.dash/debug.log >> crash.log
echo -e "\n" >> crash.log
echo "********************************************" >> crash.log
echo -e "\n" >> crash.log
echo -e "\n" >> crash.log
./dashd
fi
Its kind of redoing whats already been done, but now it nice 'n compact without sifting trough the 10mb debug.log
1. The script is in my homedir where i keep all the stuff so its written as such. You may need to alter some paths if you keep your stuff elsewhere.
2. The script appends to the file crash.log, if not exist it is created.
3. the command 'date' spits out UTC time. Its possible to alter this to your own timezone. Do a google on it.
Im a noobish linux user so the script may appear wonky, but hey, it works, right?
Dont ask hard questions cuz i may not be able to answer them
#!/bin/bash
if [ -z `pidof dashd` ]; then
echo "Crashed!" >> crash.log
date >> crash.log
echo -e "\n" >> crash.log
tail -n 30 ./.dash/debug.log >> crash.log
echo -e "\n" >> crash.log
echo "********************************************" >> crash.log
echo -e "\n" >> crash.log
echo -e "\n" >> crash.log
./dashd
fi
Yah, and they're using coinmine.pl, which exacerbates the issues. Jerks.
Thank you for this. Apparently my nodes are being restarted on average once a day. I had no idea. I wonder why they're
Edit: Actually, my nodes are shutting down and restarting constantly from what I get from the log? Unless I'm not reading this correctly?
Well, this looks weird? Why is my masternode cleanly shutting down constantly, then restarting?
Last edited by a moderator:
Solarminer
Well-known member
Either your node didn't shutdown and still has control of the .dash directory, or you are trying to run 2 nodes from the same data directory. I have a .dash, .dash2, for each node and start with a script. Script has /home/user/dashd2 -datadir=/home/user/.dash2/ . If you shutdown your node and TOP shows it still running, kill -9 the process, and start dashd again.
Solarminer
Well-known member
Thanks. This is a good idea. I would suggest that this also be added in the next release. Basically, if there is a shutdown it adds the last 30 lines of debug info in a crash.log. On startup, the debug.log could be cleared too.Since some people are saying v.53 is crashing sometimes, i made the 'mn_watch.sh' masternode restarting-script already here on this topic a bit more versatile. Instead of just restarting dashd it now spits out the time it crashed as well as the last 30 lines of debug.log to a file before restarting dashd.
Its kind of redoing whats already been done, but now it nice 'n compact without sifting trough the 10mb debug.log
1. The script is in my homedir where i keep all the stuff so its written as such. You may need to alter some paths if you keep your stuff elsewhere.
2. The script appends to the file crash.log, if not exist it is created.
3. the command 'date' spits out UTC time. Its possible to alter this to your own timezone. Do a google on it.
Im a noobish linux user so the script may appear wonky, but hey, it works, right?
Dont ask hard questions cuz i may not be able to answer them
#!/bin/bash
if [ -z `pidof dashd` ]; then
echo "Crashed!" >> crash.log
date >> crash.log
echo -e "\n" >> crash.log
tail -n 30 ./.dash/debug.log >> crash.log
echo -e "\n" >> crash.log
echo "********************************************" >> crash.log
echo -e "\n" >> crash.log
echo -e "\n" >> crash.log
./dashd
fi
I am thinking of a way to check if the daemon gets stuck on a block. Then force a kill -9 then restart dashd. Stay tuned. Gotta unpack from our latest solar install first.
camosoul
Well-known member
That's output from the second cron-initialized instance as it realizes it shouldn't be running, overlapping with the original by writing to the same debug.log for a few seconds.
No need to panic, it's not actually shutting down.
If you open multiple ssh sessions, or use screen, you can see the second daemon shows up in top while tail -f monitoring the log file in another window.
"top -d 1 -u [username you use for running dashd]"
You'll notice those timestamps coincide with the second daemon every time cron tries to start it.
Since there is an InstantX Proof of Service penalty now, I run dashd in cron every 5 minutes. So, there's a lot of those in my debug.log... It'd be a shame not to facilitate an IX TX regardless of penalty.
Yeah, it's lazy, but it works...
Last edited by a moderator:
camosoul
Well-known member
Yeah, I just didn't care until now... Still don't. I'm still grumpy over having to manually re-do every single damn one of them because of locking themselves out... Took me 2 and a half days since nothing automated would work due to the arbitrary timing...
Solarminer
Well-known member
Your tutorial is good. Thanks for getting this topic started. More to come.Exactly! I started with the conversation on bitcointalk, and discovered that my daemons wouldn't start independently, if one should crash or stop, but the other continued. (I have one server, two users, 2 ip addresses, running 2 masternodes) So GR+ showed me how to test for the user's process id for dash (which I think is only possible because our developers made it pop up as a file in the .dash folder? It is checked with a cron job and if not running, it starts the daemon back up.
There is another way to check to see if the daemon stopped cleanly vs dirty, so that if you stopped the daemon (rather than it crashing) it would stay stopped until you started it again. This would be useful for updating, but I wasn't able to get it to work. I don't think it's worth the trouble either as I only usually need a second to restart the daemon after updating the files. I don't even stop it before updating. As long as we still have dashd and dash-cli, the older running version of dashd can shut down fine (it doesn't over write the new version on shutdown) and restarting updates the version. Plus, I check every 10 minutes, which is done by the clock, so if I start after a check (ie: X:00, X:10, X:20...etc...) I have plenty of time, even if I had to stop the daemon to update.
Anyway, I wrote a tutorial on it here: https://dashtalk.org/threads/keep-your-mn-up-and-running-after-crash-ubuntu-w-explainations.6063/
If it sucks too much, anyone is welcome to rewrite it and even better, give other ways and other choices on how to do it
Thanks guys. Good news is it's normal, bad is that there is no insight for why the daemon shuts down (for me, once a day, about) Ah well. No harm for me, as It continues to stay online, but if what camo says is so, and we're not in fact functioning correctly, or worse, could drop stuff while mixing or IXing, well that'd be bad
.
.
Probably bad news for everyone running their nodes with "masternode start" (i.e. using local dash.conf): I guess there's a bug with masternode self-activation somewhere.
If you are using local dash.conf to start your remote masternode do NOT run this local wallet while masternode=1 is still in local dash.conf, I think it will try to self-activate for some reason and will drop your node to the end of the queue. Either set it to masternode=0 before you run it OR better option would be to use masternode.conf even if you only have one masternode.
Sorry about that :sad:
PS. Code there became a bit messy actually because of many different options. I think we should stop using this one, clean it up and stick to masternode.conf method only to activate remote nodes while old dash.conf method should only be used for activating local Hot masternodes from now.
PPS. Users with masternode.conf setup should not be affected by this.
If you are using local dash.conf to start your remote masternode do NOT run this local wallet while masternode=1 is still in local dash.conf, I think it will try to self-activate for some reason and will drop your node to the end of the queue. Either set it to masternode=0 before you run it OR better option would be to use masternode.conf even if you only have one masternode.
Sorry about that :sad:
PS. Code there became a bit messy actually because of many different options. I think we should stop using this one, clean it up and stick to masternode.conf method only to activate remote nodes while old dash.conf method should only be used for activating local Hot masternodes from now.
PPS. Users with masternode.conf setup should not be affected by this.
moli
Well-known member
I was waiting for you to say this. Finally. Thanks.
TaoOfSatoshi
Well-known member
So, you are saying that my setup guide is soon to be obsolete? I want it to remain current, so the user:
- does not need a local dash.conf at all for a hot/cold setup?
- should only have a masternode.conf, and issue a masternode start-alias mn01?
Let me know and I'll update ASAP.
I think he's saying only if you're using a hot node, that is,no remote, you do use the dash.conf with masternode=1. I also think we may still need dash.conf to hold only the rpcuser and rpcpassword and maybe some of the other configurations you might have, but NOT the masternode=1 That must go unless you're using a hot mastenode with no remote. Instead, use masternode.conf. I have my son's set up with dash.conf, so I'll have to make sure I dont' accidentally start it with dash.conf having masternode=1 inside before I next open it. How much you wanna bet I'm gonna screw that up when the time comes? LOL
For Hot/Cold setups, I don't think it matters if your hot node has masternode=1 in the conf. You're pretty much never going to be issuing a "masternode start" from there anyway, the way it is set up now.
I think you'll be fine if you leave hot nodes as is, and only issue a masternode start-alias/many/disabled/missing from the cold wallet's masternode.conf
I mean this kind of setup can be used but user has to change masternode=1 to masternode=0 once it's done and change it back to masternode=1 when he'd like to update/restart his node. Since that's not that user friendly I would highly recommend to switch to masternode.conf setup as a default one. I'm going to change docs in repo on github to reflect this situation soon. You can start single node with any start-<mode> command (<mode> = all, missing, disabled , start-many works too though it's now depreciated and kept for backward compatibility reasons only).
RemainingPaymentCount will be fixed in next version https://github.com/dashpay/dash/pull/602 (it's a cosmetic bug), check "mnbudget projection" to verify that "reimbursement" proposal is no longer there.
"Alloted" is for current proposal and "TotalBudgetAlloted" is for all proposals in total starting from the first one in the list and up to the current one (including it).
It's not very clear to display it that way however.
So imagine we fixed both issues :grin: and that how it should look then imo:
Code:
{
"core-team" : {
"URL" : "goo.gl/V52wZd",
"Hash" : "eac6392cd0d63e4b2ebd3c60da2d3e13137c892cd4cd1a8f3885077ac86b7487",
"BlockStart" : 332320,
"BlockEnd" : 2002228,
"TotalPaymentCount" : 100,
"RemainingPaymentCount" : 99,
"PaymentAddress" : "XtspXMnoGt4RF23CZ7MQQ7NFmkAebMUNME",
"Ratio" : 0.99422336,
"Yeas" : 1531,
"Nays" : 9,
"Abstains" : 0,
"TotalPayment" : 117600.00000000,
"MonthlyPayment" : 1176.00000000,
"Alloted" : 1176.00000000,
"IsValid" : true,
"IsValidReason" : "",
"fValid" : true
},
"public-awareness" : {
"URL" : "goo.gl/V52wZd",
"Hash" : "cbafad18687045bb72fae611078fac09c3ec09c8379e357c36901ce84891f189",
"BlockStart" : 332320,
"BlockEnd" : 2002228,
"TotalPaymentCount" : 100,
"RemainingPaymentCount" : 99,
"PaymentAddress" : "XxTqjYd4bpkTA6yP1gmo5maMkPynT6YvbG",
"Ratio" : 0.97036082,
"Yeas" : 1488,
"Nays" : 46,
"Abstains" : 0,
"TotalPayment" : 215600.00000000,
"MonthlyPayment" : 2156.00000000,
"Alloted" : 2156.00000000,
"IsValid" : true,
"IsValidReason" : "",
"fValid" : true
},
"TotalBudgetAlloted" : 3332.00000000
}
qwizzie
Well-known member
Mangled Blue raised a good question on the bitcointalkforum : why do the blocks still get 50 / 50 % paid out instead of 45 / 45 / 10 ?
https://bitcointalk.org/index.php?topic=421615.msg12374678#msg12374678
https://bitcointalk.org/index.php?topic=421615.msg12374678#msg12374678