Re: [suse-security] Reasons for a system to freeze?
Hello... Just thought I'd add my $0.02 worth in... I *always* run netscape from a script which uses ulimit to set the amount of memory it can get. If I don't, it sometimes sucks the life out of the machine in similar ways by using all memory. With it ulimitted, it dies after a while (when it can't get any more memory), but my system still lives on. I've been doing this for serveral years. -Nick
While this might not be a security related problem I'd appreciate any hints/tips/advice from the experts here.
Did you test to open the mail again after the reboot? maybe its some mad code in it? Netscape also has many memleaks .. maybe you've just read the mail on the wrong day for netscape ;) i would check the mail for some mad code. did you see the load of the maschine?
I tried opening the mail (cautiously) and it worked fine ... hmmm. It's a php-general-list-digest, so it does contain code snippets.
I was not able to see the machine load. I tried top, but the command did not produce any output. This was about the same time, my ssh died.
-- Get your free email from www.linuxmail.org Powered by Outblaze
I would like to see your script. It sounds useful. Perhaps even more than $0.02 worth. On Fri, Apr 20, 2001 at 07:42:32PM +0600, Nick LeRoy wrote:
Hello...
Just thought I'd add my $0.02 worth in...
I *always* run netscape from a script which uses ulimit to set the amount of memory it can get. If I don't, it sometimes sucks the life out of the machine in similar ways by using all memory. With it ulimitted, it dies after a while (when it can't get any more memory), but my system still lives on. I've been doing this for serveral years.
-Nick
While this might not be a security related problem I'd appreciate any hints/tips/advice from the experts here.
Did you test to open the mail again after the reboot? maybe its some mad code in it? Netscape also has many memleaks .. maybe you've just read the mail on the wrong day for netscape ;) i would check the mail for some mad code. did you see the load of the maschine?
I tried opening the mail (cautiously) and it worked fine ... hmmm. It's a php-general-list-digest, so it does contain code snippets.
I was not able to see the machine load. I tried top, but the command did not produce any output. This was about the same time, my ssh died.
--
Get your free email from www.linuxmail.org
Powered by Outblaze
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
-- -ashley One of these days I'm going to completely organize my life.
On Sun, 22 Apr 2001, Ashley wrote:
I would like to see your script. It sounds useful. Perhaps even more than $0.02 worth.
On Fri, Apr 20, 2001 at 07:42:32PM +0600, Nick LeRoy wrote:
Hello...
Just thought I'd add my $0.02 worth in...
I *always* run netscape from a script which uses ulimit to set the amount of memory it can get. If I don't, it sometimes sucks the life out of the machine in similar ways by using all memory. With it ulimitted, it dies after a while (when it can't get any more memory), but my system still lives on. I've been doing this for serveral years.
Hello, I would like to know, if this is Linux specific, or am I able to crash (or freeze) any Unix (Solaris for example) just by eating a lot of memory? Where does this problem come from? When a programm calls a malloc (or something like that), I think the system should return an error, if there is not enough memory. It seems that Linux does *not* return an error (or only too late). Am I right or wrong? Regards, Peter -- Peter Münster http://notrix.net/pm-vcard
: On Sun, 22 Apr 2001 18:39:23 +0200 (CEST), Peter Münster wrote:
I would like to know, if this is Linux specific, or am I able to crash (or freeze) any Unix (Solaris for example) just by eating a lot of memory?
"Unprotected" systems will at least suffer from DOS attacks.
Where does this problem come from?
Lack of ulimit'ing.
When a programm calls a malloc (or something like that), I think the system should return an error, if there is not enough memory.
When is "not enough memory" really "not enough memory"? If you fork an application with a code size of 5 MB a hundred times - do you need 5 MB of "memory", or do you need 500 MB? Well, Linux thinks that in the above scenario 5 MB of memory are perfectly sufficient, even if your system only provides a total amount of virtual memory of 100 MB. IOW, Linux overcommits on the amount of memory it actually has - it will give you an infinite amount of memory (relatively speaking :->) while it only has a fixed amount of backing virtual memory at its disposal.
It seems that Linux does *not* return an error (or only too late).
Current released kernels (AFAIK) will always overcommit. If a situation arises where more virtual memory is required than the system can deliver, a process is being killed ("OOM killer"). I believe that recently an experimental patch has been published that will allow turning off of overcommitting. I, for one, would immediately turn overcommitting off, if it finds its way into the kernel.
Hi, pardon me for jumping in ;-), but I have had an own experience regarding exhausted memory with kernel 2.4.3. I hope that this is not OT, it's not regarding access-security, but reliability. My private box is Suse 7.1 with kernel 2.4.3, 128 MB RAM, 64 MB swap (this may be odd, but anyway, normally it works). I ran a recent version of a WAV Editor (The Art of Noise) to edit a 70MB WAV File. In the first instance it ran smooth, but when I opend a second instance it consumed all RAM while loading the WAV, then also all swapspace, and when the overcommitment was takting effect and all VM was exhausted, the box was fully unusable, constantly swapping, paging and so on, nearly frozen (besides heavy diskactivity). I had to switch it off. No sign of an OOM-Killer. I do not use any ulimits (maybe I have to establish it). In my opinion not a reliable allocation scheme for an OS used to run a server, only for a workstation where such behaviour could be easily tolerated. Only my personal opinion, no public flamewars please ;-) My 2 cents. Stefan Hoffmeister wrote:
: On Sun, 22 Apr 2001 18:39:23 +0200 (CEST), Peter Münster wrote:
I would like to know, if this is Linux specific, or am I able to crash (or freeze) any Unix (Solaris for example) just by eating a lot of memory?
"Unprotected" systems will at least suffer from DOS attacks.
Where does this problem come from?
Lack of ulimit'ing.
When a programm calls a malloc (or something like that), I think the system should return an error, if there is not enough memory.
When is "not enough memory" really "not enough memory"? If you fork an application with a code size of 5 MB a hundred times - do you need 5 MB of "memory", or do you need 500 MB?
Well, Linux thinks that in the above scenario 5 MB of memory are perfectly sufficient, even if your system only provides a total amount of virtual memory of 100 MB.
IOW, Linux overcommits on the amount of memory it actually has - it will give you an infinite amount of memory (relatively speaking :->) while it only has a fixed amount of backing virtual memory at its disposal.
It seems that Linux does *not* return an error (or only too late).
Current released kernels (AFAIK) will always overcommit. If a situation arises where more virtual memory is required than the system can deliver, a process is being killed ("OOM killer").
I believe that recently an experimental patch has been published that will allow turning off of overcommitting. I, for one, would immediately turn overcommitting off, if it finds its way into the kernel.
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
Pardon, the first reply was signed :-( --------------- Hi, pardon me for jumping in ;-), but I have had an own experience regarding exhausted memory with kernel 2.4.3. I hope that this is not OT, it's not regarding access-security, but reliability. My private box is Suse 7.1 with kernel 2.4.3, 128 MB RAM, 64 MB swap (this may be odd, but anyway, normally it works). I ran a recent version of a WAV Editor (The Art of Noise) to edit a 70MB WAV File. In the first instance it ran smooth, but when I opend a second instance it consumed all RAM while loading the WAV, then also all swapspace, and when the overcommitment was takting effect and all VM was exhausted, the box was fully unusable, constantly swapping, paging and so on, nearly frozen (besides heavy diskactivity). I had to switch it off. No sign of an OOM-Killer. I do not use any ulimits (maybe I have to establish it). In my opinion not a reliable allocation scheme for an OS used to run a server, only for a workstation where such behaviour could be easily tolerated. Only my personal opinion, no public flamewars please ;-) My 2 cents. Stefan Hoffmeister wrote:
: On Sun, 22 Apr 2001 18:39:23 +0200 (CEST), Peter Münster wrote:
I would like to know, if this is Linux specific, or am I able to crash (or freeze) any Unix (Solaris for example) just by eating a lot of memory?
"Unprotected" systems will at least suffer from DOS attacks.
Where does this problem come from?
Lack of ulimit'ing.
When a programm calls a malloc (or something like that), I think the system should return an error, if there is not enough memory.
When is "not enough memory" really "not enough memory"? If you fork an application with a code size of 5 MB a hundred times - do you need 5 MB of "memory", or do you need 500 MB?
Well, Linux thinks that in the above scenario 5 MB of memory are perfectly sufficient, even if your system only provides a total amount of virtual memory of 100 MB.
IOW, Linux overcommits on the amount of memory it actually has - it will give you an infinite amount of memory (relatively speaking :->) while it only has a fixed amount of backing virtual memory at its disposal.
It seems that Linux does *not* return an error (or only too late).
Current released kernels (AFAIK) will always overcommit. If a situation arises where more virtual memory is required than the system can deliver, a process is being killed ("OOM killer").
I believe that recently an experimental patch has been published that will allow turning off of overcommitting. I, for one, would immediately turn overcommitting off, if it finds its way into the kernel.
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
[ OT for -security, merely for the record and the interested ] On Sun, Apr 22, 2001 at 20:46 +0200, Stefan Hoffmeister wrote:
When is "not enough memory" really "not enough memory"? If you fork an application with a code size of 5 MB a hundred times - do you need 5 MB of "memory", or do you need 500 MB?
Get a book on UNIX memory management (like the ubiquitous "The design of the UNIX operating system") and look at the "shared text" and "copy on write" discussion. In short: text segments (i.e. code) are loaded only once and get shared among applications. stack and data segments get shared upon fork(2) but marked for "copy on write" (that's some kind of read only). As soon as there's a write operation an exception is triggered to have the data copied to the writing process before manipulation. This method doesn't make much sense in regards of stack segments, so they could be separate right from the start. So: everything equal between the processes is shared (existing only once in reality, referenced multiple times) and everything special to an application is kept separately. NB: sticky executables' segments are kept in RAM even after the exit(2) call which makes them easier available upon their next invocation. That's really useful for shells, xterm, etc. virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" Gerhard.Sittig@gmx.net -- If you don't understand or are scared by any of the above ask your parents or an adult to help you.
participants (6)
-
Ashley -
Gerd Bitzer -
Gerhard Sittig -
Nick LeRoy -
Peter Münster -
Stefan Hoffmeister