BitShares Forum
Main => Stakeholder Proposals => Topic started by: Thom on July 29, 2015, 02:45:48 pm
-
I have never noticed this on any of the VPS systems, but for some unknown reason I can't explain the wallet goes from an unlocked state to a locked state and at the same time block production gets disabled. When this occurs all that is required to resume normal block production is to unlock the wallet.
When I unlock the wallet I set the time for it to remain unlocked to weeks, so that is not the issue.
I'm using different monitoring options in bts_tools than I was on the VPS, and I'm wondering if that might be the cause. It doesn't seem likely, but I'm puzzled by this behavior. It seems to happen every other day or so.
Wackou, I have set the "missed" blocks option in monitoring array, but when this occurs I get no notification, tho blocks are missed. Any ideas why?
-
That's not documented behavior .. the client should not auto lock the wallet if an active delegate is present .. that's odd
-
I have never noticed this on any of the VPS systems, but for some unknown reason I can't explain the wallet goes from an unlocked state to a locked state and at the same time block production gets disabled. When this occurs all that is required to resume normal block production is to unlock the wallet.
When I unlock the wallet I set the time for it to remain unlocked to weeks, so that is not the issue.
I'm using different monitoring options in bts_tools than I was on the VPS, and I'm wondering if that might be the cause. It doesn't seem likely, but I'm puzzled by this behavior. It seems to happen every other day or so.
Wackou, I have set the "missed" blocks option in monitoring array, but when this occurs I get no notification, tho blocks are missed. Any ideas why?
Are you attempting to run the delegate in the windows client?
-
Yes this is strange.. could there be anything funky with either your system clock or NTP clock ?
-
This happens on xbuntu 14.04. I've noticed if the clock is off much I can't sync; it's as tho I'm on a minority fork. I've also noticed the clock drifts. If was off .01 seconds, up from .0045 less than 14 hours earlier.
-
Do any of the "different monitoring options" unlock the wallet automatically? If so, maybe the script is locking it after it has run. Or if it unlocking it for a shorter time, not sure if this would overide a previous wallet unlock for a longer time.
-
I'm quite certain bts_tools never unlocks the wallet. I have spoken to wackou about this in the past who considered it risky to include the wallet password within the code, even if it's solicited by python and not echoed on the screen. We also talked about a crash recovery option that would restart the client and resume feeds / block production automatically, either of which requires the wallet to be unlocked. Unless I misunderstood him, and I doubt I did, he considered it too risky to even hold the wallet password in memory.
-
Wackou, I have set the "missed" blocks option in monitoring array, but when this occurs I get no notification, tho blocks are missed. Any ideas why?
Do you have your email properly configured in the "notification" section of your config.yaml file? Is there something in the logs that a notification cannot be sent or does everything seem normal? Also, your client need to be synchronized and on the main fork to be able to detect the missed blocks, if you end up on a minority fork then the detection cannot work.
I'm quite certain bts_tools never unlocks the wallet. I have spoken to wackou about this in the past who considered it risky to include the wallet password within the code, even if it's solicited by python and not echoed on the screen. We also talked about a crash recovery option that would restart the client and resume feeds / block production automatically, either of which requires the wallet to be unlocked. Unless I misunderstood him, and I doubt I did, he considered it too risky to even hold the wallet password in memory.
everything you said is correct. Password management is tricky to get right, and I don't want the responsibility of dealing with it and giving the users a false sense of security. If people want to automatically unlock their wallet, there are scripts floating around that do that, or it isn't too hard to write one oneself, but it should be up to the delegate to do so.
-
Do you have your email properly configured in the "notification" section of your config.yaml file? Is there something in the logs that a notification cannot be sent or does everything seem normal? Also, your client need to be synchronized and on the main fork to be able to detect the missed blocks, if you end up on a minority fork then the detection cannot work.
Yes, I get email notifications. I tested that with network connections limits by adjusting the minimum number to be high. The tools notify if you drop below that minimum.
There is far less than 1 second deviation of the system time, NTP sync is working and the avg delegate participation is > 95% . No indication when this "locking" is happening that the node is on a minority fork.
-
Is it at all possible the other party to this delegate is attempting to start up a wallet that is causing your node to lock?
-
Do you have your email properly configured in the "notification" section of your config.yaml file? Is there something in the logs that a notification cannot be sent or does everything seem normal? Also, your client need to be synchronized and on the main fork to be able to detect the missed blocks, if you end up on a minority fork then the detection cannot work.
Yes, I get email notifications. I tested that with network connections limits by adjusting the minimum number to be high. The tools notify if you drop below that minimum.
There is far less than 1 second deviation of the system time, NTP sync is working and the avg delegate participation is > 95% . No indication when this "locking" is happening that the node is on a minority fork.
hmmm that is weird, then, not sure what can cause blocks to be missed without being noticed. I'll have another look at the relevant code, see if I can spot something. Another thing I will most certainly do is add another monitoring plugin that checks whether the wallet is locked / unlocked and send a notification upon change of state. That way, you'll get a notification when the wallets gets locked.