All those mother fucking 100% cpu daemons...

[Duncan]

Maxime Haselbauer posted on Thu, 15 May 2014 22:16:48 +0200 as excerpted:


> I am using kde since 2010 There has been continuously a problem with a
> given component of KDE that I won't even mentionn it but basically the
> problem is like that:
> 1)you work 2)and suddenly a programm starts to rev-up at 100% cpu  and
> your computer does not respond anymore until you press the shutdown
> button
> 
> My questions:
> 1) Is it currently possible to have like an "emegency" button so that
> when this happen you would press on it, it would freeze everything and
> head you back to a terminal immediatly where you can kill those mother
> fuckers Basically it would be like ctrl+alt+f1 but ctrl+alt+f1 does not
> respond as well when something is running at 100% cpu...

First, please tone down your language a bit.  It's quite possible there 
are kids or other sensitive folks subscribed, and it's also quite 
possible to express frustration using the traditional YELLING and 
*YELLING* *EVEN* *LOUDER* methods without such language.  Or if you 
/really/ feel the need, use "comic swearing": *#@#_%.  It gets the 
message across. =8^0

Meanwhile...

As vgobbo says, try the "magic sys-request" sequences.  But here's a bit 
more detail and additional sequence suggestions:

Wikipedia on SysRQ: https://en.wikipedia.org/wiki/System_request

Quote of interest:

>> On the later [x86] 101-key keyboard, it shares a physical key with the
>> Print Screen key function. One must hold down the Alt key while
>> pressing this “dual-function” key to invoke SysRq.

Thus the alt-srq sequence.  To that, a third key is added, depending on 
the desired action.

Wikipedia on the Linux-specific ' "Magic SysRq key":

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

The kernel's own magic-srq document can be found at
$KERNDIR/Documentation/sysrq.txt (where $KERNDIR is /usr/src/linux or 
wherever else you or your distro places your kernel sources directory).


Assuming magic-srq is enabled (or enable-able) on your distro, the most 
common use, as the above page explains, is REISUB (assuming QWERTY 
keyboard layout, there's a table on the wiki page for other common 
layouts), to effect a safer emergency reboot, when nothing else seems to 
work.  Additionally, how far you have to go in that sequence before you 
get any indication that it's helping is a good indication of how horribly 
locked up the system actually was/is.  If the RE gets a response, it 
wasn't too bad.  OTOH, if you get all the way to the B before anything 
(including drive activity indication) happens, the kernel was corrupted 
badly enough that it feared it couldn't safely even write to storage to 
sync and remount-read-only, which means things were pretty bad, and if 
even the B doesn't respond, then the kernel itself was locked up, to the 
point it couldn't even see or process the unconditional reboot directive.

REISUB:

unRaw	-	Turn off X's raw keyboard mode
tErm	-	Terminate all processes that will terminate gracefully
kIll	-	Force-kill all remaining processes
Sync	-	Flush all unwritten data to storage (disk/SSD)
remoUnt	-	Remount all filesystems read-only
reBoot	-	Unconditional immediate reboot

Note that unlike the other keys in the REISUB sequence, alt-srq-s (sync) 
by itself is generally safe at any time and can be used to force-flush 
unwritten data to disk before an operation you think might crash the 
computer.  You can then continue as if nothing happened, and/or 
repeatedly hit alt-srq-s in ordered to repeatedly sync an ongoing 
operation.  I use it that way myself from time to time.


Meanwhile, of particular interest for this thread is another magic-srq 
key, the K/saK/Secure-access-key, alt-srq-k.  This key kills any process 
listening on the current virtual terminal along with all its children.  
As a result, it can be used to force-kill an unresponsive X, if 
necessary.  It may or may not return you to a shell prompt (tho if it 
doesn't, sometimes using the alt-srq-r/unraw, followed by the usual ctrl-
alt-Fn sequence, to switch to a different VT, can sometimes help).

This is what I might well try if I found myself in the situation you 
describe, since 100% CPU will very likely still respond to magic-srq, and 
the alt-srq-k combo has a good chance of killing X and either letting it 
respawn (if you use a *DM graphical login) or getting you back a text 
login (if as me you login at a text terminal and run startx to start kde).

The above references should get you started if you're interested in more, 
and of course a google on "magic sysrequest" and variants should turn up 
a wealth of community commentary as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.