Bug 7972 - cp or tar uses up all available memory, then swap, then kernel panic
Summary: cp or tar uses up all available memory, then swap, then kernel panic
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tar
Version: 6.1
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-12-23 17:37 UTC by Michael Fryman
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-01-05 19:27:04 UTC


Attachments (Terms of Use)

Description Michael Fryman 1999-12-23 17:37:48 UTC
After a plain vanilla install of RedHat Linux 6.1 on at least 3 different
Intel platforms with various hardware, memory and processor differences,
any cp or tar command will keep grabbing more and more memory, until the
system has to swap, and then use all the swap space, and then results in a
kernel panic.

Furthermore, if we try to kill the cp or tar process, the memory and
buffers are never released.  Even flushing the buffers doesn't release the
memory.

This is a critical problem preventing the rollout of 9 Linux systems to a
large new customer.  Please help asap.

Comment 1 Riley H Williams 1999-12-23 21:03:59 UTC
I'm not sure what the problem is in your case, but I regularly use both cp and
tar to manipulate files, including on "plain vanilla" 6.1 installs (I did one of
those yesterday, then used tar to extract an additional package only supplied in
tar.gz format into it as well) and have never had any problems with it.

I would suspect that more information will be required to track down whatever
your problem is, as there's precious little in your report...

Comment 2 Bernhard Rosenkraenzer 2000-01-05 17:32:59 UTC
We've tried to reproduce this on a number of systems, without seeing the same
problem anywhere.
Please give us some details about the computers you used, and make sure you're
installing from a working CD/server.

Comment 3 Michael Fryman 2000-01-05 19:23:59 UTC
Here is the initial problem description by the customer for this issue:
===================
1.  We have a dual PIII 450 system.
2.  We have a raid attached to it. It's a riad5. We also have an 18gig hard
disk in it. The raid holds our user drive space and the 18gig disk holds our
customers' email.
3. Here is the command that I used to tar/zip to our tape drive which caused a
kernel panic because it ran out of mem the went to swap and ran out of that.
	tar -zcvf /dev/tape /u01
4. Here is the command that I used to copy from /u01 to an nfs mount.
	a. First I used the cpbk util:  cpbk -r spool /mail  --- spool being
the mail dir and /mail being an nfs mount. I then used just plain old
cp and I go the same result. In the case of using copy I stopped the
copy as soon as I saw that I was swapping heavily.  I ran a similar
copy using tar going from spool to the nfs mount /mail.

I have researched the problem and found that others have had same and
similar problems as far back as 2.0.29. I did do a test using SuSe
with kernel 2.2.10 and was not able to fully dup the problem. I loaded
the OS on the same type of machine as we have in Irvine and the
machine has 512MB or ram. I started several tar's and flood pings to
local host and I created a script that would run a disk intensive find
over and over. When I first started I had 288MB+ free and got it down
to about 3+ megs free. It never swapped and it appeared to use what
was cached and buffered and the mem stabalized around 11+megs. I ran
this test 4 times and did not have any problems using the SuSe 2.2.10
kernel.

Comment 4 Michael Fryman 2000-01-05 19:27:59 UTC
Sorry, but the customer has figured out their problem, somewhat.  When this
problem was finally discussed in detail with their own developers, the problem
suddenly went away.  When asked, the developers said they had been tweaking
several things, including the IMAP config files.
I don't have any more information than that at the moment, but this can
certainly be closed.


Note You need to log in before you can comment on or make changes to this bug.