-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Locked due to inactivity - password is required - On wallet with no password #5922
Comments
Is that a duplicate of #5719 ? |
No, not same situation. Well, I'm still running in screen, but. Before, the password prompt came when receiving funds. When run in screen it looks like this:
When run in bash, no screen, it looks like this:
I don't know what I guess, I'm missing a EDIT: I forgot. I'm running |
ask-password is for the "ask before a command that spends or similar". The lock screen is buggy if ask-password isn't set, I'll fix. As you found, disable it with idle-timeout. |
Well, I didn't find This setting is not shown by While this setting works, when invoked in a
|
Ah so it's the same bug after all... |
The When launching the same command with |
Yes, but after it's set, you don't get the lock screen while in screen, right ? |
When in screen, I don't get the lock screen, just the
scrolling up the screen like crazy. Maybe 100 lines per second. Also, when in screen the
has no effect. On next timeout the |
Very weird. When you are in screen, if you type "set", what is the value of the timeout ? |
After |
You've set the timeout while not in screen, right ? |
So, I actually get the lock screen at some point:
|
Is it a persistent variable/setting? While NOT in screen, |
Hmm, now back in screen |
It is persistent, that's why the password is needed as it writes back to the keys file. |
Okay, but what's up with the (in screen):
|
Is it different from the previous bug ? |
I don't know. It might be. This could be a command line parameter. The password is available already from the start. |
You're starting the CLI incorrectly.
You're using "bash -c" which tells bash to fire off a one-shot process without a tty attached. That's why the CLI's attempts to read from stdin are failing. Don't do that. This is not a wallet bug. |
This one is probably related.
A screen session: (before paste address)
A screen session: (after paste address)
So my bet is on either readline, ncurses or termcap getting screwed by screen. |
@hyc It's the same behavior with, or without, the From
|
Fwiw, when I try this the wallet-cli immediately exits when it fails to read the password.
When |
Try the same, but with |
This testnet wallet has no password. If I specify the OK, so I added |
Strange, in this strace, it isn't even trying to read.
over and over and over |
I created a wallet, set password to empty, set ask-password to never, wait for lock unlock. It works fine. So this bug is exactly the same as the previous one AFAICT (running in screen prevents password from being read). If you think it is not the case, explain precisely why, otherwise I'll close as duplicate, |
I'm not qualified to determine if it's the same. I'll take your word for it. This problem was bypassed by opening the wallet in |
OK, it looks like the same thing to me. Reopen if it's still buggy after the first one gets fixed. +duplicate |
Running a few wallet cli and rpc in screen sessions on testnet, I noticed high CPU usage
on that server. It turns out that the 2
monero-wallet-cli
is both looping like crazy,with the below output.
Attaching to the screen session, and hitting [ENTER] stops the loop, for whatever
time the
idle
timeout is at.Those 2 are throwaway test wallets, and there is no password set.
The text was updated successfully, but these errors were encountered: