From owner-freebsd-hackers Fri Jul 16 4: 6:37 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from kozlik.carrier.kiev.ua (kozlik.carrier.kiev.ua [193.193.193.111]) by hub.freebsd.org (Postfix) with ESMTP id E4D7414C3E for ; Fri, 16 Jul 1999 04:06:27 -0700 (PDT) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (8.The.Best/UUCP_FOREVER) with UUCP id OAA17170 for freebsd-hackers@freebsd.org; Fri, 16 Jul 1999 14:05:49 +0300 (EEST) (envelope-from nx@nn.kiev.ua) Received: from nn.UUCP (uucp@localhost) by kozlik.carrier.kiev.ua (rmail mypid=17169 childpid=17170) with UUCP; Fri, 16 Jul 1999 11:05:49 +0000 GMT Received: by nn.kiev.ua (UUPC/@ v7.00, 29Jul97) id AA06197; Fri, 16 Jul 1999 14:00:16 +0300 (EDT) To: freebsd-hackers@freebsd.org X-Comment-To: "Daniel C. Sobral" References: <378DF141.393ECB36@newsguy.com> Message-ID: From: "Valentin Nechayev" Date: Fri, 16 Jul 1999 14:00:16 +0300 (EDT) X-Mailer: dMail [Demos Mail for DOS v2.06] Subject: Re: Replacement for grep(1) (part 2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 47 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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