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.
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"
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?
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.