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]
SOLVED: Slow Linux response during disk operations (was: Testingon various computers needed)
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. You'll have a line saying using_dma = 1 (on). But if the line says that your DMA is off, I suggest start thinking about doing something about it (I *didn't* say turn it on right away). It's worth the effort. It's a HUGE difference. Now the long story: == You all owe me a great Mazal Tov. Two, as a matter of fact. The first is because after using Linux for five years, I compiled the kernel for the first time today. A 2.4.21, to be exact. And it seems to work like a charm. Actually, I enjoyed every minute of it. I needed a good excuse to get into it, and I had one. The second Mazal Tov is because 2.4.21 recognizes 845PE's IDE controller, and hence the DMA was automatically enabled. And voila, the system runs smoothly even when the disk is heavily used. And it's running much faster. As a matter of fact, everything feels faster now. It's really like a different computer. Aftermath: = The really bothering thing about this is the impression that other people may get of Linux, as a heavy OS. You may not have liked my tone about all this, but it's still much better than you'll get from those that we're trying to convince using Linux. Five years of Linux is enough to stick to it, despite a complaint here and there. What are newbies thinking when their GUI freezes as they untar something large? Anyhow, I've filed a report to bugzilla at Red Hat (enhancement), recommending to issue a warning during installation when the DMA is off. Yes, some of you told me to upgrade the kernel in the first place, but I'm always told to upgarde the kernel when something doesn't work well. And until now (five years), playing with the kernel has turned out unnecessary. Some of you like to play with the kernel, and I may start to like it myself, but with a linmodem whose drivers were a bit nasty to compile last time, I had all reasons not to jump to that solution before being convinced it might do something. Neither was I too happy with fiddling with hdparm, to be very honest. Forcing DMA on a drive which didn't get that naturally, sounded scary to me. A disk crash is not what I needed right now. But in the end, that kind of direct fiddling wasn't needed either. It was only after I ran those speed tests, that it occured to me that Ilya had the best lead: Windows was both faster and smoother, so maybe the DMA *was* the thing. So thanks, Ilya. Only when I tried to enable the DMA, and hdparm refused, did I realize that the IDE controller wasn't recognized (it was by googling the error message I got from hdparm). That's when upgrading the kernel finally made sense. As a final remark -- you may not have liked my tone throughout this thread. And it's true that I wouldn't have sounded like this, if Windows did the same tricks, simply because I don't expect much from an MS-based system. But when Linux pulls tricks on me, I feel betrayed. Now, when the problem is fixed, I also realize that I had very good reasons to be annoyed. And I think this whole IDE thing should have been handled better by the system. All I needed was a descriptive warning, not a side comment in /var/log/dmesg. Let's hope at least Red Hat will do something with my report. Regards, Eli = 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]
