Author Topic: Has anyone ever noticed the cli wallet locking before it's time?  (Read 3295 times)

0 Members and 1 Guest are viewing this topic.

Offline wackou

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.
Please vote for witness wackou! More info at http://digitalgaia.io

Offline BunkerChainLabs-DataSecurityNode

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?
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline Thom

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.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline wackou

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.
Please vote for witness wackou! More info at http://digitalgaia.io

Offline Thom

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.
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline lafona

  • Sr. Member
  • ****
  • Posts: 231
    • View Profile
  • BitShares: lafona
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.
BTS Witnesses: delegate-1.lafona     Witness Thread: https://bitsharestalk.org/index.php/topic,21569.msg280911/topicseen.html#msg280911
MUSE Witness: lafona

Offline Thom

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.



Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline vikram

Yes this is strange.. could there be anything funky with either your system clock or NTP clock ?

Offline BunkerChainLabs-DataSecurityNode

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?
+-+-+-+-+-+-+-+-+-+-+
www.Peerplays.com | Decentralized Gaming Built with Graphene - Now with BookiePro and Sweeps!
+-+-+-+-+-+-+-+-+-+-+

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
That's not documented behavior .. the client should not auto lock the wallet if an active delegate is present .. that's odd

Offline Thom

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?
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html