| View previous topic :: View next topic |
| Author |
Message |
SemmZemm
n00b
Joined: 05 Jul 2013
Posts: 62
Location: France, Russia
|
 Posted: Mon Oct 14, 2013 12:04 am Post subject: ^C doesn't kill emerge [SOLVED] |
 |
|
Hi,
When I try to kill emerge using ^C (ctrl+C) it doesn't work. It just puts ^C on terminal.
For example I can't cancel unmerging some package. I use bash as CLI. ^X, ^Z neither don't work
Some additional information:
| Code: | szldlc semmzemm # equery l bash
* Searching for bash ...
[IP-] [ ] app-shells/bash-4.2_p45:0
szldlc semmzemm # uname -a
Linux szldlc 3.11.4-gentoo #1 SMP Mon Oct 7 14:21:26 CEST 2013 x86_64 Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz GenuineIntel GNU/Linux
szldlc semmzemm # equery l portage
* Searching for portage ...
[IP-] [ ] sys-apps/portage-2.2.7:0 |
Thanks in advance!
Last edited by SemmZemm on Wed Oct 16, 2013 8:56 am; edited 1 time in total |
|
| Back to top |
|
 |
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Mon Oct 14, 2013 12:14 am Post subject: |
|
|
| This works for me. Did you disable job control on your terminal? |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Oct 14, 2013 12:15 am Post subject: |
|
|
It will do but emerge spawns a load of other processes. I generally hammer ctrl-c when I want to break out
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
SemmZemm
n00b
Joined: 05 Jul 2013
Posts: 62
Location: France, Russia
|
| Posted: Mon Oct 14, 2013 12:01 pm Post subject: |
|
|
| Hu wrote: | | This works for me. Did you disable job control on your terminal? |
Hm. Surely I didn't do it intentionally, how can I check it?
| Naib wrote: | | It will do but emerge spawns a load of other processes. I generally hammer ctrl-c when I want to break out |
But normally if I kill parent process I must also kill the children? I'd like to have this hammer too. |
|
| Back to top |
|
|
Naib
Watchman
Joined: 21 May 2004
Posts: 6051
Location: Removed by Neddy
|
| Posted: Mon Oct 14, 2013 6:47 pm Post subject: |
|
|
You are not killing the parent though but one of the children
_________________
| Quote: | | Removed by Chiitoo |
|
|
| Back to top |
|
|
SemmZemm
n00b
Joined: 05 Jul 2013
Posts: 62
Location: France, Russia
|
| Posted: Mon Oct 14, 2013 9:24 pm Post subject: |
|
|
| The same behaviour for traceroute. It doesn't create children processes. What I did wrong? |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Oct 15, 2013 1:37 am Post subject: |
|
|
Not sure about traceroute, but essentially if a process doesn't respond to signals, there's not much you can do besides wait, and eventually try kill -9. Note you should never do that normally: in update we step through SIGTERM, SIGINT and SIGQUIT (twice each), and only eventually use kill -9 after waiting 18 seconds (we wait for 3 seconds with each signal * 2.) And we do this only because we know that on restart emerge will start over, and the user wants to quit now.
Note this has nothing to do with trying to kill the children, since we know the pid of the main emerge process. It just isn't responding, since it's blocked waiting for its children (or something;)
Hmm 18 seconds seems like a long time. It rarely needs all of it tho (ie we normally see: "Terminating...\n Again .....done" vs "..forcefully.") |
|
| Back to top |
|
|
SemmZemm
n00b
Joined: 05 Jul 2013
Posts: 62
Location: France, Russia
|
| Posted: Tue Oct 15, 2013 9:19 am Post subject: |
|
|
| I know about kill, sometimes it's useful but I just want to understand why ^C doesn't work like before and to get back possiblity kill processes in the terminal like I'm used to do it. |
|
| Back to top |
|
|
Atom2
Apprentice
Joined: 01 Aug 2011
Posts: 185
|
| Posted: Tue Oct 15, 2013 9:37 pm Post subject: |
|
|
| SemmZemm wrote: | | I just want to understand why ^C doesn't work like before and to get back possiblity kill processes in the terminal like I'm used to do it. |
I might be wrong, but my suspicion is that your terminal line settings are f***ed-up. Diagnosing any such issues, however, is straightforward and works as follows: | Code: | $ stty -a
speed 38400 baud; rows 43; columns 132; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke |
The interesting part is the first value in the second line assigned to the intr attribute - which in my example reads ^C and thus translates to Ctrl-C. My assumption is that this value is most likely different in your case.
The good news is that the value assigned to intr is configurable and can easily be changed to another value. An example would be
which results in changing the current value (Ctrl-C in my first example above) to Ctrl-K. After this Ctrl-C would no longer send the signal SIGINT (that's what intr actually does) but rather Ctrl-K would send SIGINT to the current foreground process (and thus terminate this process [that is: unless SIGINT is handled or ignored by the process]). The changed value for intr can now easily be checked again as follows: | Code: | $ stty -a
speed 38400 baud; rows 43; columns 132; line = 0;
intr = ^K; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke |
The name intr by the way clearly resembles a link to the corresponding signal SIGINT.
Reasonable default values (including resetting the value of intr to Ctrl-C) are available by issuing or, in case you just want to reset intr to Ctrl-C, you could also type |
|
| Back to top |
|
|
SemmZemm
n00b
Joined: 05 Jul 2013
Posts: 62
Location: France, Russia
|
| Posted: Tue Oct 15, 2013 10:49 pm Post subject: |
|
|
It was ^C for me. I tried to change it to ^K but demonstrates the same behaviour.
But anyway, thank you for the try, Atom2 |
|
| Back to top |
|
|
paulj
Guru
Joined: 30 Sep 2004
Posts: 513
Location: Wales, UK
|
| Posted: Wed Oct 16, 2013 5:01 am Post subject: |
|
|
This might sound strange - I had this problem, and came across a post about nvidia-drivers causing this problem (written in 2009). Anyway, I downgraded to the stable version of nvidia-drivers, and the problem disappeared. I am busy sorting another issue on my system at the moment, and then I plan to go back and confirm if this problem is indeed related to nvidia-drivers.
I can't be sure yet, so normally I wouldn't post anything in the forums, but as you have the same problem, it might be worth a try if you have unstable nvidia-drivers installed.
I was on 331.13, and now I am back on 319.49. |
|
| Back to top |
|
|
SemmZemm
n00b
Joined: 05 Jul 2013
Posts: 62
Location: France, Russia
|
| Posted: Wed Oct 16, 2013 8:55 am Post subject: |
|
|
| paulj wrote: | This might sound strange - I had this problem, and came across a post about nvidia-drivers causing this problem (written in 2009). Anyway, I downgraded to the stable version of nvidia-drivers, and the problem disappeared. I am busy sorting another issue on my system at the moment, and then I plan to go back and confirm if this problem is indeed related to nvidia-drivers.
I can't be sure yet, so normally I wouldn't post anything in the forums, but as you have the same problem, it might be worth a try if you have unstable nvidia-drivers installed.
I was on 331.13, and now I am back on 319.49. |
Amazing! It works fine with 319.49. Thanks a lot! |
|
| Back to top |
|
|
paulj
Guru
Joined: 30 Sep 2004
Posts: 513
Location: Wales, UK
|
| Posted: Wed Oct 16, 2013 10:43 am Post subject: |
|
|
| Glad to have been able to help. I'll narrow down the issue then post a bug (although I suspect it should go upstream). |
|
| Back to top |
|
|
SemmZemm
n00b
Joined: 05 Jul 2013
Posts: 62
Location: France, Russia
|
| Posted: Wed Oct 16, 2013 12:10 pm Post subject: |
|
|
| paulj wrote: | | Glad to have been able to help. I'll narrow down the issue then post a bug (although I suspect it should go upstream). |
I'm not sure I should report the bug, because I have 3.11.4 kernel and I compiled drivers with 3rd part patch.
During the installation I'm prevented to not do a report if I have kernel version >=3.11 |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)
|
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21631
|
| Posted: Sun Oct 20, 2013 8:30 pm Post subject: |
|
|
| There are multiple upstream projects here. If you can reproduce the problem with an untainted kernel, you could report it to the kernel maintainers. If it happens only when you load the proprietary nVidia module, then you need to bug nVidia to fix their driver. |
|
| Back to top |
|
|
Josef.95
Advocate
Joined: 03 Sep 2007
Posts: 4553
Location: Germany
|
| Posted: Mon Oct 21, 2013 1:07 am Post subject: |
|
|
| Sounds like Bug 487700 |
|
| Back to top |
|
|
SemmZemm
n00b
Joined: 05 Jul 2013
Posts: 62
Location: France, Russia
|
|
| Back to top |
|
|
|
Portage & Programming
