Bug 33351

Summary: zip run as root can lock system, when making a large archive
Product: [Retired] Red Hat Linux Reporter: Olen <olenb>
Component: zipAssignee: Mike A. Harris <mharris>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: medium    
Version: 7.0   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-03-29 04:31:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Olen 2001-03-27 03:26:42 UTC 
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-27 03:51:39 UTC 
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-29 04:31:52 UTC 
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 16:28:37 UTC 
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.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.