Behavior of Ctrl+C is not intuitive when OSv is run with interactive shell #49

tgrabiec · 2013-10-02T10:53:04Z

Currently when you hit Ctrl+C the qemu terminates and the OS is brought down. If I start OSv with intent to use its command line interface this behavior is not intuitive as I expect that when I'm in a shell hitting ^C will clear the command line.

A solution to this could be to:

start qemu with -nographic (unless in "daemon" mode), key strokes like Ctrl+C will be passed to the guest
change the CLI to react on Ctrl+C by clearing the command line
add a command to shut down the OS (convenience)

Downside of this approach would be that one would not be able to kill OSv from console using Ctrl+C.

I'm interested in your opinions on that one.

nyh · 2013-10-02T11:38:21Z

On Wed, Oct 2, 2013 at 1:53 PM, Tomasz Grabiec notifications@github.comwrote:

Currently when you hit Ctrl+C the qemu terminates and the OS is brought
down. If I start OSv with intent to use its command line interface this
behavior is not intuitive as I expect that when I'm in a shell hitting ^C
will clear the command line.

Yes, it's not exactly intuitive but I actually find the current behavior
useful for development - I very rarely run the shell, and usually run a
specific C or Java program, and want ^C to kill the whole guest.

I think it would be best to have both behaviors as options to run.py, like
for example ssh has the -T/-t option, so please both crowds.

A solution to this could be to:

start qemu with -nographic (unless in "daemon" mode), key strokes
like Ctrl+C will be passed to the guest

change the CLI to react on Ctrl+C by clearing the command line

^C is meant to sent a SIGINT, not to clear the line during command-line
editing. For that you have ^U (the "kill" character in stty).
And ^U already works in our shell.
So if that's all you want, you don't need to change anything.

A more complicated issue (that Avi and I were discussing this morning) is
what we really want
to happen on ^C while a program is running. If it runs
kill(getpid(),SIGINT), as it does on Unix, this
will kill the entire OSv "process". Makes sense, but at the same time, not
a very useful feature.
Instead, a ^C on a (say) ssh connection should cause some sort of
"notification" or "flag" to be
sent to the Java code running on this connection - something like
Thread.interrupt() or something
else. The end result should be that a ^C while something is running in one
ssh connection only stops
this something, and not other ssh connections, or other things happening
concurrently in other
threads.

add a command to shut down the OS (convenience)

yes, poweroff.
We already have a C++ function osv::poweroff() to do that.

Downside of this approach would be that one would not be able to kill OSv
from console using Ctrl+C.

I'm interested in your opinions on that one.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49
.

Nadav Har'El
nyh@cloudius-systems.com

tgrabiec · 2013-10-02T11:57:44Z

2013/10/2 nyh notifications@github.com

On Wed, Oct 2, 2013 at 1:53 PM, Tomasz Grabiec notifications@github.comwrote:

Currently when you hit Ctrl+C the qemu terminates and the OS is brought
down. If I start OSv with intent to use its command line interface this
behavior is not intuitive as I expect that when I'm in a shell hitting
^C
will clear the command line.

Yes, it's not exactly intuitive but I actually find the current behavior
useful for development - I very rarely run the shell, and usually run a
specific C or Java program, and want ^C to kill the whole guest.

I think it would be best to have both behaviors as options to run.py, like
for example ssh has the -T/-t option, so please both crowds.

A solution to this could be to:

start qemu with -nographic (unless in "daemon" mode), key strokes
like Ctrl+C will be passed to the guest

change the CLI to react on Ctrl+C by clearing the command line

^C is meant to sent a SIGINT, not to clear the line during command-line
editing. For that you have ^U (the "kill" character in stty).
And ^U already works in our shell.
So if that's all you want, you don't need to change anything.

You are right that Ctrl+U does clear the shell but in this issue I am
referring to another feature - sending Ctrl+C when there is no task running
in the foreground and you typed something just starts a fresh prompt in the
new line. It does not result in the shell being killed.

A more complicated issue (that Avi and I were discussing this morning) is
what we really want
to happen on ^C while a program is running. If it runs
kill(getpid(),SIGINT), as it does on Unix, this
will kill the entire OSv "process". Makes sense, but at the same time, not
a very useful feature.
Instead, a ^C on a (say) ssh connection should cause some sort of
"notification" or "flag" to be
sent to the Java code running on this connection - something like
Thread.interrupt() or something
else. The end result should be that a ^C while something is running in one
ssh connection only stops
this something, and not other ssh connections, or other things happening
concurrently in other
threads.

add a command to shut down the OS (convenience)

yes, poweroff.
We already have a C++ function osv::poweroff() to do that.

Downside of this approach would be that one would not be able to kill
OSv
from console using Ctrl+C.

I'm interested in your opinions on that one.

—
Reply to this email directly or view it on GitHub<
https://github.com/cloudius-systems/osv/issues/49>
.

Nadav Har'El
nyh@cloudius-systems.com

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-25531910
.

penberg · 2013-10-02T13:03:06Z

I'm certainly in favor of changing the default behavior of Ctrl-C not to kill QEMU.

tgrabiec · 2013-10-02T13:14:53Z

And you could still kill the QEMU from the console with ctrl+a x

2013/10/2 Pekka Enberg notifications@github.com

I'm certainly in favor of changing the default behavior of Ctrl-C not to
kill QEMU.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/49#issuecomment-25536241
.

penberg · 2013-10-02T13:31:47Z

Awesome, just like with the KVM tool! :-)

glommer · 2013-10-02T14:59:51Z

On 10/02/2013 07:53 AM, Tomasz Grabiec wrote:

Downside of this approach would be that one would not be able to kill
OSv from console using Ctrl+C.

I'm interested in your opinions on that one.

For the record, this is already how xen works, because having ctrl+C to
stop the VM in Xen case would be harder. So one advantage of doing this
is that we would be more consistent.

glommer · 2013-10-02T15:02:02Z

On 10/02/2013 10:03 AM, Pekka Enberg wrote:

I'm certainly in favor of changing the default behavior of Ctrl-C not to
kill QEMU.

I think it makes sense to kill qemu (through poweroff) if we are not
running the shell. But if we are, going back to the shell makes a lot
more sense.

In all popular shells when you are entering a command and you press Ctrl+C the shell starts a new prompt below and the old text is visible above. This patch leverages a change in jline which allows interruption of readline() invocations. See cloudius-systems/osv#49

This is in order to make it send Ctrl+C to the guest instead of killing the VM. Leads to less surprises when working with interactive shell inside OSv. To suppress the new behavior run with --g or --with-graphic. Relates to issue #49. Signed-off-by: Tomasz Grabiec <tgrabiec@cloudius-systems.com>

nyh · 2013-10-07T07:50:22Z

Closing this bug, issue #53 is a new spinoff.

tgrabiec · 2013-10-07T07:58:58Z

Actually #53 is related to this issue, but kind of perpendicular to it. Fixing #53 does not affect ^C when entering command. The fix for this issue has not yet been pushed so I'm reopening.

nyh · 2013-10-07T08:00:02Z

Sorry, didn't realise you didn't push the fix yet :(

This patch adds interrupt (by default ctrl-C) and quit (by default ctrl-\) handling to the console driver, when the ISIG termios flag is enabled (and this patch enables this flag by default). The application can change these characters or disable ISIG with ioctls, exactly as in Unix. The ^C character sends a SIGINT to the (only) process, and ^\ sends SIGQUIT. By default both abort OSv, but when running Java we get a much more interesting SIGQUIT handler - it shows a trace of all running threads and other information. Note that our line-discipline code currently sits in the console driver (we do not have ptys yet), so it only applies to the console, not to SSH connections or the likes. Also note that by default (before the patch to issue #49), qemu will catch the ^C and ^\ and won't even pass them to OSv, so apply the patch to #49 (or change the interrupt or quit characters) to see this feature working. This patch relates to issue #53. Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>

nyh · 2014-09-30T08:07:41Z

@tgrabiec, can we (you) close this issue? I think it refers to the shell we don't use any more. If we still have specific ^C issues (and we always will complain about ^C, as long as we consider OSv single-application but still want to run several applications...), we can open a new issue.

mikelo · 2015-07-20T05:45:52Z

what about right-control-C passes to OS and left-control-C to the guest?

nyh · 2015-07-20T14:07:15Z

Hi Michele, giving right-control-C and left-control-C different behavior is not something that Unix users would expect. Worse, when the guest is using the serial port instead of VGA (this is what happens by default when you run through qemu), there is no support at all for left or right control keys (pressing control-C, of either variant, will send character \003 on the emulated serial port). So your idea cannot work.

In any case, I think the current behavior is quite reasonable, don't you? Right now, control-C is passed to the guest, which might do anything it pleases with it, but the default behavior is to power off the guest. If the guest catches control-C and you nevertheless want to kill it, qemu provides a convenient way to kill a guest type "control-A x" (that's "control-A" followed by "x"). That can be used for killing any guest in qemu, not just an OSv guest.

So I think the current behavior is most reasonable, and most similar to what users would expect from Linux guests, so I think we should keep this issue closed.

ghost assigned tgrabiec Oct 2, 2013

tgrabiec mentioned this issue Oct 7, 2013

When crash CLI is started inside OSv it uses older version of jline than it was compiled with #50

Closed

tgrabiec mentioned this issue Oct 7, 2013

Cannot interrupt crash commands from the main console #53

Closed

nyh closed this as completed Oct 7, 2013

tgrabiec reopened this Oct 7, 2013

tgrabiec closed this as completed Sep 30, 2014

yuwang888 mentioned this issue Jan 2, 2018

reschedule_from_interrupt assert(sched::exception_depth <= 1) when run specjbb2015 #933

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Behavior of Ctrl+C is not intuitive when OSv is run with interactive shell #49

Behavior of Ctrl+C is not intuitive when OSv is run with interactive shell #49

tgrabiec commented Oct 2, 2013

nyh commented Oct 2, 2013

tgrabiec commented Oct 2, 2013

penberg commented Oct 2, 2013

tgrabiec commented Oct 2, 2013

penberg commented Oct 2, 2013

glommer commented Oct 2, 2013

glommer commented Oct 2, 2013

nyh commented Oct 7, 2013

tgrabiec commented Oct 7, 2013

nyh commented Oct 7, 2013

nyh commented Sep 30, 2014

mikelo commented Jul 20, 2015

nyh commented Jul 20, 2015

Behavior of Ctrl+C is not intuitive when OSv is run with interactive shell #49

Behavior of Ctrl+C is not intuitive when OSv is run with interactive shell #49

Comments

tgrabiec commented Oct 2, 2013

nyh commented Oct 2, 2013

tgrabiec commented Oct 2, 2013

penberg commented Oct 2, 2013

tgrabiec commented Oct 2, 2013

penberg commented Oct 2, 2013

glommer commented Oct 2, 2013

glommer commented Oct 2, 2013

nyh commented Oct 7, 2013

tgrabiec commented Oct 7, 2013

nyh commented Oct 7, 2013

nyh commented Sep 30, 2014

mikelo commented Jul 20, 2015

nyh commented Jul 20, 2015