From owner-freebsd-questions@FreeBSD.ORG Wed Dec 24 14:18:45 2003 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B169F16A4CE for ; Wed, 24 Dec 2003 14:18:45 -0800 (PST) Received: from be-well.no-ip.com (lowellg.ne.client2.attbi.com [66.30.200.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9DA643D49 for ; Wed, 24 Dec 2003 14:18:42 -0800 (PST) (envelope-from freebsd-questions-local@be-well.ilk.org) Received: by be-well.no-ip.com (Postfix, from userid 1147) id 4D75866; Wed, 24 Dec 2003 17:18:42 -0500 (EST) Sender: lowell@be-well.ilk.org To: "Simon" References: <20031223171606.7E8EF43D49@mx1.FreeBSD.org> <44brpxn9qr.fsf@be-well.ilk.org> From: Lowell Gilbert Date: 24 Dec 2003 17:18:42 -0500 In-Reply-To: <44brpxn9qr.fsf@be-well.ilk.org> Message-ID: <447k0ln9kt.fsf@be-well.ilk.org> Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: "freebsd-questions@freebsd.org" Subject: Re: New Error Messages :-( X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Dec 2003 22:18:45 -0000 Lowell Gilbert writes: > "Simon" writes: > > > Before version 4.9, FBSD used to print/log: > > pid 20055 (cmd), uid 1057, was killed: exceeded maximum CPU limit > > Now, all it prints is: maxproc limit exceeded by uid 1203, please see tuning(7)... > > making it impossible to identify which process was killed, am I missing something > > in 4.9 which would make it print the PID killed as well? > > > > Any pointers would be appreciated. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_fork.c?f=u&only_with_tag=RELENG_4&logsort=date > > The relevant change was Revision 1.72.2.15, which put a maxproc check > in a place that hadn't had one at all before. This was a fix to a bug > (which may have been theoretically present for a long time, but hadn't > affected any hardware built until recently), so "fixing" this would be > more complicated than just changing an error string... No, I think I'm wrong. The task context is, in fact, available at that point.