Re: Question about kill(1)
Goswin == Goswin von Brederlow [EMAIL PROTECTED] writes: Goswin Try ctrl/atl/shift + print/scroll/pause combinations on Goswin the console. Or alt+sysrq+h if thats enabled in your Goswin kernel. You get a process listing with one of the first Goswin and the second can do a lot more. Thanks for reminding me, I need to remember these keystrokes. How does it work? On my system, I push shift+ctrl+alt with my 1st hand, any two of print/scroll/pause with my 2nd hand. At this stage, I get a user friendly manual with showTasks as one my options. With my third hand I push the T button, and get what looks like a complete stack trace that overflows the dmesg buffer, let alone the screen. Oh wait, I can't do that, I just remembered I only have two hands... Maybe this has changed in the 2.6 kernels. I don't think it will work from X-Windows when the system is too bogged down to switch to a text console though... -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about kill(1)
I demand that Brian May may or may not have written... Goswin von Brederlow [EMAIL PROTECTED] writes: Try ctrl/atl/shift + print/scroll/pause combinations on the console. Or alt+sysrq+h if thats enabled in your kernel. You get a process listing with one of the first and the second can do a lot more. Thanks for reminding me, I need to remember these keystrokes. How does it work? On my system, I push shift+ctrl+alt with my 1st hand, any two of print/scroll/pause with my 2nd hand. At this stage, I get a user friendly manual with showTasks as one my options. I'd call it terse. ;-) With my third hand I push the T button, and get what looks like a complete stack trace that overflows the dmesg buffer, let alone the screen. Increase the buffer size and rebuild your kernel. ;-) Oh wait, I can't do that, I just remembered I only have two hands... Where's Mr Beeblebrox when you need him... Press Alt or AltGr, press SysRq (or Print or Stop or F13...), optionally release Alt (but definitely keep the other key pressed), press whichever key corresponds to what you want to do. (Details may vary according to architecture and/or keyboard. See linux/Documentation/sysrq.txt (kernel source) for more details.) Maybe this has changed in the 2.6 kernels. It's still the same. I don't think it will work from X-Windows when the system is too bogged down to switch to a text console though... You want Alt-SysRq-R (after which you should be able to switch to a text VT) or a serial or network console. -- | Darren Salt | nr. Ashington, | linux (or ds) at | sarge,| Northumberland | youmustbejoking | RISC OS | Toon Army | demon co uk Say NO to UK ID cards | http://www.no2id.net/ Your work is very poor, but at least it's slow. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about kill(1)
Adeodato == Adeodato Simó [EMAIL PROTECTED] writes: Adeodato I also have heard (but I'm not sure how often does this Adeodato happen, if at all) that it is usefult to have it as a Adeodato built-in when your system is in a state when it can't Adeodato create more processes. In practise whenever that happens, and if I am lucky enough to have a terminal open, and if I am not dumb enough to accidently close the window, I don't know what the PID is of that CPU hungry/memory hungry process is in order to kill it. This happened to me approx a week ago. I wanted to write a wrapper around subversion that set umask before calling subversion, but instead the wrapper recursively called itself. I thought subversion was just being slow. It never considered the possibility it was the reason my computer subsequently went very slowly until it was unusable. It took me two reboots of the computer before I finally realized the DOS attack was from *my* own script! It took me another reboot to fix the problem properly. Sometimes it pays to use the full pathname to the executable... -- Brian May [EMAIL PROTECTED]
Re: Question about kill(1)
Brian May [EMAIL PROTECTED] writes: Adeodato == Adeodato Simó [EMAIL PROTECTED] writes: Adeodato I also have heard (but I'm not sure how often does this Adeodato happen, if at all) that it is usefult to have it as a Adeodato built-in when your system is in a state when it can't Adeodato create more processes. In practise whenever that happens, and if I am lucky enough to have a terminal open, and if I am not dumb enough to accidently close the window, I don't know what the PID is of that CPU hungry/memory hungry process is in order to kill it. Try ctrl/atl/shift + print/scroll/pause combinations on the console. Or alt+sysrq+h if thats enabled in your kernel. You get a process listing with one of the first and the second can do a lot more. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about kill(1)
* Bob Proulx [Thu, 07 Jul 2005 21:24:07 -0600]: * why the different implementations? It is there for BSD job control functionality. That way you can say 'kill %1' and kill the background jobs by job control number. The standalone version does not know about the shell's list of jobs. I also have heard (but I'm not sure how often does this happen, if at all) that it is usefult to have it as a built-in when your system is in a state when it can't create more processes. -- Adeodato Simó EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621 The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- F. Nietzsche -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Question about kill(1)
On Thu, Jul 07, 2005 at 09:24:07PM -0600, Bob Proulx wrote: Roberto C. Sanchez wrote: I was reading the kill man page today looking for some information for a script I am writing. The man page mentioned that some shells have a kill built-in command. On further investigation, I noticed that bash has this as a built-in. My questions are: * should I explicitly call /bin/kill? No. Just call it 'kill' as you would normally. In general you should avoid hard coding paths like this unless you have a specific reason. And even then you should not use hard coded paths. :-) * is there any advantage to avoiding the built-in? No. The man page is pointing this out because when people go to report a bug in 'kill' they read man page and report it to procps or coreutils or wherever. The maintainer there says you are not using the standalone kill but rather the one in bash (or ash or ...) and so then you back up and report the bug to bug-bash. Now that you know there is a shell built-in version by reading it in the man page you can isolate the bug to the right package before submitting an inquiry on it to the wrong one. (This is usually my experience with kill, sleep, nice, test, etc. in coreutils. It is now one of the FAQs in coreutils[1].) * why the different implementations? It is there for BSD job control functionality. That way you can say 'kill %1' and kill the background jobs by job control number. The standalone version does not know about the shell's list of jobs. Bob [1] http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#I-am-having-a-problem-with-kill Thanks. That was very enlightening. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpjajC8TfpZ2.pgp Description: PGP signature
Re: Question about kill(1)
Adeodato Simó wrote: * Bob Proulx [Thu, 07 Jul 2005 21:24:07 -0600]: * why the different implementations? It is there for BSD job control functionality. That way you can say 'kill %1' and kill the background jobs by job control number. The standalone version does not know about the shell's list of jobs. I also have heard (but I'm not sure how often does this happen, if at all) that it is usefult to have it as a built-in when your system is in a state when it can't create more processes. The v7 shell did not have a built-in kill. But having it built-in as with later shells is certainly useful at times for the purpose you state. But the problem is finding the number of the process to kill. With /proc available to get process id numbers with 'echo /proc/*' which does not spawn a new process this is easier than in the old days from pstat*(2) and a standalone 'ps' process. Because without /proc and needing to run 'ps' to get a listing of processes if you had a full process table you could not run ps and could not find the process id to kill easily. Too many times I have seen cannot fork messages from the shell. But if you knew a process id that you could kill to gain a few more process slots then even in the v7 shell you had a way to kill it. The technique showed to me from an experienced unix hacker when I was learning this was 'exec kill -9 ##'. By using the running shell for the process you get one attempt for the command so better make it effective. :-) Bob signature.asc Description: Digital signature
Re: Question about kill(1)
Roberto C. Sanchez wrote: I was reading the kill man page today looking for some information for a script I am writing. The man page mentioned that some shells have a kill built-in command. On further investigation, I noticed that bash has this as a built-in. My questions are: * should I explicitly call /bin/kill? No. Just call it 'kill' as you would normally. In general you should avoid hard coding paths like this unless you have a specific reason. And even then you should not use hard coded paths. :-) * is there any advantage to avoiding the built-in? No. The man page is pointing this out because when people go to report a bug in 'kill' they read man page and report it to procps or coreutils or wherever. The maintainer there says you are not using the standalone kill but rather the one in bash (or ash or ...) and so then you back up and report the bug to bug-bash. Now that you know there is a shell built-in version by reading it in the man page you can isolate the bug to the right package before submitting an inquiry on it to the wrong one. (This is usually my experience with kill, sleep, nice, test, etc. in coreutils. It is now one of the FAQs in coreutils[1].) * why the different implementations? It is there for BSD job control functionality. That way you can say 'kill %1' and kill the background jobs by job control number. The standalone version does not know about the shell's list of jobs. Bob [1] http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#I-am-having-a-problem-with-kill signature.asc Description: Digital signature
