Bug 33351 - zip run as root can lock system, when making a large archive
zip run as root can lock system, when making a large archive
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: zip (Show other bugs)
7.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-26 22:26 EST by Olen
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-28 23:31:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Olen 2001-03-26 22:26:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.16-22 i586)


I was going to make a zip archive of /usr ( about 1.2 gig of data) as
a backup before placing on a cd.   However this cause the kernel to kill
all other processes to give memory to zip, eventually the system was locked
up. the -R option was used to recurse the subdirectories.
This may be a kernel bug as well.

Reproducible: Always
Steps to Reproduce:
1. use zip to make archive of /usr 
2.
3.
	

Actual Results:  Mar 26 20:10:00 spacewalker CROND[1112]: (root) CMD (  
/sbin/rmmod -as)
Mar 26 20:18:16 spacewalker kernel: VM: killing process magicdev
Mar 26 20:18:17 spacewalker kernel: VM: killing process gnome-session
Mar 26 20:18:17 spacewalker kernel: VM: killing process panel
Mar 26 20:18:22 spacewalker kernel: VM: killing process deskguide_apple
Mar 26 20:18:26 spacewalker kernel: VM: killing process sawfish
Mar 26 20:18:31 spacewalker kernel: VM: killing process gmc
Mar 26 20:18:44 spacewalker kernel: VM: killing process tasklist_applet
Mar 26 20:18:44 spacewalker kernel: VM: killing process gnome-name-serv
Mar 26 20:18:44 spacewalker kernel: VM: killing process automount
Mar 26 20:18:44 spacewalker kernel: VM: killing process gnome-smproxy
Mar 26 20:18:44 spacewalker kernel: VM: killing process mixer_applet
Mar 26 20:18:47 spacewalker PAM_unix[638]: (gdm) session closed for user
boydstun

Then the system locked up.  No virtual consoles were available after a
while.  


Expected Results:  I think I should have gotten an archive that I could
save on a cdrom

see actual results field for excerpt from my syslog.
Comment 1 Mike A. Harris 2001-03-26 22:51:39 EST
This is not a bug.  On any Linux system, if you run any command which uses
massive amounts of memory performing its duty, it can potentially exhaust
all memory in the system.  At this point the kernel's VM OOM killer will
kick in and kill processes in an attempt to reclaim some VM.

If you do not want this to happen, you need to add more VM to the machine
either by adding more physical memory to the box, or by adding more swap
space, or some combination of both.  If you are running a 2.4.x kernel
at all, your swap space _MUST_ be twice the size of RAM for proper operation.

If you want to prevent things like this from tripping the kernel OOM (out
of memory) killer, then do not run applications that will cause OOM to occur,
or else use resource limits to limit what resources a program can use.  For
details:  "man ulimit"

Comment 2 Olen 2001-03-28 23:31:52 EST
Shouldn't a malloc fail at some point, before the system locks up, or VM OOPS
kicks in?  
Seems like the documentation for zip should mention that it has no control
over taking too many resources.  I don't see it documented in the man page.
Now it is at least mentioned on the web so administrators may find out the
problem before they crash their servers.

maybe you could give it a command line arguement to let the user specify the
maximum percent of memory to use?

Comment 3 Mike A. Harris 2001-03-29 11:28:37 EST
No, I repeat this is not a bug in zip.  It is a fundamental design *feature*
of Linux and all other UNIX and UNIX like systems.  It is called memory
overcommit, and is completely intentional.  It does not have anything to
do with the zip program.  The proper solution is to either use resource
limitations of the shell (man ulimit) or to disable memory overcommit.
If you do the latter, you'll not be very impressed by the performance of
your systems any longer as they'll be running at 1970's speeds.

This is all I have to say on this issue.  If you'd like the hows and whys,
etc, please take it up on the linux-kernel@vger.kernel.org mailing list,
as it isn't very appropriate here.  Sorry I can't recommend anything more
than that, but this "problem" is rarer than you think, and solved using the
tools that were designed to do so.

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