Things don't die on ^C anymore [SOLVED]

cookiecaper · 2010-01-13 01:09:55

I type ^C and it does not kill the running program in the terminal anymore. Things have been this way since a somewhat recent system update. I can ^C (control-c) all I want and it shows up in the terminal but it does not kill the running process. ^Z stills stops it.

This is bad and I would like it to be fixed. Please help me. Thanks.

Last edited by cookiecaper (2010-01-15 23:04:08)

tavianator · 2010-01-13 01:34:18

Are you sure this is a general problem, or could it be one with a specific app? ^C just sends a SIGINT to the program; if it's in a bad state, that may not kill it. ^Z sends SIGSTOP, which always stops the process.

cookiecaper · 2010-01-13 03:38:54

Yes, I am quite sure. It won't kill locate, yaourt, pacman, paster, or sudo. It won't give me a new terminal at bash. It seems not to work at all.

tavianator · 2010-01-13 04:58:36

Hmm I've heard of this before but I don't remember the solution. What's the output of "stty"? Edit: and "trap"?

Last edited by tavianator (2010-01-13 05:02:38)

cookiecaper · 2010-01-13 05:47:12

[jeff@arch ~]$ stty
speed 38400 baud; line = 0;
iutf8
[jeff@arch ~]$ trap
[jeff@arch ~]

that is, trap outputs nothing

chlg · 2010-01-14 03:20:04

trap output seems ok to me.

in doubt, try typing "stty intr ^C"
(^C are 2 characters : ^ and C)
and try again

But I doubt that will solve the problem, since this is supposed to be the default

cookiecaper · 2010-01-14 13:17:59

I did that and it doesn't seem to have effected anything. Thanks though. : )

chlg · 2010-01-14 18:36:13

Could you try to type :
trap ls SIGINT
and then hit Ctrl+C (with no program running : just in the shell).

This will solve nothing, but at least we will know wether the SIGINT event is received or not.

Another verification could be useful : try with another terminal (xterm, rxvt, ... anyone, but the one you are already using). May be the terminal itself is traping the Ctrl+C (for example as "CUT"). I've never heard such a thing before, but nowadays nothing surprised me : someone could have decided that Windows standard have priority on Unix standard
(BTW which terminal are you using ? Which shell ?)

cookiecaper · 2010-01-14 18:58:10

[jeff@arch ~]$ trap ls SIGINT
[jeff@arch ~]$

^C doesn't do anything here.

Using a different terminal doesn't seem to help either.

Evidence does seem to point toward SIGINT not getting sent at all anymore; pkill -2 won't kill a thing either.

Ah, hmm. I just tested it and VLC seems to die on ^C, but find doesn't die, locate doesn't die, yaourt doesn't die, sudo doesn't die, etc. This is weird seeming to me.

So this seems to have a lot more to do with SIGINT and its reception than with ^C directly.

EDIT: SIGINT won't work with Firefox either. VLC is the only program I've found so far that it still works with.

Last edited by cookiecaper (2010-01-14 18:59:21)

chlg · 2010-01-14 21:26:33

Do you mean that even with "kill" you cannot send a SIGINT to any process ? (Nothing to do with Ctrl+C then).

For example, if you try to kill the shell in which you typed
trap ls INT
with kill -2, nothing happens ?

(Be sure to have your shell CWD in a non-empty directory, or, better, replace "ls" with stg else, eg "pwd")

Is it the same with another signal (I mean trapable signal, not STOP or KILL) ?

cookiecaper · 2010-01-15 13:21:10

Well, let me make sure I understand how trap works.

I am doing:
$ trap ls INT
$ trap ls HUP

which means that when the shell receives either a HUP or INT, ls should be executed, correct?

If so, ls is not executed when either INT or HUP signals are sent to trap's parent shell. Nothing happens.

mar77i · 2010-01-15 15:09:57

Well, are you using archlinux and are you on the local machine / how do processes behave without X? If so, what kernel are you using? Did you really check the above with "/bin/kill" (procps v3.2.8)?
Well, could you provide us w/ an image of your base system to experiment with it?

cookiecaper · 2010-01-15 15:35:03

Aha, it works outside of X. That's hopeful, I hadn't noticed that. I thought I had tried it before.

Yes, I am using ArchLinux. Kernel is kernel26 2.6.32.3-1. I checked the above with /bin/kill, yes.

mar77i · 2010-01-15 16:20:03

I think I found what you're looking for :

Compare the following two xev outputs. Mine is first, yours comes afterwards (from your post on bugs.archlinux.org)
What x keyboard settings have you set?

KeyPress event, serial 34, synthetic NO, window 0xc00001,
    root 0x145, subw 0x0, time 102769372, (-102,559), root:(548,580),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 34, synthetic NO, window 0xc00001,
    root 0x145, subw 0x0, time 102770158, (-102,559), root:(548,580),
    state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (03) ""
    XmbLookupString gives 1 bytes: (03) ""
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0xc00001,
    root 0x145, subw 0x0, time 102770231, (-102,559), root:(548,580),
    state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (03) ""
    XFilterEvent returns: False

KeyRelease event, serial 34, synthetic NO, window 0xc00001,
    root 0x145, subw 0x0, time 102770350, (-102,559), root:(548,580),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x3a00001,
    root 0x10c, subw 0x0, time 299061040, (522,247), root:(523,267),
    state 0x10, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 29, synthetic NO, window 0x3a00001,
    root 0x10c, subw 0x0, time 299061497, (522,249), root:(523,269),
    state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (03) "^C"
    XmbLookupString gives 1 bytes: (03) "^C"
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x3a00001,
    root 0x10c, subw 0x0, time 299061625, (522,249), root:(523,269),
    state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (03) "^C"
    XFilterEvent returns: False

KeyRelease event, serial 29, synthetic NO, window 0x3a00001,
    root 0x10c, subw 0x0, time 299066683, (522,249), root:(523,269),
    state 0x14, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Last edited by mar77i (2010-01-15 16:20:42)

cookiecaper · 2010-01-15 16:39:17

Hmm, the only difference I've noticed is XLookupString gives 1 bytes: (03) "^C" and XLookupString gives 1 bytes: (03) "".

My keyboard settings are determined by evdev as far as I know.

From Xorg.0.log:

(II) config/hal: Adding input device Microsoft Natural® Ergonomic Keyboard 4000
(**) Microsoft Natural® Ergonomic Keyboard 4000: always reports core events
(**) Microsoft Natural® Ergonomic Keyboard 4000: Device: "/dev/input/event7"
(II) Microsoft Natural® Ergonomic Keyboard 4000: Found 1 mouse buttons
(II) Microsoft Natural® Ergonomic Keyboard 4000: Found scroll wheel(s)
(II) Microsoft Natural® Ergonomic Keyboard 4000: Found relative axes
(II) Microsoft Natural® Ergonomic Keyboard 4000: Found absolute axes
(II) Microsoft Natural® Ergonomic Keyboard 4000: Found keys
(II) Microsoft Natural® Ergonomic Keyboard 4000: Configuring as mouse
(II) Microsoft Natural® Ergonomic Keyboard 4000: Configuring as keyboard
(**) Microsoft Natural® Ergonomic Keyboard 4000: YAxisMapping: buttons 4 and 5
(**) Microsoft Natural® Ergonomic Keyboard 4000: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200
(II) XINPUT: Adding extended input device "Microsoft Natural® Ergonomic Keyboard 4000" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "us"

I don't know where else to look for the settings you may want, sorry. Let me know if you need something else.

Last edited by cookiecaper (2010-01-15 16:39:50)

cookiecaper · 2010-01-15 19:49:28

I've fixed it now; it was something with the version of awesome I was using. I cleared it out and installed the awesome from the repositories and all is well now.

Thanks to all who've helped with this.

n0dix · 2010-01-15 22:12:35

Add the SOLVED tag to the title please.

Arch Linux

#1 2010-01-13 01:09:55

Things don't die on ^C anymore [SOLVED]

#2 2010-01-13 01:34:18

Re: Things don't die on ^C anymore [SOLVED]

#3 2010-01-13 03:38:54

Re: Things don't die on ^C anymore [SOLVED]

#4 2010-01-13 04:58:36

Re: Things don't die on ^C anymore [SOLVED]

#5 2010-01-13 05:47:12

Re: Things don't die on ^C anymore [SOLVED]

#6 2010-01-14 03:20:04

Re: Things don't die on ^C anymore [SOLVED]

#7 2010-01-14 13:17:59

Re: Things don't die on ^C anymore [SOLVED]

#8 2010-01-14 18:36:13

Re: Things don't die on ^C anymore [SOLVED]

#9 2010-01-14 18:58:10

Re: Things don't die on ^C anymore [SOLVED]

#10 2010-01-14 21:26:33

Re: Things don't die on ^C anymore [SOLVED]

#11 2010-01-15 13:21:10

Re: Things don't die on ^C anymore [SOLVED]

#12 2010-01-15 15:09:57

Re: Things don't die on ^C anymore [SOLVED]

#13 2010-01-15 15:35:03

Re: Things don't die on ^C anymore [SOLVED]

#14 2010-01-15 16:20:03

Re: Things don't die on ^C anymore [SOLVED]

#15 2010-01-15 16:39:17

Re: Things don't die on ^C anymore [SOLVED]

#16 2010-01-15 19:49:28

Re: Things don't die on ^C anymore [SOLVED]

#17 2010-01-15 22:12:35

Re: Things don't die on ^C anymore [SOLVED]

Board footer