Date: Fri, 16 Jul 1999 14:00:16 +0300 (EDT) From: "Valentin Nechayev" <nx@nn.kiev.ua> To: freebsd-hackers@freebsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <AD03nZt4a4@nn.kiev.ua> References: <378DF141.393ECB36@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Daniel C. Sobral wrote: > Eh? Reasonable programs *never* run into trouble. Trouble only > happens when you have unreasonable programs around, or did not > configure the system correctly. And if you did not configure the > system correctly, why do you think you would be able to correctly > estimate the stack needed for the various programs? Your words are bad words. Exhausting of any of main resources - virtual memory, disk space, process descriptors, file descriptors - is a terrible situation, but one must not fight against headache with headcutting. Every system can fall in uncontrolled state and eat all of some resource, and kernel stack is to prevent process pool part from this, not to destruct it. I had seen two boxes where swap was out misfortunately with bad results: on first (FreeBSD 2.2.7), system kills the cron (sic!) process, on second (Linux) syslogd, sendmail and some others became poisoned without any warnings. It is totally bad behavior; kernel must be friend, not enemy. Actions supposed enough by me for first (!) time: 1) Count in some kernel variables (readable by sysctl) overflows of virtual memory, file descriptors, process descriptors and other critical resources. This data must be available for watchdogs; for some systems, it is right to reboot them immediately after some overflow, not to try to work in poisoned state. 2) Run (in standard setup!) cron, syslogd and other important daemons from special init slot (as Linux and possibly other systems allow), not from startup scripts. Reason: they must be restarted when die without admin intervention and without wrappers which can also be killed on memory low. 3) Declare thresholds for critical resources; for example, when more than 80% of virtual memory is used, prevent everybody except euid==0 or egid==0 from allocating new memory. 4) Provide special signal (SIGXMEM?) to send messages that there is memory low and all have to shorten their memory. Daemons should interpret this signal similarly to SIGHUP, with exec() itself and restart. > Now comes the people saying "don't overcommit in *this* case, and > overcommit in *that* case". Irrelevant. Programs are still getting > killed because memory was overcommitted (with the added disadvantage > of you not having as much memory as in a full overcommit mode). Kernel can kill processes that try to get unexistent memory. But when it did not prevent system from falling into overflow, it plays unfair game. -- Netch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AD03nZt4a4>