From owner-freebsd-current@FreeBSD.ORG Tue Sep 2 06:02:06 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E47DE1065674; Tue, 2 Sep 2008 06:02:06 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from mx2.gfk.ru (mx2.gfk.ru [84.21.231.139]) by mx1.freebsd.org (Postfix) with ESMTP id 1E0558FC0C; Tue, 2 Sep 2008 06:02:05 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from ex.hhp.local by mx2.gfk.ru (MDaemon PRO v9.6.0) with ESMTP id md50001761858.msg; Tue, 02 Sep 2008 09:51:36 +0400 Received: from bootserv.hhp.local ([10.0.0.54]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Sep 2008 09:51:32 +0400 Date: Tue, 2 Sep 2008 09:53:11 +0400 (MSD) From: Yuriy Tsibizov X-X-Sender: chibis@atwork.home.local To: Manfred Antar In-Reply-To: <200809011436.m81Eaq2v040141@pozo.com> Message-ID: <20080902095229.Y1605@atwork.home.local> References: <200809011335.m81DZW8b006033@pozo.com> <200809011436.m81Eaq2v040141@pozo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Sep 2008 05:51:32.0979 (UTC) FILETIME=[F410AC30:01C90CBF] X-Spam-Processed: mx2.gfk.ru, Tue, 02 Sep 2008 09:51:36 +0400 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.com X-Envelope-From: Yuriy.Tsibizov@gfk.com X-MDAV-Processed: mx2.gfk.ru, Tue, 02 Sep 2008 09:51:37 +0400 Cc: ports@freebsd.org, Yuriy.Tsibizov@gfk.ru, freebsd-current@freebsd.org, Claus Guttesen Subject: /usr/bin/limits (WAS: Re: Apache.sh on current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 06:02:07 -0000 On Mon, 1 Sep 2008, Manfred Antar wrote: > At 07:19 AM 9/1/2008, Claus Guttesen wrote: >>> /usr/local/etc/rc.d/apache.sh : >>> /usr/bin/limits -e -U www >>> dumps core when starting apache on current >>> This something new, not sure when it started as I have been out of the Country for the past month. >>> Kernel and usr are current >>> Also /usr/local/sbin/apachect : >>> eval `limits -e -C daemon` >>> also dumps core >> >> Are you using apache and php? >> >> -- >> regards >> Claus >> >> When lenity and cruelty play for a kingdom, >> the gentler gamester is the soonest winner. >> >> Shakespeare > > Yes > But if I just do limits -e -U root I get a core dump. > I don't think the problem is with apache. > limits -e -U (Any User) dumps core It's not apache problem. There was new limit added to kernel, and /usr/src/usr.bin/limits was not updated. looking in limits core (lines are a bit different, I had some debug printfs in .c file): (gdb) bt #0 0x00000000 in ?? () #1 0x0804937d in main (argc=3, argv=0xbfbfed44) at /usr/src/usr.bin/limits/limits.c:341 (gdb) l 341 val = resources[rcswhich].func(lc, resources[rcswhich].cap, limits[rcswhich].rlim_cur, limits[rcswhich].rlim_cur); 342 limits[rcswhich].rlim_cur = resources[rcswhich].func(lc, str, val, val); 343 /* maximum value overridden by resourcename or resourcename-max */ 344 sprintf(str, "%s-max", resources[rcswhich].cap); 345 val = resources[rcswhich].func(lc, resources[rcswhich].cap, limits[rcswhich].rlim_max, limits[rcswhich].rlim_max); 346 limits[rcswhich].rlim_max = resources[rcswhich].func(lc, str, val, val); 347 } 348 } 349 } 350 (gdb) p resources $1 = {{cap = 0x804adc2 "cputime", func = 0x8048c84 }, { cap = 0x804adca "filesize", func = 0x8048c34 }, { cap = 0x804add3 "datasize", func = 0x8048c34 }, { cap = 0x804addc "stacksize", func = 0x8048c34 }, { cap = 0x804ade6 "coredumpsize", func = 0x8048c34 },{ cap = 0x804adf3 "memoryuse", func = 0x8048c34 }, { cap = 0x804adfd "memorylocked", func = 0x8048c34 },{ cap = 0x804ae0a "maxproc", func = 0x8048c94 }, { cap = 0x804ae12 "openfiles", func = 0x8048c94 }, { cap = 0x804ae1c "sbsize", func = 0x8048c34 }, { cap = 0x804ae23 "vmemoryuse", func = 0x8048c34 }, { cap = 0x0, func = 0}} And limits dies when processing last limit. Yuriy Tsibizov, GfK RUS Network Administrator p.s. Please keep me in CC.