Re: SOLVED: Slow Linux response during disk operations (was: Testingon various computers needed)
On Mon, 16 Jun 2003, Yedidyah Bar-David wrote: Sorry for not reading it (apparently wasn't here, maybe hackers-il, but google doesn't find it), but what I usually do is kill -STOP all of them, and only then kill -SOMETHINGTERMINAL. Unless the user intended to abuse the system, and wrote a signal handler for STOP, it would work well (and does in practice, with all the OS course students I have here). a user cannot write a signal handler for the 'STOP' signal. this one, and the 'KILL' signal, are un-stopable in a user application. by the way, you forgot to mention that you kill -STOP the process group, rather then the processes directly one by one. i still remember the note regarding this that you (or someone else?) placed in bar ilan university's terminals farm, some 10+ years ago ;) -- guy For world domination - press 1, or dial 0, and please hold, for the creator. -- nob o. dy = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: SOLVED: Slow Linux response during disk operations (was: Testingon various computers needed)
Nadav Har'El wrote on 2003-06-16: Indeed it was hackers-il. See my original message in http://groups.yahoo.com/group/hackers-il/message/2181 which shows a really nasty fork bomb in 12 bytes of shell code. Hmm, nasty indeed :-( and an antidote in http://groups.yahoo.com/group/hackers-il/message/2187 Elegant! (please read the last message before you run anything in the first!! Too late :-( and don't run any of those things on a public machine!!) Don't worry, it's my personal machine at home ;-). (and for the nitpickers, a few corrections:) http://groups.yahoo.com/group/hackers-il/message/2184 http://groups.yahoo.com/group/hackers-il/message/2183 As I explained there, the problem is that if you accidentally run this fork-bomb yourself (involving 12 bytes of shell script!) it's hard, or nearly impossible, to kill it (with -STOP or anything else) without killing all your other processes in the meantime. Some people might not find that a problem, but I do (I typically stay logged in, with dozens of open windows, for weeks. I sometimes consider logging out almost as bad as rebooting :)). Indeed, I counldn't (== wasn't patient enough to) get a shell. SSH from adjacent machine times out. (Is there a way to give SSH high priority so that it can be used if the system is otherwise stuck?) Ctrl-Alt-Backspace had its effect after a few minutes... -- Beni Cherniavsky [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: SOLVED: Slow Linux response during disk operations (was: Testingon various computers needed)
On Sun, Jun 15, 2003 at 12:06:01PM +0200, Eli Billauer wrote: Hello All. Bottom line: If you haven't done it yet, become root on your computer and go: hdparm /dev/hda or whatever hdX you have as your hard disk. and (at least on redhat) take a look at /etc/sysconfig/harddisks , to avoid re-running it manually. -- Tzafrir Cohen +---+ http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend| mailto:[EMAIL PROTECTED] +---+ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: SOLVED: Slow Linux response during disk operations (was: Testingon various computers needed)
if he was running it manually they it wouldn't have mattered;) Ely Levy System group Hebrew University Jerusalem Israel On Sun, 15 Jun 2003, Tzafrir Cohen wrote: On Sun, Jun 15, 2003 at 12:06:01PM +0200, Eli Billauer wrote: Hello All. Bottom line: If you haven't done it yet, become root on your computer and go: hdparm /dev/hda or whatever hdX you have as your hard disk. and (at least on redhat) take a look at /etc/sysconfig/harddisks , to avoid re-running it manually. -- Tzafrir Cohen +---+ http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend| mailto:[EMAIL PROTECTED] +---+ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: SOLVED: Slow Linux response during disk operations (was: Testingon various computers needed)
On Sun, 15 Jun 2003, Tzafrir Cohen wrote: and (at least on redhat) take a look at /etc/sysconfig/harddisks , to avoid re-running it manually. Don't enable DMA using hdparm on 865/875 Intel chipsets when using the SATALink buses, the drives stop responding and the system hangs. --Ariel -- Tzafrir Cohen +---+ http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend| mailto:[EMAIL PROTECTED] +---+ = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED] -- Ariel Biener e-mail: [EMAIL PROTECTED] PGP(6.5.8) public key http://www.tau.ac.il/~ariel/pgp.html = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: SOLVED: Slow Linux response during disk operations (was: Testingon various computers needed)
On my system (RedHat 9): $ cat /proc/version Linux version 2.4.20-8 ([EMAIL PROTECTED]) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Thu Mar 13 17:54:28 EST 2003 # hdparm -d /dev/hda /dev/hda: using_dma= 1 (on) When I did ``cat /dev/zero junk``, the system did become half-irresponsive (not critically). Since DMA is already on, is there any point in upgrading the kernel? Another question: fork bombs. I think this was much worse a few years ago but still, when I do:: perl -e 'for $i (1..15) { fork(); }' the system gets completely stuck for a few seconds. Increasing the number increases the stuck time. Isn't a unix suppossed to protect users from such DOS attacks in some way (just checked, executing it from another user has exactly the same effect)? Perhaps it does: curiously enough, after doing this a dozen times, it seems that linux has learnt the trick: I can now fork 2^20 times with no effect! Can someone enlighten me what goes on? -- Beni Cherniavsky [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: SOLVED: Slow Linux response during disk operations (was: Testingon various computers needed)
Muli Ben-Yehuda wrote on 2003-06-15: On Sun, Jun 15, 2003 at 09:01:07PM +0300, Beni Cherniavsky wrote: the system gets completely stuck for a few seconds. Increasing the number increases the stuck time. Isn't a unix suppossed to protect users from such DOS attacks in some way (just checked, executing it from another user has exactly the same effect)? man bash, see ulimit. Yes (and info libc has all the details) -- but these are cruel. I don't want forbid hogging resources, I just want to make it unobtrusive to other users/processes. Actually the limit on physical memory size comes pretty close to this requirement. Perhaps it does: curiously enough, after doing this a dozen times, it seems that linux has learnt the trick: I can now fork 2^20 times with no effect! Can someone enlighten me what goes on? Two things most likely. The first is cache effects - the task structs are cached in the slab cache (so allocating and deallocating new task structs incur very little run time overhead), and the the relevant code paths and data are all in the CPU's cache. The second is the scheduler kicking in, and classifying the shell and / or the perl process as a CPU hog, and therefore lowering its dynamic priority. Hard to be more specific without profiling. Whatever it does, it seems to work rather well. I'm wiser and happier now :-). -- Beni Cherniavsky [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
Re: SOLVED: Slow Linux response during disk operations (was: Testingon various computers needed)
Nadav Har'El wrote on 2003-06-15: On Sun, Jun 15, 2003, Beni Cherniavsky wrote about Re: SOLVED: Slow Linux response during disk operations (was: Testing on various computers needed): Perhaps it does: curiously enough, after doing this a dozen times, it seems that linux has learnt the trick: I can now fork 2^20 times with no effect! Can someone enlighten me what goes on? Perhaps all your background stuff (servers, etc.) were swapped out (making your system stuck for a few seconds) and they never came back, so the next run of fork loop had enough memory to run. Remember that your number of processes *is* limited by default, so you'll never get 2^20 processes with the above trick - just your limit. 2047 on my RH9. I tried:: perl -e 'for $i (1..20) { fork() = 0 || die failed; } sleep(2)' (the sleep there to keep the processes around) but don't get any messages. The process limit is supposed to make fork() fail, isn't it? Anyway, I don't know if that's what happened to you - it's just a guess. -- Beni Cherniavsky [EMAIL PROTECTED] = To unsubscribe, send mail to [EMAIL PROTECTED] with the word unsubscribe in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]