Capture Ctrl+C in cli_wallet when not in daemon mode #1193 #1232

cogutvalera · 2018-08-03T15:46:28Z

pmconrad · 2018-08-09T20:17:01Z

IMO we should capture and treat SIGTERM the same as SIGINT.

pmconrad

Doesn't work for me - pressed CTRL-C and got message "Captured CTRL+C not in daemon mode", but wallet didn't exit.
I suspect that's because wallet_cli->stop internally calls the same wait() that is called by main.cpp, but https://github.com/bitshares/bitshares-fc/blob/master/src/thread/future.cpp#L107

pmconrad · 2018-08-09T19:26:07Z

programs/cli_wallet/main.cpp

+
+         fc::set_signal_handler([&wallet_cli, &wapi, &wallet_file](int signal) {
+            ilog( "Captured CTRL+C not in daemon mode" );
+            wapi->save_wallet_file(wallet_file.generic_string());


Not required here, will be handled in line 302

abitmore · 2018-08-14T12:51:47Z

programs/cli_wallet/main.cpp

            wapi->save_wallet_file(wallet_file.generic_string());
-            wallet_cli->stop();
+            std::terminate();


Terminate? Why not exit? (I want to know why but not simply asking for a change)

because exit cannot finish program fully as terminate can

I'm not convinced that we should call this. Actually, I don't like exit either, but IMHO terminate is even worse. For example, why not raise SIGKILL, I guess it can end the program as well, but all of them don't seem correct.

# abort indicates "abnormal" end to the program, and raises the the POSIX signal SIGABRT, which means that any handler that you have registered for that signal will be invoked, although the program will still terminate afterwords in either case. Usually you would use abort in a C program to exit from an unexpected error case where the error is likely to be a bug in the program, rather than something like bad input or a network failure. For example, you might abort if a data structure was found to have a NULL pointer in it when that should logically never happen. # exit indicates a "normal" end to the program, although this may still indicate a failure (but not a bug). In other words, you might exit with an error code if the user gave input that could not be parsed, or a file could not be read. An exit code of 0 indicates success. exit also optionally calls handlers before it ends the program. These are registered with the atexit and on_exit functions. #std::terminate is what is automatically called in a C++ program when there is an unhandled exception. This is essentially the C++ equivalent to abort, assuming that you are reporting all your exceptional errors by means of throwing exceptions. This calls a handler that is set by the std::set_terminate function, which by default simply calls abort.

We should do a "normal" end.

"normal" end won't fully terminate cli_wallet

This is what you need to figure out: how to end the program normally when needed.

Thanks.

@cogutvalera I have explained above what the problem is, please try to solve instead of using dirty workarounds.

@pmconrad I don't think terminate is dirty workaround, just didn't think as @abitmore mentioned about other wrappers that may use cli_wallet program, you didn't talk about wrappers and I didn't think about them

https://stackoverflow.com/questions/30250934/how-to-end-c-code

...but IMO exiting in any way is not the way to go here - just shut down wallet_cli cleanly.

cogutvalera · 2018-08-28T08:12:50Z

Guys, check please when you will have enough time. Is cancel thread good enough ?

Thanks !

abitmore · 2018-08-28T13:08:10Z

I guess it's better, although the code looks a bit ugly.

cogutvalera · 2018-08-28T13:22:47Z

@abitmore Thank you very much ! I will think about it and how to improve the code !

pmconrad · 2018-08-28T16:20:38Z

Please explain why you don't shut down wallet_cli cleanly.

cogutvalera · 2018-08-28T17:26:14Z

@pmconrad please tell me what do you mean by shut down wallet_cli cleanly ?

do we have clean method that can close cli_wallet cleanly ? Direct me please and I will change the code with the best way and best approach of course for sure ! Not a problem, maybe I've missed something.

Thanks !

abitmore · 2018-08-29T00:51:17Z

@cogutvalera I think we need code like wallet_cli->quit(); when captured SIGINT or SIGTERM in main(). I used the word like because I don't know if it will work, but it's the spirit.

cogutvalera · 2018-08-29T03:15:07Z

@abitmore @pmconrad I've tried earlier wapi->quit() and wallet_cli->stop() but it cannot stop thread from main when SIGINT or SIGTERM is captured, that's why currently I'm using pthread_cancel solution. Isn't it good enough ? Should I spent more time and fight with another one solution ? Should I try to find another one solution ?

Thanks !

pmconrad · 2018-08-30T12:57:36Z

3 weeks ago I wrote:

I suspect that's because wallet_cli->stop internally calls the same wait() that is called by main.cpp, but https://github.com/bitshares/bitshares-fc/blob/master/src/thread/future.cpp#L107

Try to work around this by adding a nowait=false parameter to stop, or something along that line.

cogutvalera · 2018-08-30T14:39:41Z

@pmconrad Thank you very much ! I've tried to work around earlier but nothing helped, will try again more to play with this approach as you suggested.

Thanks !

cogutvalera · 2018-09-28T09:16:51Z

rebased
also #1193 issue requires PR for fc library bitshares/bitshares-fc#77

pmconrad · 2018-09-28T12:28:11Z

programs/cli_wallet/main.cpp

+         fc::set_signal_handler([&wallet_cli, &wapi, &wallet_file](int signal) {
+            ilog( "Captured SIGTERM not in daemon mode" );
+            wapi->save_wallet_file(wallet_file.generic_string());
+            wallet_cli->quit_blocked_thread();


I found a simpler solution: just call fclose(stdin);. Please test on Windows.

Thanks ! Will check it ...

@pmconrad I've checked your method on Ubuntu 18.04 and your solution is simpler than mine I absolutely agree with you but your solution has disadvantage:

after unlocking wallet if you press CTRL+C then you cannot see what you type in command line, you need to restart it, in my approach we don't have this issue.

Don't you like my approach by cleanly quitting blocked thread ?

Thanks !

No, I don't like that. :-)

The thread may not be actually blocked at the time the signal is received. In that case your code will segfault.

When compiled with editline, there is a separate background thread active that will be left dangling with your method.

I could not reproduce the behaviour you described, but it might be a good idea to restore tty settings when cli shuts down.

cli_wallet uses future and promise which has blocked_thread member, when SIGINT or SIGTERM is caught I use method quit of the blocked_thread member, thus we will stop cli_wallet's thread.

@pmconrad

What do you mean by "The thread may not be actually blocked at the time the signal is received" ?

My solution just quit only cli_wallet's thread, do you mean my solution may quit another thread instead of required ?

To reproduce the behaviour I've described you should evaluate next 3 steps (tested on Ubuntu 18.04):
3.1. unlock cli_wallet
3.2 press CTRL+C
3.3 try to write anything in command line tool and you won't see what are you typing there

Thanks !

If the signal is received before you call wallet_cli->wait(), blocked_thread will be a nullptr. Admittedly this is unlikely in this specific case, but there may be other uses of fc::rpc::cli where it is less unlikely.

No, there is another thread related to cli that is not stopped by your solution.

I tried that (but not on Ubuntu). But never mind, if you see the behaviour then tty settings must be cleaned up. I suppose you do use editline? Can you reproduce this reliably?

I've used editline through VS code and after new updates seems all works fine enough now with your solution @pmconrad (I mean fclose(stdin) ! Very simple and efficient ! Thank you very much ! Will do new commit now and will close next PR in fc library bitshares/bitshares-fc#77 cause we don't need anymore

pmconrad · 2018-10-19T12:07:58Z

Please undo the fc bump in this PR and squash.

cogutvalera · 2018-10-19T12:46:45Z

ok sure ! Thanks !

cogutvalera · 2018-10-19T13:01:25Z

Done ! Thank you !

pmconrad · 2018-10-19T15:32:14Z

Thanks!

cogutvalera · 2018-10-19T15:44:27Z

Thank you ! ;)

abitmore · 2018-10-19T16:38:56Z

@pmconrad should we merge this for 201810 feature release? I think we can do it.

pmconrad · 2018-10-19T18:47:46Z

IMO we shouldn't include further issues once we have published the testnet release. Except for critical issues and bugs that are caught during testing of course.
I think this one's not critical, therefore I'd postpone it until the next release.

oxarbitrage · 2018-10-19T19:04:59Z

I agree with @pmconrad , some witnesses already installed new testnet version, announcements were made, etc. We should not push more changes to 201810 unless is absolutely necessary. We will always have stuff finished just one day after the release, we should left this and them out IMHO.

cogutvalera · 2018-10-20T06:07:16Z

Perhaps we should separate different releases in future for witness_node and cli_wallet

ryanRfox added this to the 201810 - Non-Consensus-Changing Release milestone Aug 3, 2018

pmconrad suggested changes Aug 9, 2018

View reviewed changes

abitmore reviewed Aug 14, 2018

View reviewed changes

abitmore modified the milestones: 201810 - Feature Release, 201812 - Feature Release Sep 14, 2018

cogutvalera force-pushed the issue_1193 branch from e054b81 to bed035f Compare September 28, 2018 09:11

pmconrad reviewed Sep 28, 2018

View reviewed changes

cogutvalera mentioned this pull request Sep 28, 2018

Capture Ctrl+C in cli_wallet when not in daemon mode #1193 bitshares/bitshares-fc#77

Closed

cogutvalera force-pushed the issue_1193 branch from 69eb872 to e4b59b7 Compare October 19, 2018 10:37

Capture Ctrl+C in cli_wallet when not in daemon mode bitshares#1193

7dc0de7

cogutvalera force-pushed the issue_1193 branch from e4b59b7 to 7dc0de7 Compare October 19, 2018 13:00

pmconrad approved these changes Oct 19, 2018

View reviewed changes

pmconrad merged commit 0eebc1e into bitshares:develop Oct 20, 2018

pmconrad mentioned this pull request Oct 20, 2018

Capture Ctrl+C in cli_wallet when not in daemon mode #1193

Closed

10 tasks

pmconrad mentioned this pull request Dec 21, 2018

Testnet X-Mas Sneak Preview Release #1489

Merged

MichelSantos mentioned this pull request Feb 7, 2019

Release Notes for the 201902 Feature Release of BitShares Core #1565

Closed

Capture Ctrl+C in cli_wallet when not in daemon mode #1193 #1232

Capture Ctrl+C in cli_wallet when not in daemon mode #1193 #1232

Conversation

cogutvalera commented Aug 3, 2018

pmconrad commented Aug 9, 2018

pmconrad left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abitmore Aug 14, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

abitmore Aug 14, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cogutvalera Aug 14, 2018 • edited Loading

Choose a reason for hiding this comment

pmconrad Aug 14, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cogutvalera commented Aug 28, 2018 • edited Loading

abitmore commented Aug 28, 2018

cogutvalera commented Aug 28, 2018

pmconrad commented Aug 28, 2018

cogutvalera commented Aug 28, 2018 • edited Loading

abitmore commented Aug 29, 2018 • edited Loading

cogutvalera commented Aug 29, 2018

pmconrad commented Aug 30, 2018

cogutvalera commented Aug 30, 2018

cogutvalera commented Sep 28, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cogutvalera Sep 28, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmconrad commented Oct 19, 2018

cogutvalera commented Oct 19, 2018

cogutvalera commented Oct 19, 2018

pmconrad commented Oct 19, 2018

cogutvalera commented Oct 19, 2018

abitmore commented Oct 19, 2018

pmconrad commented Oct 19, 2018

oxarbitrage commented Oct 19, 2018

cogutvalera commented Oct 20, 2018

abitmore Aug 14, 2018 •

edited

Loading

abitmore Aug 14, 2018 •

edited

Loading

cogutvalera Aug 14, 2018 •

edited

Loading

pmconrad Aug 14, 2018 •

edited

Loading

cogutvalera commented Aug 28, 2018 •

edited

Loading

cogutvalera commented Aug 28, 2018 •

edited

Loading

abitmore commented Aug 29, 2018 •

edited

Loading

cogutvalera Sep 28, 2018 •

edited

Loading