From owner-freebsd-stable@FreeBSD.ORG Sat Mar 11 01:57:56 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9999C16A526 for ; Sat, 11 Mar 2006 01:57:49 +0000 (GMT) (envelope-from mike@jellydonut.org) Received: from mail.secureworks.net (mail.secureworks.net [65.114.32.155]) by mx1.FreeBSD.org (Postfix) with SMTP id 5200E44460 for ; Fri, 10 Mar 2006 13:03:04 +0000 (GMT) (envelope-from mike@jellydonut.org) Received: (qmail 49692 invoked from network); 10 Mar 2006 13:03:02 -0000 Received: from unknown (HELO ATLEXCHANGE.secureworks.net) (63.239.86.253) by 0 with SMTP; 10 Mar 2006 13:03:02 -0000 Received: by bromine.back1.secureworks.net with Internet Mail Service (5.5.2657.72) id ; Fri, 10 Mar 2006 08:02:40 -0500 Message-ID: <441178F8.1070503@jellydonut.org> From: Michael Proto To: Dmitry Pryanishnikov Date: Fri, 10 Mar 2006 08:02:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_4 on flash disk and swap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2006 01:57:56 -0000 Dmitry Pryanishnikov wrote: > On Sat, 4 Mar 2006, Peter Jeremy wrote: >> Once you've received this message, the OS is free to kill your >> processes until it frees up some swap (which it can't do if you don't >> have any). I suggest you have a quick look through vm/swap_pager.c >> and vm/vm_pageout.c, looking at swap_pager_full and swap_pager_almost_full. > > This is still a concern for me. IMHO it would be useful to have the ability > to disable process killing due to the lack of swap, because having this > enabled on e.g. transit router can lead to very unpleasant scenario. Imagine > someone DoS-attacks it's sshd, and kernel kills the process with the largest > RSS - it could e.g. be a vital part of the routing software (zebra/ripd/bgpd), > and killing this process will render our router unreachable and unusable! > > Sincerely, Dmitry My suggestion would then be to utilize resource limits in /etc/login.conf for the sshd user (in your example) or other user accounts for applications that you don't want running out of control. See login.conf(5) and login_cap(3) for more details on this. In particular, the datasize, stacksize, memoryuse, and vmemoryuse options may be of benefit. -Proto