GNU bug report logs -
#12478
cat SEGV when I press Ctrl-Alt-SysRq-1 on text console
Previous Next
Reported by: "Rafal W." <kenorb <at> gmail.com>
Date: Thu, 20 Sep 2012 15:56:02 UTC
Severity: normal
Tags: moreinfo, notabug
Done: Bob Proulx <bob <at> proulx.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12478 in the body.
You can then email your comments to 12478 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Thu, 20 Sep 2012 15:56:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Rafal W." <kenorb <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Thu, 20 Sep 2012 15:56:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
> $ cat /dev/zero
> ^\Quit (core dumped)
>
> Steps to reproduce:
> 1. Switch to any text console (it doesn't happen in X).
> 2. Login
> 3. Run: cat /dev/zero
> 4. Press: Ctrl-Alt-SysRq-1 (or any number except letters:)
> 5. You'll see: ^\Quit (core dumped)
>
> Here is the backtrace:
> kenorb <at> kenorb-HP-Compaq-8100-Elite-SFF-PC:/usr/src/coreutils-8.13/src$ gdb ./cat
> GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2) 7.4-2012.04
> Copyright (C) 2012 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> For bug reporting instructions, please see:
> <http://bugs.launchpad.net/gdb-linaro/>...
> Reading symbols from /usr/src/coreutils-8.13/src/cat...done.
> (gdb) set args /dev/zero
> (gdb) run
> Starting program: /usr/src/coreutils-8.13/src/cat /dev/zero
> ^\
> Program received signal SIGQUIT, Quit.
> 0x00007ffff7b02100 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82
> 82 ../sysdeps/unix/syscall-template.S: No such file or directory.
> (gdb) bt
> #0 0x00007ffff7b02100 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82
> #1 0x0000000000405184 in safe_write (fd=1, buf=0x60f000, count=32768) at safe-read.c:66
> #2 0x0000000000402dba in full_write (fd=1, buf=0x60f000, count=32768) at full-write.c:65
> #3 0x0000000000401e0e in simple_cat (buf=0x60f000 "", bufsize=32768) at cat.c:186
> #4 0x0000000000402958 in main (argc=2, argv=0x7fffffffe088) at cat.c:731
> (gdb) bt full
> #0 0x00007ffff7b02100 in __write_nocancel () at ../sysdeps/unix/syscall-template.S:82
> No locals.
> #1 0x0000000000405184 in safe_write (fd=1, buf=0x60f000, count=32768) at safe-read.c:66
> result = 32768
> #2 0x0000000000402dba in full_write (fd=1, buf=0x60f000, count=32768) at full-write.c:65
> n_rw = 32768
> total = 0
> ptr = 0x60f000 ""
> #3 0x0000000000401e0e in simple_cat (buf=0x60f000 "", bufsize=32768) at cat.c:186
> n = 32768
> n_read = 32768
> #4 0x0000000000402958 in main (argc=2, argv=0x7fffffffe088) at cat.c:731
> outsize = 32768
> insize = 32768
> page_size = 4096
> inbuf = 0x60ef90 ""
> outbuf = 0x0
> ok = true
> c = -1
> argind = 1
> out_dev = 15774435
> out_ino = 9
> check_redirection = false
> have_read_stdin = false
> stat_buf = {st_dev = 5, st_ino = 1031, st_nlink = 1, st_mode = 8630, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 261, st_size = 0, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1348073751, tv_nsec = 756796048},
> st_mtim = {tv_sec = 1348073751, tv_nsec = 756796048}, st_ctim = {tv_sec = 1348073751, tv_nsec = 756796048}, __unused = {0, 0, 0}}
> number = false
> number_nonblank = false
> squeeze_blank = false
> show_ends = false
> show_nonprinting = false
> show_tabs = false
> file_open_mode = 0
> long_options = {{name = 0x409810 "number-nonblank", has_arg = 0, flag = 0x0, val = 98}, {name = 0x409820 "number", has_arg = 0, flag = 0x0, val = 110}, {name = 0x409827 "squeeze-blank", has_arg = 0, flag = 0x0, val = 115}, {
> name = 0x409835 "show-nonprinting", has_arg = 0, flag = 0x0, val = 118}, {name = 0x409846 "show-ends", has_arg = 0, flag = 0x0, val = 69}, {name = 0x409850 "show-tabs", has_arg = 0, flag = 0x0, val = 84}, {
> name = 0x40985a "show-all", has_arg = 0, flag = 0x0, val = 65}, {name = 0x409863 "help", has_arg = 0, flag = 0x0, val = -130}, {name = 0x409868 "version", has_arg = 0, flag = 0x0, val = -131}, {name = 0x0, has_arg = 0,
> flag = 0x0, val = 0}}
> (gdb)
>
> It's a cat bug, or libc?
>
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Thu, 20 Sep 2012 19:52:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Rafal W. writes:
>
> > $ cat /dev/zero
> > ^\Quit (core dumped)
> >
> > Steps to reproduce:
> > 1. Switch to any text console (it doesn't happen in X).
> > 2. Login
> > 3. Run: cat /dev/zero
> > 4. Press: Ctrl-Alt-SysRq-1 (or any number except letters:)
What's that supposed to do? Ctrl isn't normally used with SysRq.
> > 5. You'll see: ^\Quit (core dumped)
The ^\ character generates a QUIT signal (the same way ^C generates INT), and
death with core dump is the default response to SIGQUIT. Ctrl-4 is an
alternate way of typing Ctrl-\ so this is all perfectly normal for a key
combination involving Ctrl and 4.
By adding SysRq into the mix I don't know what exactly you accomplished.
Maybe you confused the keyboard. Most keyboards don't have every key wired
separately, and weird combinations can send events for keys that weren't
pressed.
To investigate further, try running 'stty -isig' to disable signal
generation, then 'cat >/dev/null' or maybe 'od -c' and type your key
combinations. Ctrl-D should still work for EOF to get you out, which is not a
signal so it's not disabled by stty -isig.
Added tag(s) moreinfo.
Request was from
Bob Proulx <bob <at> proulx.com>
to
control <at> debbugs.gnu.org.
(Sun, 30 Sep 2012 05:37:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Sun, 30 Sep 2012 05:41:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Rafal,
Any news? Please try the steps that Alan has suggested.
I marked the bug ticket as needing more information.
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Mon, 01 Oct 2012 07:43:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Hi Bob,
thanks for the reminder, but I didn't receive any message from Alan,
could you re-post it?
Maybe it went to Spam.
Is there any web version of this bug tracker? At work they're blocking
the access for all the emails.
Kind Regards,
Rafal
Sent from my iPhone
On 30 Sep 2012, at 07:40, Bob Proulx <bob <at> proulx.com> wrote:
> Rafal,
>
> Any news? Please try the steps that Alan has suggested.
> I marked the bug ticket as needing more information.
>
> Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Mon, 01 Oct 2012 07:55:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Yes, I've tried and it didn't QUIT (it ignored SysRq signal). I didn't
know about Ctrl-4 shortcut for sending the QUIT signal. After that I
had to kill the process, because Control-D didn't work.
So I'm assuming it's by design.
Thanks for your help.
Kind Regards,
Rafal
Sent from my iPhone
On 30 Sep 2012, at 07:40, Bob Proulx <bob <at> proulx.com> wrote:
> Rafal,
>
> Any news? Please try the steps that Alan has suggested.
> I marked the bug ticket as needing more information.
>
> Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Mon, 01 Oct 2012 08:00:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 12478 <at> debbugs.gnu.org (full text, mbox):
But if Control-4 is sending QUIT signal, why:
Control-1 does kill the process?
I've checked again and actually it's not even about the number.
When I press only: Control-SysRq it kills the process as well.
Sometimes it happens on press, sometimes on release.
Kind Regards,
Rafal
Sent from my iPhone
On 30 Sep 2012, at 07:40, Bob Proulx <bob <at> proulx.com> wrote:
> Rafal,
>
> Any news? Please try the steps that Alan has suggested.
> I marked the bug ticket as needing more information.
>
> Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Mon, 01 Oct 2012 09:31:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Rafal W. wrote:
> Hi Bob,
> thanks for the reminder, but I didn't receive any message from Alan,
> could you re-post it?
> Maybe it went to Spam.
> Is there any web version of this bug tracker?
Yes. Any mail sent to bug-coreutils gets an issue number,
which comes with a URL like this: http://bugs.gnu.org/12478
Alan's reply to you is here:
http://bugs.gnu.org/12478#8
> At work they're blocking the access for all the emails.
Sounds like they have a buggy mail filter.
Spam on this list is exceptionally rare.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Mon, 01 Oct 2012 09:33:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Rafal W. writes:
>
> But if Control-4 is sending QUIT signal, why:
> Control-1 does kill the process?
> I've checked again and actually it's not even about the number.
> When I press only: Control-SysRq it kills the process as well.
> Sometimes it happens on press, sometimes on release.
Is your SysRq key also the PrtSc key? It will be if your keyboard is a
descendant of the IBM PC/AT design. With Alt, it's the SysRq key. Without
Alt, it's the PrtSc key. So if your Control-Sysrq combination doesn't include
Alt, then it's really Control-PrtSc and you should call it that instead of
Control-Sysrq which just confusing.
For other keys, the interpretation of modifiers (including Alt) is done in
software. The PrtSc/SysRq key is the only one in which a distinction is made
in hardware. PrtSc and SysRq are different scancodes. This specialness
probably influenced the decision to use SysRq as a magic key for talking to
the Linux kernel.
Now, on to why you got your SIGQUIT. Well, the default keymap for the Linux
console generates ^\ when you press PrtSc. That's not a reason, that's just a
fact. I don't know the reason. The Ctrl-4 thing is, I believe, a matter of
accurate vt100 emulation. At least it's part of a neat pattern. Ctrl-2
through Ctrl-8 generate all the control codes that aren't ^A through ^Z
alphabeticals, in numerical order:
key byte echoprt ASCII name
Ctrl-2 0 ^@ NUL
Ctrl-3 27 ^[ ESC
Ctrl-4 28 ^\ FS
Ctrl-5 29 ^] GS
Ctrl-6 30 ^^ RS
Ctrl-7 31 ^_ US
Ctrl-8 127 ^? DEL
Notice that one of them, Ctrl-6 for ^^ actually makes sense. The Ctrl-^ is
Ctrl-Shift-6 after all. Perhaps the others were simply built around that one
as a logical extension.
Oops, I got sidetracked. Why does PrtSc generate ^\ on the Linux console? I
don't know. Looking at the historical source code, it seems that it has been
this way since Linux-0.99.10 (June 7, 1993), in which the keyboard driver was
massively overhauled to support loadable keymaps. In 0.99.9 there is this:
/* Print screen key sends E0 2A E0 37 and puts
the VT100-ESC sequence ESC [ i into the queue, ChN */
puts_queue("\033\133\151");
So in conclusion, the PrtSc ^\ mapping snuck in as part of a large patch that
wasn't supposed to change any defaults, but did. Accident... or sabotage?
Insert your conspiracy theory here. History says Risto Kankkunen did the
loadable keymap patch, so that's who to blame. ChN appears to be:
* Some additional features added by Christoph Niemann (ChN), March 1993
Whatever the reason behind this annoying ^\, fixing it isn't hard:
# It's too easy to hit PrtSc by accident. mapping it to ^\ hurts!
loadkeys <<'EOF'
keycode 99 = VoidSymbol
EOF
I've had that in my system startup for a long time. Actually it's a bit more
complicated since I have a few other keys I like to remap, but the comment is
exactly as I wrote it at least 15 years ago. (I don't hit PrtSc by accident
much since I got my Happy Hacking keyboard!)
VoidSymbol makes the key do nothing at all when pressed. I suppose you could
map it to "ESC [ i" like it used to be in 0.99.9 if you feel like you must
right this historical wrong.
The remapping has no effect on the usability of the magic SysRq functions,
because they magically bypass the remapping table.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Mon, 01 Oct 2012 10:17:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Hi,
Thanks for this info.
Just to explain why I press it with Control and Alt.
My Linux freezing all the time, so sometimes I'm using kernel SysRq
for the reason.
So in example if I want to check all currently held Locks with SysRq-D
(which doesn't work anyway), so:
When I press SysRq-D, I've KSnapshot popping up. In the text console
it doesn't work at all.
When I press Control-SysRq-D, my session is getting logout.
When I press Control-Alt-SysRq-D my processes are killed.
So whatever I press, bad things are happening.
Alt key prevent the QUIT till it's released.
This annoying problem is related to all Linux binaries, even sleep. At
least my train (sl) is get killed on Ctrl-SysRq:)
So I've started to use only Ctrl-Alt-SysRq-something as a workaround
of these kind of signal problems.
Numbers I've used to increase kernel debug messaging, but instead I'm
killing the applications.
As suggested, I can't ignore my SysRq key, because I'm using it quite
often to debug my freezes.
I could live with Control-4 (on the other hand it's quite useful), but
I'm against the killing using just SysRq key (which is
multiple-purposes key), I'm not sure if this could be fixed or there
is some unwritten rule to not fix '93 old code:)
Kind Regards,
Rafal
Sent from my iPhone
On 1 Oct 2012, at 11:37, Alan Curry <pacman-cu <at> kosh.dhis.org> wrote:
> Rafal W. writes:
>>
>> But if Control-4 is sending QUIT signal, why:
>> Control-1 does kill the process?
>> I've checked again and actually it's not even about the number.
>> When I press only: Control-SysRq it kills the process as well.
>> Sometimes it happens on press, sometimes on release.
>
> Is your SysRq key also the PrtSc key? It will be if your keyboard is a
> descendant of the IBM PC/AT design. With Alt, it's the SysRq key. Without
> Alt, it's the PrtSc key. So if your Control-Sysrq combination doesn't include
> Alt, then it's really Control-PrtSc and you should call it that instead of
> Control-Sysrq which just confusing.
>
> For other keys, the interpretation of modifiers (including Alt) is done in
> software. The PrtSc/SysRq key is the only one in which a distinction is made
> in hardware. PrtSc and SysRq are different scancodes. This specialness
> probably influenced the decision to use SysRq as a magic key for talking to
> the Linux kernel.
>
> Now, on to why you got your SIGQUIT. Well, the default keymap for the Linux
> console generates ^\ when you press PrtSc. That's not a reason, that's just a
> fact. I don't know the reason. The Ctrl-4 thing is, I believe, a matter of
> accurate vt100 emulation. At least it's part of a neat pattern. Ctrl-2
> through Ctrl-8 generate all the control codes that aren't ^A through ^Z
> alphabeticals, in numerical order:
>
> key byte echoprt ASCII name
> Ctrl-2 0 ^@ NUL
> Ctrl-3 27 ^[ ESC
> Ctrl-4 28 ^\ FS
> Ctrl-5 29 ^] GS
> Ctrl-6 30 ^^ RS
> Ctrl-7 31 ^_ US
> Ctrl-8 127 ^? DEL
>
> Notice that one of them, Ctrl-6 for ^^ actually makes sense. The Ctrl-^ is
> Ctrl-Shift-6 after all. Perhaps the others were simply built around that one
> as a logical extension.
>
> Oops, I got sidetracked. Why does PrtSc generate ^\ on the Linux console? I
> don't know. Looking at the historical source code, it seems that it has been
> this way since Linux-0.99.10 (June 7, 1993), in which the keyboard driver was
> massively overhauled to support loadable keymaps. In 0.99.9 there is this:
>
> /* Print screen key sends E0 2A E0 37 and puts
> the VT100-ESC sequence ESC [ i into the queue, ChN */
> puts_queue("\033\133\151");
>
> So in conclusion, the PrtSc ^\ mapping snuck in as part of a large patch that
> wasn't supposed to change any defaults, but did. Accident... or sabotage?
> Insert your conspiracy theory here. History says Risto Kankkunen did the
> loadable keymap patch, so that's who to blame. ChN appears to be:
>
> * Some additional features added by Christoph Niemann (ChN), March 1993
>
> Whatever the reason behind this annoying ^\, fixing it isn't hard:
>
> # It's too easy to hit PrtSc by accident. mapping it to ^\ hurts!
> loadkeys <<'EOF'
> keycode 99 = VoidSymbol
> EOF
>
> I've had that in my system startup for a long time. Actually it's a bit more
> complicated since I have a few other keys I like to remap, but the comment is
> exactly as I wrote it at least 15 years ago. (I don't hit PrtSc by accident
> much since I got my Happy Hacking keyboard!)
>
> VoidSymbol makes the key do nothing at all when pressed. I suppose you could
> map it to "ESC [ i" like it used to be in 0.99.9 if you feel like you must
> right this historical wrong.
>
> The remapping has no effect on the usability of the magic SysRq functions,
> because they magically bypass the remapping table.
>
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Mon, 01 Oct 2012 10:38:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Rafal W. writes:
>
> So in example if I want to check all currently held Locks with SysRq-D
> (which doesn't work anyway), so:
> When I press SysRq-D, I've KSnapshot popping up. In the text console
> it doesn't work at all.
ksnapshot sounds like something that might respond to a PrtSc keypress. This
is a sign that you aren't using Alt, so what you've really done is PrtSc-D.
Didn't I tell you already to stop using "SysRq" to descibe key combinations
that don't include Alt? WITHOUT ALT IT IS NOT A SYSRQ KEY. Got that yet?
Reread it until you do.
> When I press Control-SysRq-D, my session is getting logout.
Well, Ctrl-D is EOF and PrtSc+D is a meaningless combination (as meaningless
as pressing D and Q at the same time, it's anyone's guess which will take
precedence)
> When I press Control-Alt-SysRq-D my processes are killed.
Too many keys there, I can't guess what they're all doing. Get rid of the
Control. And make sure your kernel has CONFIG_LOCKDEP, otherwise the Sysrq+D
function is disabled.
Also, based on the Subject line, you think "SEGV" is a synonym for core dump.
Stop thinking that. Nothing segfaulted. SIGSEGV is one of many signals that
can cause a core dump. SIGQUIT is another one.
--
Alan Curry
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Mon, 01 Oct 2012 11:28:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Thanks. Without Control more things are working.
Alt-SysRq-m and other letters works, doesn't kill the process.
So the only problems are numbers:
Alt-SysRq-1 to 9 (exempt 5 & 6) is killing the process.
Looks like 5 and 6 have some special privileges.
Kind Regards,
Rafal
Sent from my iPhone
On 1 Oct 2012, at 12:41, "Alan Curry" <pacman-cu <at> kosh.dhis.org> wrote:
> Rafal W. writes:
>>
>> So in example if I want to check all currently held Locks with SysRq-D
>> (which doesn't work anyway), so:
>> When I press SysRq-D, I've KSnapshot popping up. In the text console
>> it doesn't work at all.
>
> ksnapshot sounds like something that might respond to a PrtSc keypress. This
> is a sign that you aren't using Alt, so what you've really done is PrtSc-D.
> Didn't I tell you already to stop using "SysRq" to descibe key combinations
> that don't include Alt? WITHOUT ALT IT IS NOT A SYSRQ KEY. Got that yet?
> Reread it until you do.
>
>> When I press Control-SysRq-D, my session is getting logout.
>
> Well, Ctrl-D is EOF and PrtSc+D is a meaningless combination (as meaningless
> as pressing D and Q at the same time, it's anyone's guess which will take
> precedence)
>
>> When I press Control-Alt-SysRq-D my processes are killed.
>
> Too many keys there, I can't guess what they're all doing. Get rid of the
> Control. And make sure your kernel has CONFIG_LOCKDEP, otherwise the Sysrq+D
> function is disabled.
>
> Also, based on the Subject line, you think "SEGV" is a synonym for core dump.
> Stop thinking that. Nothing segfaulted. SIGSEGV is one of many signals that
> can cause a core dump. SIGQUIT is another one.
>
> --
> Alan Curry
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Mon, 01 Oct 2012 20:55:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Rafal W. wrote:
> Thanks. Without Control more things are working.
> Alt-SysRq-m and other letters works, doesn't kill the process.
> So the only problems are numbers:
> Alt-SysRq-1 to 9 (exempt 5 & 6) is killing the process.
> Looks like 5 and 6 have some special privileges.
Typically 5 and 6 will change the kernel logging level to those
values. For whatever reason on my Debian system the other numbers are
not enabled to change the log level. I have never bothered to
investigate why. On my system the other number 1-4,7-9,0 keys appear
to do nothing. But it is documented that the Alt-SysRq-0 through
Alt-SysRq-9 keys set the console log level.
http://kernel.org/doc/Documentation/sysrq.txt
The useful kernel log levels are:
#define KERN_EMERG "<0>" /* system is unusable */
#define KERN_ALERT "<1>" /* action must be taken immediately */
#define KERN_CRIT "<2>" /* critical conditions */
#define KERN_ERR "<3>" /* error conditions */
#define KERN_WARNING "<4>" /* warning conditions */
#define KERN_NOTICE "<5>" /* normal but significant condition */
#define KERN_INFO "<6>" /* informational */
#define KERN_DEBUG "<7>" /* debug-level messages */
The linux kernel default is 8 so that all messages are logged to the
console. This can produce a large amount of noise to the point of
making the console unusable on a firewall machine with an active
Internet connection since this will cause many log events rapidly
consuming the screen display. At least one distro sets it to 3 and
another leaves it at the linux kernel default setting of 8. I
normally set this to 5 to reduce the noise on the console. I normally
do this with the 'dmesg -n5' command in the firewall init scripts but
there are several different ways to set this. The key sequence is
intended to restore usability to a console that is getting bombarded
with log events and Alt-SysRq-5 is useful for that purpose.
I think you should determine what actions are enabled on your system.
You can do this by using the /proc kernel interface directly.
$ cat /proc/sys/kernel/sysrq
What level number is produced there?
# echo h > /proc/sysrq-trigger
# tail /var/log/syslog (or tail /var/log/messages or whatever)
On my system it shows:
$ cat /proc/sys/kernel/sysrq
438
That is 0x1b6 or 2 + 4 + 16 + 32 + 128 + 256 and with this bitmap we
can see that some features are not enabled by default on my system.
2 - enable control of console logging level
4 - enable control of keyboard (SAK, unraw)
8 - enable debugging dumps of processes etc.
16 - enable sync command
32 - enable remount read-only
64 - enable signalling of processes (term, kill, oom-kill)
128 - allow reboot/poweroff
256 - allow nicing of all RT tasks
# echo h > /proc/sysrq-trigger
# tail /var/log/syslog
... SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount force-fb(V) show-blocked-tasks(W) dump-ftrace-buffer(Z)
Running 'tail -f /var/log/syslog' (or /var/log/messages, or whatever)
while you are testing pressing those keys is useful because the kernel
will log actions taken there.
Bob
Added tag(s) notabug.
Request was from
Bob Proulx <bob <at> proulx.com>
to
control <at> debbugs.gnu.org.
(Mon, 01 Oct 2012 20:58:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Tue, 02 Oct 2012 08:45:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 12478 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Yes, the Alt-SysRq + 1-4,7-9,0 keys do nothing on mine as well, even on the
plain console.
But if I send the numbers to sysrq-trigger, then it works. So probably it's
a separate bug report.
I've 1 in sysrq.
$ cat /proc/sys/kernel/sysrq
1
So in summary the process is killed if the key is not handled by anything
else. In this case Alt-SysRq 1-4,7-9,0 are not handled by kernel somehow.
So then code of release key of Alt-SysRq is sent. Pressing just Alt-SysRq
is killing the process as well. Which shouldn't happen I guess.
Rafal
On 1 Oct 2012, at 22:53, Bob Proulx <bob <at> proulx.com> wrote:
Rafal W. wrote:
Thanks. Without Control more things are working.
Alt-SysRq-m and other letters works, doesn't kill the process.
So the only problems are numbers:
Alt-SysRq-1 to 9 (exempt 5 & 6) is killing the process.
Looks like 5 and 6 have some special privileges.
Typically 5 and 6 will change the kernel logging level to those
values. For whatever reason on my Debian system the other numbers are
not enabled to change the log level. I have never bothered to
investigate why. On my system the other number 1-4,7-9,0 keys appear
to do nothing. But it is documented that the Alt-SysRq-0 through
Alt-SysRq-9 keys set the console log level.
http://kernel.org/doc/Documentation/sysrq.txt
The useful kernel log levels are:
#define KERN_EMERG "<0>" /* system is unusable */
#define KERN_ALERT "<1>" /* action must be taken immediately */
#define KERN_CRIT "<2>" /* critical conditions */
#define KERN_ERR "<3>" /* error conditions */
#define KERN_WARNING "<4>" /* warning conditions */
#define KERN_NOTICE "<5>" /* normal but significant condition */
#define KERN_INFO "<6>" /* informational */
#define KERN_DEBUG "<7>" /* debug-level messages */
The linux kernel default is 8 so that all messages are logged to the
console. This can produce a large amount of noise to the point of
making the console unusable on a firewall machine with an active
Internet connection since this will cause many log events rapidly
consuming the screen display. At least one distro sets it to 3 and
another leaves it at the linux kernel default setting of 8. I
normally set this to 5 to reduce the noise on the console. I normally
do this with the 'dmesg -n5' command in the firewall init scripts but
there are several different ways to set this. The key sequence is
intended to restore usability to a console that is getting bombarded
with log events and Alt-SysRq-5 is useful for that purpose.
I think you should determine what actions are enabled on your system.
You can do this by using the /proc kernel interface directly.
$ cat /proc/sys/kernel/sysrq
What level number is produced there?
# echo h > /proc/sysrq-trigger
# tail /var/log/syslog (or tail /var/log/messages or whatever)
On my system it shows:
$ cat /proc/sys/kernel/sysrq
438
That is 0x1b6 or 2 + 4 + 16 + 32 + 128 + 256 and with this bitmap we
can see that some features are not enabled by default on my system.
2 - enable control of console logging level
4 - enable control of keyboard (SAK, unraw)
8 - enable debugging dumps of processes etc.
16 - enable sync command
32 - enable remount read-only
64 - enable signalling of processes (term, kill, oom-kill)
128 - allow reboot/poweroff
256 - allow nicing of all RT tasks
# echo h > /proc/sysrq-trigger
# tail /var/log/syslog
... SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E)
memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK
show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N)
powerOff show-registers(P) show-all-timers(Q) unRaw Sync
show-task-states(T) Unmount force-fb(V) show-blocked-tasks(W)
dump-ftrace-buffer(Z)
Running 'tail -f /var/log/syslog' (or /var/log/messages, or whatever)
while you are testing pressing those keys is useful because the kernel
will log actions taken there.
Bob
[Message part 2 (text/html, inline)]
bug closed, send any further explanations to
12478 <at> debbugs.gnu.org and "Rafal W." <kenorb <at> gmail.com>
Request was from
Bob Proulx <bob <at> proulx.com>
to
control <at> debbugs.gnu.org.
(Tue, 02 Oct 2012 16:18:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Tue, 02 Oct 2012 16:21:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Rafal W. wrote:
> So in summary the process is killed if the key is not handled by anything
> else.
I don't agree with that conclusion. It has not been determined what
action is happening for you with Alt-SysRq-{1,2,3,4,7,8,9,0} and
without that knowledge I don't believe a conclusion can be made.
I think it likely that on your system those keys are getting mapped to
C-\ which is supposed to generate SIGQUIT which is a debugging feature
which is supposed to cause applications to core dump so that the core
image can be examined.
> In this case Alt-SysRq 1-4,7-9,0 are not handled by kernel somehow.
And they are not for me either. But nothing else happens for me either.
> So then code of release key of Alt-SysRq is sent. Pressing just Alt-SysRq
> is killing the process as well. Which shouldn't happen I guess.
But that is contrary to what you said before where you said:
> Alt-SysRq-m and other letters works, doesn't kill the process.
I think things have reduced to the point where your next step would be
to take your current key mapping issue to your software distribution
community and see what they say. The behavior on your system is
different from the behavior on other systems and therefore this seems
to me like a system dependent issue. That means that you need to
address the key mapping problem within your software distribution.
This clearly isn't a bug in any of the coreutils. I am going to go
ahead and mark the bug as closed. Feel free to continue the
discussion as I just did with this message. It will still reach all
of the participants.
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Wed, 03 Oct 2012 08:18:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Thanks for your help.
I've reported this bug against Ubuntu.
Follow-up: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1060767
Kind Regards,
Rafal
Sent from my iPhone
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Wed, 03 Oct 2012 16:04:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 12478 <at> debbugs.gnu.org (full text, mbox):
Rafal W. wrote:
> Thanks for your help.
> I've reported this bug against Ubuntu.
> Follow-up: https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1060767
Since you are using Ubuntu that is the right place to pursue the key
mapping problem. Your report there included good information.
But... You sent your report against the coreutils package and we
already determined here that this is not related to coreutils. That
means that your bug report against the coreutils package there was
incorrectly aimed from the start.
Since the problem on your system is very likely something configured
specifically on your system and not generally elsewhere. I don't have
an Ubuntu system to test this on but I doubt the key sequence there
would do any different than on my Debian machine. Could be wrong
though. In any case the first task is to get to the root cause of it.
When I have these types of problems I don't go directly to a bug
report. For one thing it is often a problem to determine the correct
target to submit against. As is the case here where twice you have
been submitting against coreutils but your issue has nothing to do
with coreutils. We have just been trying to be helpful.
Instead I go for help discussion on the users mailing list. Some
discussion it is often very helpful at determining the root cause.
And then with that information sending a targeted bug report against
the root cause of the problem will usually yield better results.
Especially in this case where I think it is likely to be a key mapping
issue and I have no idea what part of the distro would manage that
part of the system. Could be console-tools. Could be kbd. Could be
something else entirely. Don't know. Would need to find that first.
The same is true here. The coreutils general discussion list is
coreutils <at> gnu.org and we welcome discussion there before submitting a
bug report. If in the future you have questions or comments it would
be great if you would open the discussion there.
For Ubuntu the users mailing lists are described here:
https://wiki.ubuntu.com/UbuntuUsersListFAQ
http://www.ubuntu.com/support/community/mailing-lists
I would take the problem there next.
Good luck!
Bob
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Wed, 03 Oct 2012 17:22:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 12478 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Yes, coreutils was a mistake, because they've stupid autocomplete
textfield, when typing kernel, ubuntu or other keywords which I've tried,
all the time was too general, so how do I know what other options are if I
don't see any results (at last first 10?)? So I was happy to type anything
there with the idea to change it later.
I'm not much community person, once I was posting some problems/bugs on
FreeBSD forum, they call me crazy, that nobody has that kind of problems
(they call it magic), so mostly everything was ignored.
So basically I hate forums. In example Apple has some community forum
(instead of bug tracker), I've posted all my kernel crash backtraces
(generated almost once a day) and other stuff and the problem was ignored
as well, so basically problem exists, but nobody care. Secondly I'm not
doing this for a pleasure, most of the time it preventing me to work
properly (I'm not inventing this stuff, this just happens). If I'm spending
couple of hours daily (if not the whole day) only creating the bugs, so I
would spent the whole day on forums analysing and discussing the problem
and from my experience most of the time people on the forum have no any
technical knowledge at all, if they do - they say google it (even if they
don't understand the problem). So I'm kind of bug guy by the choice. And I
clearly see that this is the bug, but I don't know where yet.
---
Kind regards,
Rafal
On 3 October 2012 18:02, Bob Proulx <bob <at> proulx.com> wrote:
> Rafal W. wrote:
> > Thanks for your help.
> > I've reported this bug against Ubuntu.
> > Follow-up:
> https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/1060767
>
> Since you are using Ubuntu that is the right place to pursue the key
> mapping problem. Your report there included good information.
>
> But... You sent your report against the coreutils package and we
> already determined here that this is not related to coreutils. That
> means that your bug report against the coreutils package there was
> incorrectly aimed from the start.
>
> Since the problem on your system is very likely something configured
> specifically on your system and not generally elsewhere. I don't have
> an Ubuntu system to test this on but I doubt the key sequence there
> would do any different than on my Debian machine. Could be wrong
> though. In any case the first task is to get to the root cause of it.
>
> When I have these types of problems I don't go directly to a bug
> report. For one thing it is often a problem to determine the correct
> target to submit against. As is the case here where twice you have
> been submitting against coreutils but your issue has nothing to do
> with coreutils. We have just been trying to be helpful.
>
> Instead I go for help discussion on the users mailing list. Some
> discussion it is often very helpful at determining the root cause.
> And then with that information sending a targeted bug report against
> the root cause of the problem will usually yield better results.
> Especially in this case where I think it is likely to be a key mapping
> issue and I have no idea what part of the distro would manage that
> part of the system. Could be console-tools. Could be kbd. Could be
> something else entirely. Don't know. Would need to find that first.
>
> The same is true here. The coreutils general discussion list is
> coreutils <at> gnu.org and we welcome discussion there before submitting a
> bug report. If in the future you have questions or comments it would
> be great if you would open the discussion there.
>
> For Ubuntu the users mailing lists are described here:
>
> https://wiki.ubuntu.com/UbuntuUsersListFAQ
>
> http://www.ubuntu.com/support/community/mailing-lists
>
> I would take the problem there next.
>
> Good luck!
> Bob
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#12478; Package
coreutils.
(Wed, 03 Oct 2012 18:59:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 12478 <at> debbugs.gnu.org (full text, mbox):
bronek wrote:
> Yes, coreutils was a mistake, because they've stupid autocomplete
> textfield, when typing kernel, ubuntu or other keywords which I've tried,
> all the time was too general, so how do I know what other options are if I
> don't see any results (at last first 10?)? So I was happy to type anything
> there with the idea to change it later.
I assume that as the bug submitter you would be able to edit the bug
and make changes and reassign it.
> I'm not much community person, once I was posting some problems/bugs on
> FreeBSD forum, they call me crazy, that nobody has that kind of problems
> (they call it magic), so mostly everything was ignored.
I have the benefit of having a number of machines available to me.
When I run into a hard problem I take a victim machine and install the
system fresh from pristine released sources upon it. Then on that
fresh system I try to see if the problem is present. If not then I
know that it is something I created myself on the system after
installation through the course of events.
This type of problem is the usual one for people to describe such as
you have done. If it isn't a problem that other people are
experiencing then it must be one that has been created through the use
and modifications of the system. In which case it won't be present
upon a pristine installation. And if not then I know that it is my
problem because I created it.
> So basically I hate forums.
If by forum you mean a web based message board where people hold
conversations in the form of posted messages then I agree that I do
not like them. But if you are using the term generically as a medium
for discussion such as this mailing list then I disagree since those
have been most helpful.
> In example Apple has some community forum (instead of bug tracker),
> I've posted all my kernel crash backtraces (generated almost once a
> day) and other stuff and the problem was ignored as well, so
> basically problem exists, but nobody care.
I am sad to hear of your trouble with Apple's software. Of course the
advantage of GNU free software is that everything is available and it
is possible debug the problem outside of others. However I admit that
skill either must exist or must be developed to be able to do this.
> Secondly I'm not doing this for a pleasure, most of the time it
> preventing me to work properly (I'm not inventing this stuff, this
> just happens).
Oh no! The curse! :-)
I am sorry for laughing at this. We have all been there. But stuff
doesn't just happen. Really! There is always a reason. While people
have good days and bad days and just cantankerous days the machine
does not. Unless there is a hardware problem the machine will always
behave exactly as it is programmed to do. That is a good thing.
> If I'm spending couple of hours daily (if not the whole day) only
> creating the bugs, so I would spent the whole day on forums
> analysing and discussing the problem and from my experience most of
> the time people on the forum have no any technical knowledge at all,
> if they do - they say google it (even if they don't understand the
> problem). So I'm kind of bug guy by the choice. And I clearly see
> that this is the bug, but I don't know where yet.
And we are doing exactly the same thing here. This is a labor of
love. We don't get paid for it. Well most of us don't. And even
those that do work on the software on their free time too. We do this
because we want to make the world a better place.
This is really drifting off topic for this bug ticket. It would be
different if we were discussing this on the discussion list. To bring
it back on topic let me ask...
Do you have a spare scratch machine? I don't believe it makes sense
that this problem isn't being seen by others. If you could install a
fresh copy of your operating system on a scratch victim machine and
then try your problem there then it would be possible to determine if
it is something in the upstream to you pristine installation or if it
is something that has been changed on your installation since then.
With the problems you are lamenting I think this might be useful to
help to solve many of the issues you have been having.
If you have more discussion and it is discussion and not data to add
to this bug ticket then please start a new message thread on the
coreutils <at> gnu.org mailing list. That is the better place for it.
Good luck!
Bob
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 01 Nov 2012 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 years and 193 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.