From owner-freebsd-bugs Fri Apr 28 22:50: 8 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 39E8637B680 for ; Fri, 28 Apr 2000 22:50:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id WAA19083; Fri, 28 Apr 2000 22:50:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from home.dragondata.com (home.dragondata.com [204.137.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 9DC3F37BA79 for ; 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 ; 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 Reply-To: toasty@shell1.dragondata.com To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/18289: CPU Time exceeded delivered multiple times Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 18289 >Category: kern >Synopsis: CPU Time exceeded delivered multiple times >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Apr 28 22:50:01 PDT 2000 >Closed-Date: >Last-Modified: >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: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message