Bug 849975 - sysrq magic key combos are not passed to the guest
sysrq magic key combos are not passed to the guest
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk (Show other bugs)
6.3
Unspecified Unspecified
medium Severity low
: beta
: 6.4
Assigned To: Christophe Fergeau
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-21 07:48 EDT by David Jaša
Modified: 2014-02-28 07:58 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-19 09:17:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2012-08-21 07:48:47 EDT
Description of problem:
sysrq magic key combos are not passed to the guest

Version-Release number of selected component (if applicable):
virt-viewer-0.5.2-9.el6.x86_64
spice-gtk-0.11-11.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. open a terminal in a client and in a guest
2. in both terminals, run: tail -fn0 /var/log/messages
3. focus virt-viewer client window (both keyboard & mouse)
4. issue alt+sysrq+s (emergency sync) combo
  
Actual results:
only the client gets the combo:
# tail -fn0 /var/log/messages
Aug 21 13:10:44 dhcp-29-7 kernel: SysRq : Emergency Sync
Aug 21 13:10:44 dhcp-29-7 kernel: Emergency Sync complete

Expected results:
only the guest gets the combo (because the user doesn't want to send say alt+sysrq+c to both...)

Additional info:
Comment 1 David Jaša 2012-08-21 09:54:48 EDT
Few clarifications:

* in remote-viewer and spicy, the only way to pass a combo to the guest is to add shift key to is, like alt+shift+sysrq+s. Even then, the combo is passed to both client and guest

* old spice-client can issue the combos using its now-deprecated sticky alt feature
Comment 2 Christophe Fergeau 2012-08-29 12:21:37 EDT
I don't think we can intercept sysrq combinations, so we'd need a send-key menu, or sticky keys to implement this...
Comment 3 Marc-Andre Lureau 2012-11-18 11:55:34 EST
(In reply to comment #1)
> Few clarifications:
> 
> * in remote-viewer and spicy, the only way to pass a combo to the guest is
> to add shift key to is, like alt+shift+sysrq+s. Even then, the combo is
> passed to both client and guest


lowering severity since it is not critical for the normal usage, no crash/leak etc either. Furthermore you found a solution to the issue.
Comment 4 RHEL Product and Program Management 2012-12-14 02:23:51 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 6 Jonathon Jongsma 2013-09-09 12:40:42 EDT
We could add a menu item to the "Send key" menu, but that's only really feasible if we want to support a small number of these magic sysrq combinations.  if we had to add an item for each possible magic sysrq combination, that menu would get rather huge. Which combinations do we want to support?

On the other hand, the workaround mentioned above (including Shift) doesn't appear to work here (with a Fedora 19 host)
Comment 7 Christophe Fergeau 2013-09-10 03:19:09 EDT
Iirc virtualbox handles that by having scroll lock (iirc)  act as alt when pressed in a key combination.
spicec used to handle that using a sticky alt (hold alt for 5 seconds, release it, and then press the rest of the key combination).
Comment 8 RHEL Product and Program Management 2013-10-14 00:50:31 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 9 Marc-Andre Lureau 2014-02-18 15:01:10 EST
Otoh, if you disable sysrq on client side, it is working. Thus I would consider this as notabug, as this is certainly not a good idea to try a sysrq on both client and guest at the same time. Somebody disagree with that?
Comment 10 David Jaša 2014-02-19 09:11:58 EST
(In reply to Marc-Andre Lureau from comment #9)
> Otoh, if you disable sysrq on client side, it is working. Thus I would
> consider this as notabug, as this is certainly not a good idea to try a
> sysrq on both client and guest at the same time. Somebody disagree with that?

Sure.

Would it make sense to have keyboard shortcuts for sysrq key combos similar to ctrl-alt-end for ctrl-alt-del - so that user can press e.g. alt+pause/break+<key>? If so, we could transform the bug so such a RFE.
Comment 11 Marc-Andre Lureau 2014-02-19 09:15:29 EST
imho, someone doing sysrq with a guest should know that it is intercepted by client first. I don't see the need for extra shortcuts for something that is very much only for hackers (I even never use sysrq myself!).
Comment 12 Marc-Andre Lureau 2014-02-19 09:17:36 EST
closing as worksforme, feel free to reopen if you have valid reasons..
Comment 13 Christophe Fergeau 2014-02-20 07:13:06 EST
(In reply to Marc-Andre Lureau from comment #9)
> Otoh, if you disable sysrq on client side, it is working.

Fwiw, no idea how you disable sysrq on client side, this would probably deserve some documentation, or a kb article...
Comment 14 Christophe Fergeau 2014-02-20 07:14:28 EST
(In reply to David Jaša from comment #10)
> Would it make sense to have keyboard shortcuts for sysrq key combos similar
> to ctrl-alt-end for ctrl-alt-del - so that user can press e.g.
> alt+pause/break+<key>? If so, we could transform the bug so such a RFE.

Imo it would be nice to have.
Comment 15 Marc-Andre Lureau 2014-02-20 07:23:29 EST
I just google:

http://en.wikipedia.org/wiki/Magic_SysRq_key

There are also alternate way to do sysrq,

I disagree having keymaps/translation by default, we should have 1-1 whenever possible. In this case, the combination works when the client side is configured to permit it.
Comment 16 Christophe Fergeau 2014-02-28 07:58:30 EST
(In reply to Marc-Andre Lureau from comment #15)
> I just google:
> 
> http://en.wikipedia.org/wiki/Magic_SysRq_key
> 

For anyone reading this bug

https://en.wikipedia.org/wiki/Magic_SysRq_key#Configuration

"The feature is controlled both by a compile-time option in the kernel configuration, CONFIG_MAGIC_SYSRQ, and a sysctl kernel parameter, kernel.sysrq. To be able to use this functionality the CONFIG_MAGIC_SYSRQ option has to be enabled at kernel compile time.

The SysRq key can be disabled with the following command:

echo 0 > /proc/sys/kernel/sysrq

To re-enable:

echo 1 > /proc/sys/kernel/sysrq"

> There are also alternate way to do sysrq,
> 
> I disagree having keymaps/translation by default, we should have 1-1
> whenever possible. In this case, the combination works when the client side
> is configured to permit it.

Except that this cannot be configured by regular users. And if this is our 'official' answer for people asking how to achieve that, this imo should be documented.

Note You need to log in before you can comment on or make changes to this bug.