From owner-freebsd-questions@FreeBSD.ORG Mon Apr 12 15:58:11 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01F221065741 for ; Mon, 12 Apr 2010 15:58:11 +0000 (UTC) (envelope-from seklecki@noc.cfi.pgh.pa.us) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id ABE368FC1D for ; Mon, 12 Apr 2010 15:58:10 +0000 (UTC) Received: from [127.0.0.1] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 12 Apr 2010 12:09:11 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::419 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-questions@freebsd.org X-SMFBL: ZnJlZWJzZC1xdWVzdGlvbnNAZnJlZWJzZC5vcmc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=noc.cfi.pgh.pa.us; s=noc_cfi_pgh_pa_us_key_dkim; l=1639; t=1271088551; i=@noc.cfi.pgh.pa.us; h=Message-ID:Date:From: Reply-To:Organization:User-Agent:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding; bh=0+nprqn3YboYenp8L5z9o YjTgi0=; b=TwSmtC94QeWbYt0FdyZOmhx3fPGM+2RAf2aUvPCCYIm6MwDcjr/gV BvyBwXBb0zl4hxu3NQ8GZqcoeR9biIZXBEq7cQjHbKOiz9vZARDljkcO2X9Va4Ab DK/LYvrwypq Message-ID: <4BC3430F.8070400@noc.cfi.pgh.pa.us> Date: Mon, 12 Apr 2010 11:58:07 -0400 From: "Brian A. Seklecki (CFI NOC)" Organization: Collaborative Fusion, Inc. (DRP NOC) User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-questions@freebsd.org, netops_team@collaborativefusion.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Debugging RLIMITs signals: SIGXFSZ and SIGXCPU X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bseklecki@noc.cfi.pgh.pa.us List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 15:58:11 -0000 All: I've got a process that is mysteriously receiving a SIGTERM (or other signal. It's a RADIUS daemon; runs a non-Root (not privsep, unfortunately). Identical hardware, identical code, identical config on 6.3-PL is fine. On 8, the daemon is logging receipt of a non-HUP signal and exiting out. Our best theory at the moment are changes in default RLIMITs between RELENG_6and RELENG_8. For example: 6.3: open files (-n) 11095 8: open files (-n) 3520 Either that, or a memory/file handler/other leak that only manifests in RELENG_8. Either way, I'd like to debug the kernel handling of RLIMITs. The best I can find are references to: /usr/src/sys/kern/kern_resource.c::lim_cb() to SIGXCPU for RLIMIT_CPU /usr/src/sys/ufs/ffs/ffs_vnops.c::ffs_write() to SIGXFSZ or ... RLIMIT_FSIZE Not sure about RLIMIT_RSS, RLIMIT_AS, RLIMIT_NOFILE or others. Unfortunately, in the two places I see, the call 'psignal()' is used in leui of 'killproc()' to pass those custom RLIMIT's related signals and psignal() doesn't have any logging like killproc(). It would be really nice if there could be some standardized logging for RLIMIT* related resource exhaustion. For example: /usr/src/sys/vm/vm_pageout.c: killproc(bigproc, "out of swap space"); So my question are: 1) Anyone else interested in having this "feature" (RLIMIT debugging, possibly a sysctl(3))? 2) Does anyone have any idea how other RLIMIT_ exhaustion is handled? A lot of other checks in the code in kernel_resource.c seems to 'return (error);' on resource exhaustion. Thanks, ~BAS