• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

V12 Release

TanteStefana said:
I just upgraded to version 45, and my 2nd wallet can see itself and my son's wallet, my son's wallet can see my 2nd wallet and himself, and my 1st wallet can see all 3. So question is, should I worry that my 2nd wallet and son's wallet can't see my 1st wallet? Or does it just take time? Thanks!
Click to expand...

Tante, are these Masternodes? I had to do a bit of start-stopping both on my local machine (masternode stop then masternode start), plus stopping and starting daemon on the masternode server itself to get mine looking perfect. Not even sure if masternode stop does anything but got it all working in the end. Got one Masternode left to do.
 
Last edited by a moderator:
Solarminer said:
In a production environment any features removed can cause big problems - even if they seem minor. Just pointing out that this is critical to put in release notes.

Not frustrated at all. This is an awesome release. Show it off!
Click to expand...
Yeah totally agreed any major changes that will break a production server or need to be handled differently that will break code should definitely be pointed out.
 
coingun said:
Yeah totally agreed any major changes that will break a production server or need to be handled differently that will break code should definitely be pointed out.
Click to expand...
It would've been nice if more people had helped out during the testing... but the next plan is I'll have the testers jot down on napkins what the changes are so when the next release is ready we'll have all of the changes on napkins for you guys..

:tongue::grin:
 
GermanRed+ said:
Elbereth, thanks for all the information. I also looked up some older posts on the forum. Evan mentioned that v0.12 has a hybrid state for the reference node. Your reply really helps clearing things up for people like me who do not read all the posts.
Click to expand...
So I guess we still have a centralization issue that only evan can turn on or off enforcement. We did have an issue once where we got stuck on a block and had no blocks for many hours until someone reached evan to turn off enforcement. I guess we should circle around and chat about how this could be improved as attacking the reference node could inhibit the ability to turn enforcement on or off. In the event someone found a major bug that required turning off enforcement and then they attacked the reference node so we couldn't turn it off that would be bad I think.
 
moli said:
It would've been nice if more people had helped out during the testing... but the next plan is I'll have the testers jot down on napkins what the changes are so when the next release is ready we'll have all of the changes on napkins for you guys..

:tongue::grin:
Click to expand...
The point is that we want to be respectful to the external people using our wallets. Exchanges, API systems, anything like that that requires specific expected results should be able to easily find what's changed so they can update their code. It takes a bunch of time for them to make those changes. The reason Bitfinex dropped our support was they said it took too much time to keep up with the changes and keep things working in their infrastructure for the amount they were making. So to be good stewards to our community we want to make it as easy as possible for them to keep up with releases and what's changed. This is just a normal best practice that all software distributors try and release. The people requesting more info aren't being lazy they have hours of work to change their code and get it working again and just don't wnat to spend it reading through pages and pages of forum posts.
 
Problem:
You have masternode in list but "dash-cli masternode debug" gives you "Could not find suitable coins!". Few hours later you node drops out of list.

Explanation:
This means that your node was not activated actually. On a successfully activated remote masternode "dash-cli masternode debug" should return "Masternode successfully started". One reason why your masternode wasn't activated could be that new activation message can't reach your masternode from your local wallet because somewhere on its route there are only v11 masternodes and they just ignore new messages.

Fix:
To fix this you need to connect to your node directly and there are few ways to do this:
1) simple one, temporary: open console in local wallet and type "addnode MNIP onetry" - this will force your client to open direct connection to your MN
2) if #1 didn't work for some reason or you want to force your wallet to connect to your MNs every time you run it: add "-connect=MNIP" in command line or add "connect=MNIP" in dash.conf. You can add it multiple times if you have many masternodes. Note: this way your client will connect only to specified IPs.
 
fible1 said:
Hey,
Yep, tried kill, and killall on console, no dice. The wallet is still there, blank. If I try to open a new one it tells me another is already running.

Pablo.
Click to expand...
A few of my nodes locked up when I tried to shutdown the old version. Type: top. Then when the DASH process is at the top hit k, (make sure it selects the dash process id) <enter>, and 9 <enter>. Worked for me. Easier way for me to remember.
 
I tried running dashd linux32 version(12.45) and it gave me an error. -bash - not a recognized file. The previous version worked on my nodes. I tried downloading a second time, after an "apt-get upgrade & update" and same problem. The linux64 worked no problem. I am running a 64bit Ubuntu so if that error is because of a 32bit application it should be your OS needs to be 32bit. Probably more likely that linux32 dashd didn't compile correctly.
 
Solarminer said:
I tried running dashd linux32 version(12.45) and it gave me an error. -bash - not a recognized file. The previous version worked on my nodes. I tried downloading a second time, after an "apt-get upgrade & update" and same problem. The linux64 worked no problem. I am running a 64bit Ubuntu so if that error is because of a 32bit application it should be your OS needs to be 32bit. Probably more likely that linux32 dashd didn't compile correctly.
Click to expand...

You need to have 32-bit libraries installed on your 64-bit system.
That's why it says the error you are seeing.
 
If anyone needs the command to check if multiple nodes are enabled you can use this and replace xx... with your IPs, pubkeys, or hashes. The "masternodelist full" is needed to display IPs now since the "masternode list" only displays the hash-index. Since the "masternode list" command has reduced functionality, this needs to be clearly addressed in the release notes.

./dash-cli masternodelist full | grep -E 'xx.xx.xx.xx|xxx.xxx.xx.xx|xxx.xxx.xx.xx'
or if you just want a count of how many are running:
./dash-cli masternodelist full | grep -E 'xx.xx.xx.xx|xxx.xxx.xx.xx|xxx.xxx.xx.xx' | grep -c ENABLED
 
Last edited by a moderator:
Is there some new way of activating the masternode with v12? uppdated one of my MNs , reindex and all looks fine, but when i run masternode start from coldwallet, it says "start sucessfully", but on the MN it only says ; "Not capable masternode: Wallet is locked." :eek:
 
qwizzie said:
just delete peers.dat & mncache.dat and do a -reindex with new version 0.12.0.45
thats pretty much it.

oh and most rpc commands have moved to dash-cli, so only use dashd to start and use dash-cli for the other rpc commands.
Oh hell, i can just as well show it in details :
Click to expand...

Wow, thanks Qwizzie! So glad you showed me the details :)
 
over 10 hours my MNs where ok, now the daemons died again :(

Edit:
this are the last lines in the debug.log before shutdown:

Code: 
2015-08-16 23:46:31 dumpaddr thread stop
2015-08-16 23:46:31 addcon thread interrupt
2015-08-16 23:46:31 opencon thread interrupt
2015-08-16 23:46:31 msghand thread interrupt
2015-08-16 23:46:31 net thread interrupt
2015-08-16 23:46:31 PrepareShutdown: In progress...
2015-08-16 23:46:31 StopNode()
2015-08-16 23:46:31 Verifying mncache.dat format...
2015-08-16 23:46:31 Loaded info from mncache.dat  233ms
2015-08-16 23:46:31   Masternodes: 2679, peers who asked us for Masternode list: 1, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 91, nDsqCount: 4300
2015-08-16 23:46:31 Writting info to mncache.dat...
2015-08-16 23:46:32 Written info to mncache.dat  179ms
2015-08-16 23:46:32   Masternodes: 2684, peers who asked us for Masternode list: 1, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 100, nDsqCount: 4326
2015-08-16 23:46:32 Masternode dump finished  416ms
2015-08-16 23:46:32 Shutdown: done

2nd node shut down nearly at the same time:

Code: 
2015-08-16 23:42:44 Shutdown: done
 
Last edited by a moderator:
UdjinM6 said:
Problem:
You have masternode in list but "dash-cli masternode debug" gives you "Could not find suitable coins!". Few hours later you node drops out of list.

Explanation:
This means that your node was not activated actually. On a successfully activated remote masternode "dash-cli masternode debug" should return "Masternode successfully started". One reason why your masternode wasn't activated could be that new activation message can't reach your masternode from your local wallet because somewhere on its route there are only v11 masternodes and they just ignore new messages.

Fix:
To fix this you need to connect to your node directly and there are few ways to do this:
1) simple one, temporary: open console in local wallet and type "addnode MNIP onetry" - this will force your client to open direct connection to your MN
2) if #1 didn't work for some reason or you want to force your wallet to connect to your MNs every time you run it: add "-connect=MNIP" in command line or add "connect=MNIP" in dash.conf. You can add it multiple times if you have many masternodes. Note: this way your client will connect only to specified IPs.
Click to expand...
That helped, but I had to do it 3 times before it started succesfully on hot MN and only on one of them it showed "Masternode successfully started" :confused:. The rest dropped out
I guess I have to do it few more times on the rest. Go figure
 
Maybe can I give an advice : yesterday I think I go too fast, made the masternode Start as they were already enabled with old version, and also face some details with some MN.

I stop the daemon and wait that they were unlisted everywhere (my other daemon and dashninja), about 2 or 3 hours..
And then perform the masternode start and since then they are online and running just fine.
 
It's a pain when you connect directly to your mn and you have only that peer connected. Blocks are synced but it takes long hours to sync masternodes, sporks from one peer (I need to connect more of them). I thought I don't need to wait for it to start a mn. I think I was synced with one which worked.
I'll check Lebubar's way later. Thanks
 
You must log in or register to reply here.
Back
Top