From toasty@shell1.dragondata.com  Fri Apr 28 22:42:21 2000
Return-Path: <toasty@shell1.dragondata.com>
Received: from home.dragondata.com (home.dragondata.com [204.137.237.2])
	by hub.freebsd.org (Postfix) with ESMTP id 9DC3F37BA79
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 28 Apr 2000 22:42:20 -0700 (PDT)
	(envelope-from toasty@shell1.dragondata.com)
Received: from shell1.dragondata.com (root@shell1 [204.137.237.8])
	by home.dragondata.com (8.9.2/8.9.2) with ESMTP id AAA21951
	for <FreeBSD-gnats-submit@freebsd.org>; Sat, 29 Apr 2000 00:42:20 -0500 (CDT)
Received: (from root@localhost)
	by shell1.dragondata.com (8.9.3/8.9.3) id AAA85097;
	Sat, 29 Apr 2000 00:42:57 -0500 (CDT)
	(envelope-from toasty)
Message-Id: <200004290542.AAA85097@shell1.dragondata.com>
Date: Sat, 29 Apr 2000 00:42:57 -0500 (CDT)
From: Kevin Day <toasty@shell1.dragondata.com>
Reply-To: toasty@shell1.dragondata.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: CPU Time exceeded delivered multiple times
X-Send-Pr-Version: 3.2

>Number:         18289
>Category:       kern
>Synopsis:       CPU Time exceeded delivered multiple times
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Apr 28 22:50:01 PDT 2000
>Closed-Date:    Sun Apr 17 22:17:17 GMT 2005
>Last-Modified:  Sun Apr 17 22:17:17 GMT 2005
>Originator:     Kevin Day
>Release:        FreeBSD 4.0-RELEASE i386
>Organization:
DragonData Internet Services
>Environment:

Any system with executables running over NFS, with CPU time limits

>Description:

If an executable running over NFS hits it's hard CPU limit, killproc is
called multiple times as the process exits.

I'm not sure if more time is being charged to the process while fd's are
being closed over NFS, or cores being dumped, etc. I haven't been able to
figure out exactly why this happens, but it's easy to reproduce.


>How-To-Repeat:


Set your maximum CPU time to a few seconds.

Compile a program that just sits in a busy loop. Copy it to an NFS
server, and run it on an NFS client.

pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit
pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit
pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit
pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit
pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit
pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit
pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit
pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit
pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit
pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit
pid 51206 (spin), uid 1001, was killed: exceeded maximum CPU limit


>Fix:

While this isn't an exact fix:

	/*
	 * Check if the process exceeds its cpu resource allocation.
	 * If over max, kill it.
	 */
	if (p->p_stat != SZOMB && p->p_limit->p_cpulimit != RLIM_INFINITY &&
	    p->p_runtime > p->p_limit->p_cpulimit) {
		rlim = &p->p_rlimit[RLIMIT_CPU];
		if (p->p_runtime / (rlim_t)1000000 >= rlim->rlim_max) {
			killproc(p, "exceeded maximum CPU limit");
		} else {
			psignal(p, SIGXCPU);
			if (rlim->rlim_cur < rlim->rlim_max) {
				/* XXX: we should make a private copy */
				rlim->rlim_cur += 5;
			}
		}
	}

This chunk of code doesn't seem to check to see if the process isn't already
exiting. I'm not sure if it's ever really valid for a process to get this
far after it's already had killproc() hit it, but it appears to be happening
for me.

It does check to see if the process is a zombie, but a quick check shows
that it's not yet a zombie at this stage. 

I have no idea if this is correct or not, but:

	if (p->p_stat != SZOMB && p->p_limit->p_cpulimit != RLIM_INFINITY &&
	    (p->p_flags & P_WEXIT) == 0 && p->p_runtime > p->p_limit->p_cpulimit) {

Looks like it might work.


>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: iedowse 
State-Changed-When: Sun Apr 17 21:11:26 GMT 2005 
State-Changed-Why:  

Does this problem still exist in more recent releases. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=18289 
State-Changed-From-To: feedback->closed 
State-Changed-By: iedowse 
State-Changed-When: Sun Apr 17 22:16:54 GMT 2005 
State-Changed-Why:  

Mail to submitter bounces. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=18289 
>Unformatted:
