jakiman
Legendary
Offline
Activity: 1638
Merit: 1011
jakiman is back!
|
|
August 23, 2016, 08:50:47 AM |
|
Fixed and no crashes/corrupts so far then?
Yes. My masternodes (linux) are all up now and haven't had any crashes yet which I was having very frequently past 1.5 days or so. As for my controller wallet (windows), it is synced up and is receiving some MN payments although it's not frequent yet as expected. But yeah, my Windows wallet feels very fragile atm. (had chain corruption multiple times today whenever it hung during MN startup) Another day or so is needed till I can really say that this setup is now working as expected.
|
|
|
|
borris123
|
|
August 23, 2016, 09:12:01 AM |
|
Fixed and no crashes/corrupts so far then?
Yes. My masternodes (linux) are all up now and haven't had any crashes yet which I was having very frequently past 1.5 days or so. As for my controller wallet (windows), it is synced up and is receiving some MN payments although it's not frequent yet as expected. But yeah, my Windows wallet feels very fragile atm. (had chain corruption multiple times today whenever it hung during MN startup) Another day or so is needed till I can really say that this setup is now working as expected. Will get mine updated in min then. let us know of there a change
|
|
|
|
mxnsch
|
|
August 23, 2016, 09:56:24 AM |
|
Fun fact: Didnt upgrade yet, but no crashes anymore on either side
|
██ ███ nope ██ ███
|
|
|
mikegi
|
|
August 23, 2016, 10:06:47 AM |
|
Fun fact: Didnt upgrade yet, but no crashes anymore on either side Me neither. Don't plan to unless necessary.
|
|
|
|
BitcoinFX
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
|
August 23, 2016, 10:52:56 AM |
|
'Upgrading' to v2.1.2.1 from v2.1.2.0 will most likely cause; error: {"code":-1,"message":"ReserveKeyFromKeyPool() : read failed"} error: {"code":-1,"message":"CWallet::GenerateNewKey() : AddKey failed"} error: {"code":-1,"message":"CDB : Error -30974, can't open database "} Error: Error: A fatal internal error occured, see debug.log for details 1. Have varying developers compiled / uploaded the binary releases with different / 'incompatible' database versions ? 2. Time to take a look over the code for other issues. More haste, less speed. If these issues are not fully resolved (explained) over the next weeks, it is highly likely that folks will simply switch off Masternode hosting due to server costs etc.,
|
|
|
|
jakiman
Legendary
Offline
Activity: 1638
Merit: 1011
jakiman is back!
|
|
August 23, 2016, 11:16:24 AM |
|
Checking my controller wallet's debug log, this error is streaming. Any idea what this is? Is it a problem? (I edited the Tx/hash/address incase they were private) 2016-08-23 11:10:16 Masternode payment enforcement is disabled, accepting block 2016-08-23 11:10:16 ProcessNewBlock : ACCEPTED 2016-08-23 11:10:16 CMasternodePayments::IsTransactionValid - Missing required payment - DTjWr8TggGm6ypCc1HrFLNYJNtNJ 2016-08-23 11:10:16 Invalid mn payment detected CTransaction(hash=d008f86, ver=1, vin.size=1, vout.size=3, nLockTime=0) CTxIn(COutPoint(b7c884a2c2aec6a3d2c56bcd9aee06ea15dd96145c392516813d409e7, 1), scriptSig=30450220085f09cb0027) CTxOut(nValue=0.00000000, scriptPubKey=) CTxOut(nValue=2980.94996357, scriptPubKey=02292b1ca3c7cc5ac9ee7d3470) CTxOut(nValue=33.75000781, scriptPubKey=OP_DUP OP_HASH160 a813a6368d)Also, it just crashed out of the blue with this in the db.log: file wallet.dat has LSN 38/1014714, past end of log at 1/476 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment file wallet.dat has LSN 38/1014714, past end of log at 1/476 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment DB_ENV->log_flush: LSN of 38/1014714 past current end-of-log of 1/476 Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment PANIC: DB_RUNRECOVERY: Fatal error, run database recovery wallet.dat: unable to flush page: 84 PANIC: fatal region error detected; run recovery
|
|
|
|
mxnsch
|
|
August 23, 2016, 11:24:11 AM |
|
Checking my controller wallet's debug log, this error is streaming. Any idea what this is? Is it a problem? (I edited the Tx/hash/address incase they were private) 2016-08-23 11:10:16 Masternode payment enforcement is disabled, accepting block 2016-08-23 11:10:16 ProcessNewBlock : ACCEPTED 2016-08-23 11:10:16 CMasternodePayments::IsTransactionValid - Missing required payment - DTjWr8TggGm6ypCc1HrFLNYJNtNJ 2016-08-23 11:10:16 Invalid mn payment detected CTransaction(hash=d008f86, ver=1, vin.size=1, vout.size=3, nLockTime=0) CTxIn(COutPoint(b7c884a2c2aec6a3d2c56bcd9aee06ea15dd96145c392516813d409e7, 1), scriptSig=30450220085f09cb0027) CTxOut(nValue=0.00000000, scriptPubKey=) CTxOut(nValue=2980.94996357, scriptPubKey=02292b1ca3c7cc5ac9ee7d3470) CTxOut(nValue=33.75000781, scriptPubKey=OP_DUP OP_HASH160 a813a6368d)Also, it just crashed out of the blue with this in the db.log: file wallet.dat has LSN 38/1014714, past end of log at 1/476 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment file wallet.dat has LSN 38/1014714, past end of log at 1/476 Commonly caused by moving a database from one database environment to another without clearing the database LSNs, or by removing all of the log files from a database environment DB_ENV->log_flush: LSN of 38/1014714 past current end-of-log of 1/476 Database environment corrupt; the wrong log files may have been removed or incompatible database files imported from another environment PANIC: DB_RUNRECOVERY: Fatal error, run database recovery wallet.dat: unable to flush page: 84 PANIC: fatal region error detected; run recoveryThe errors on the top are probably harmless, you just encountered a masternode without the proper collateral. Is DTjWr8TggGm6ypCc1HrFLNYJNtNJ you? The DB errors are most probably related to the issue BitcoinFX just pointed out and what i said in the past: We need properly tested, trusted binary releases.
|
██ ███ nope ██ ███
|
|
|
jakiman
Legendary
Offline
Activity: 1638
Merit: 1011
jakiman is back!
|
|
August 23, 2016, 11:38:02 AM |
|
Hmm. I see. Thanks. I'll go back to v2.1.2.0 for my main controller wallet and see how I go. But seems my linux masternodes are running fine with v2.1.2.1 so I'll leave them be for now.
|
|
|
|
BitcoinFX
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
|
August 23, 2016, 12:52:59 PM |
|
The network does not care which DB version an individual node runs. The wallet.dat does care about which pre-requisite version of the DB it is using and/or that it is or is not compatible with. - https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md... " Ubuntu and Debian have their own libdb-dev and libdb++-dev packages, but these will install BerkeleyDB 5.1 or later, which break binary wallet compatibility with the distributed executables which are based on BerkeleyDB 4.8. If you do not care about wallet compatibility, pass --with-incompatible-bdb to configure. " ... It will be easier to do bug tracking if everyone is "singing from the same song sheet", at least.
|
|
|
|
mxnsch
|
|
August 23, 2016, 01:07:35 PM |
|
The network does not care which DB version an individual node runs. The wallet.dat does care about which pre-requisite version of the DB it is using and/or that it is or is not compatible with. - https://github.com/bitcoin/bitcoin/blob/master/doc/build-unix.md... " Ubuntu and Debian have their own libdb-dev and libdb++-dev packages, but these will install BerkeleyDB 5.1 or later, which break binary wallet compatibility with the distributed executables which are based on BerkeleyDB 4.8. If you do not care about wallet compatibility, pass --with-incompatible-bdb to configure. " ... It will be easier to do bug tracking if everyone is "singing from the same song sheet", at least. Exactly, that's why we should get the travis builds working. Should be piece of cake since dash is using them, too.
|
██ ███ nope ██ ███
|
|
|
borris123
|
|
August 23, 2016, 01:07:49 PM |
|
'Upgrading' to v2.1.2.1 from v2.1.2.0 will most likely cause; error: {"code":-1,"message":"ReserveKeyFromKeyPool() : read failed"} error: {"code":-1,"message":"CWallet::GenerateNewKey() : AddKey failed"} error: {"code":-1,"message":"CDB : Error -30974, can't open database "} Error: Error: A fatal internal error occured, see debug.log for details 1. Have varying developers compiled / uploaded the binary releases with different / 'incompatible' database versions ? 2. Time to take a look over the code for other issues. More haste, less speed. If these issues are not fully resolved (explained) over the next weeks, it is highly likely that folks will simply switch off Masternode hosting due to server costs etc., it is annoying updating and then to find out it doesnt work. Worst thing is trying to activate the node and the controller freezing. when you have multiple nodes this is a real pain in the arse.
|
|
|
|
mxnsch
|
|
August 23, 2016, 01:18:44 PM |
|
it is annoying updating and then to find out it doesnt work.
Worst thing is trying to activate the node and the controller freezing. when you have multiple nodes this is a real pain in the arse.
no offense please, but you are repeating yourself here. It is annoying for all of us and we will resolve this by supporting the Devs in the best way we can, right? They have the knowledge and with a little more patience to actually slow down development and invest more time - to fix the expected regressions after the switch - we will get that issues sorted. Additionally, i think we should create a vote to prioritize these annoying things as we did in the past. DNET is much more than a DASH clone now, let's proceed and proof it!
|
██ ███ nope ██ ███
|
|
|
borris123
|
|
August 23, 2016, 01:28:18 PM |
|
it is annoying updating and then to find out it doesnt work.
Worst thing is trying to activate the node and the controller freezing. when you have multiple nodes this is a real pain in the arse.
no offense please, but you are repeating yourself here. It is annoying for all of us and we will resolve this by supporting the Devs in the best way we can, right? They have the knowledge and with a little more patience to actually slow down development and invest more time - to fix the expected regressions after the switch - we will get that issues sorted. Additionally, i think we should create a vote to prioritize these annoying things as we did in the past. DNET is much more than a DASH clone now, let's proceed and proof it! only agreeing about it. that be a good idea about the list of things and a vote. Can we create a test net as well. we shouldnt have to be updating all the time. Everyone on here I am sure will test on the testnet and not release anything until its solid.
|
|
|
|
q327K091
Legendary
Offline
Activity: 1792
Merit: 1010
|
|
August 23, 2016, 02:15:43 PM |
|
update: all 47 nodes were updated w/ latest git master, are operating well, staking steadily and towards 48th node
|
|
|
|
muchoman
|
|
August 23, 2016, 02:31:51 PM |
|
Sorry to say but I sold my dnet, coin is not working and too much hassle to keep up.
|
|
|
|
q327K091
Legendary
Offline
Activity: 1792
Merit: 1010
|
|
August 23, 2016, 02:37:41 PM |
|
Sorry to say but I sold my dnet, coin is not working and too much hassle to keep up.
a! that was you that made 50$ no problem at all. codebase is stabilizing with every release tip for the community, even iff all stable and even if it would be dash coin, it pays off to use supervisor (or similar task manager) with autorestart and cleanup prior (in a shall scrypt) , then you can walk away and collect one could also put git pull inside the restart scrypt (automatic pull of fresh codebase) rm blockchain and chainstate and then really go for vacation, I do this with every coin and let dev/community workout small defects how much time do I spend on dnet a week ? I say because of the above few hours a week at most great this below (there is some other similar for unix forgot its name popular amongst php folks.. and for windows there has to be something similar as well...) http://supervisord.org/
|
|
|
|
DRPD
Legendary
Offline
Activity: 1148
Merit: 1001
|
|
August 23, 2016, 02:50:50 PM |
|
just for info: so far non of my masternodes running with version 2.1.2.1 crashed some masternodes still running with 2.1.2.0 & just crashed again, so i guess the new version is a nice step ahead for masternodes
|
|
|
|
EcoChavCrypto
|
|
August 23, 2016, 02:54:29 PM |
|
just for info: so far non of my masternodes running with version 2.1.2.1 crashed some masternodes still running with 2.1.2.0 & just crashed again, so i guess the new version is a nice step ahead for masternodes What addnodes are you using? I have been syncing for the past 3 hours with none in the masternode darknet.conf files and it's still less than 50% done on the first node.
|
|
|
|
DRPD
Legendary
Offline
Activity: 1148
Merit: 1001
|
|
August 23, 2016, 02:58:41 PM |
|
just for info: so far non of my masternodes running with version 2.1.2.1 crashed some masternodes still running with 2.1.2.0 & just crashed again, so i guess the new version is a nice step ahead for masternodes What addnodes are you using? I have been syncing for the past 3 hours with none in the masternode darknet.conf files and it's still less than 50% done on the first node. only addnode=coin-server.com but yes syncing on masternodes is very slow ....
|
|
|
|
Tecem
Newbie
Offline
Activity: 18
Merit: 0
|
|
August 23, 2016, 04:10:04 PM |
|
Yesterday I was stuck at block 264538. Now with the new wallet I still can't get ast block 264538.
|
|
|
|
|