From nobody@FreeBSD.org  Tue Mar 20 06:06:20 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 2830C16A405
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 20 Mar 2007 06:06:20 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [69.147.83.33])
	by mx1.freebsd.org (Postfix) with ESMTP id 16ECF13C4B0
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 20 Mar 2007 06:06:20 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l2K66J50027704
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 20 Mar 2007 06:06:19 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id l2K61IbZ022510;
	Tue, 20 Mar 2007 06:01:18 GMT
	(envelope-from nobody)
Message-Id: <200703200601.l2K61IbZ022510@www.freebsd.org>
Date: Tue, 20 Mar 2007 06:01:18 GMT
From: Bruce Becker<hostmaster@infra-service.ca>
To: freebsd-gnats-submit@FreeBSD.org
Subject: rpc.rstatd gives bogus info
X-Send-Pr-Version: www-3.0

>Number:         110563
>Category:       kern
>Synopsis:       rpc.rstatd gives bogus info
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    obrien
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Mar 20 06:10:05 GMT 2007
>Closed-Date:    Tue Mar 20 07:19:26 GMT 2007
>Last-Modified:  Tue Mar 20 15:20:05 GMT 2007
>Originator:     Bruce Becker
>Release:        6.2
>Organization:
G.T.S.
>Environment:
FreeBSD server 6.2-STABLE FreeBSD 6.2-STABLE #3: Fri Feb 16 03:47:24 EST 2007    root@server:/usr/obj/usr/src/sys/SERVER  i386
>Description:
packets/second value reported by rpc.rstatd to remote monitor hovers around
8000 or so with odd downward spikes approx every 90 seconds (it's not at
all related to actual interface traffic)

>How-To-Repeat:
view with SunOS/Solaris perfmeter or sysutils/xsysstats port

>Fix:

patch included


Patch attached with submission follows:

--- rstat_proc.c.orig	Sun Jun  1 22:34:36 2003
+++ rstat_proc.c	Sun Jan 29 02:17:10 2006
@@ -138,6 +138,7 @@
     if (! stat_is_init)
         stat_init();
     sincelastreq = 0;
+    stats_all.s2.if_opackets = stats_all.s3.if_opackets;
     return(&stats_all.s2);
 }
 
@@ -147,6 +148,7 @@
     if (! stat_is_init)
         stat_init();
     sincelastreq = 0;
+    stats_all.s1.if_opackets = stats_all.s3.if_opackets;
     return(&stats_all.s1);
 }
 
@@ -219,13 +221,13 @@
 		exit(1);
 	}
 	for(i = 0; i < RSTAT_CPUSTATES ; i++)
-		stats_all.s1.cp_time[i] = bsd_cp_time[cp_time_xlat[i]];
+		stats_all.s3.cp_time[i] = bsd_cp_time[cp_time_xlat[i]];
 
         (void)getloadavg(avrun, sizeof(avrun) / sizeof(avrun[0]));
 
-	stats_all.s2.avenrun[0] = avrun[0] * FSCALE;
-	stats_all.s2.avenrun[1] = avrun[1] * FSCALE;
-	stats_all.s2.avenrun[2] = avrun[2] * FSCALE;
+	stats_all.s3.avenrun[0] = avrun[0] * FSCALE;
+	stats_all.s3.avenrun[1] = avrun[1] * FSCALE;
+	stats_all.s3.avenrun[2] = avrun[2] * FSCALE;
 
 	mib[0] = CTL_KERN;
 	mib[1] = KERN_BOOTTIME;
@@ -234,14 +236,13 @@
 		syslog(LOG_ERR, "sysctl(kern.boottime): %m");
 		exit(1);
 	}
-
-	stats_all.s2.boottime.tv_sec = btm.tv_sec;
-	stats_all.s2.boottime.tv_usec = btm.tv_usec;
+	stats_all.s3.boottime.tv_sec = btm.tv_sec;
+	stats_all.s3.boottime.tv_usec = btm.tv_usec;
 
 
 #ifdef DEBUG
-	fprintf(stderr, "%d %d %d %d\n", stats_all.s1.cp_time[0],
-	    stats_all.s1.cp_time[1], stats_all.s1.cp_time[2], stats_all.s1.cp_time[3]);
+	fprintf(stderr, "%d %d %d %d\n", stats_all.s3.cp_time[0],
+	    stats_all.s3.cp_time[1], stats_all.s3.cp_time[2], stats_all.s3.cp_time[3]);
 #endif
 
 	/* XXX - should use sysctl */
@@ -249,18 +250,18 @@
 		syslog(LOG_ERR, "rstat: can't read cnt from kmem");
 		exit(1);
 	}
-	stats_all.s1.v_pgpgin = cnt.v_vnodepgsin;
-	stats_all.s1.v_pgpgout = cnt.v_vnodepgsout;
-	stats_all.s1.v_pswpin = cnt.v_swappgsin;
-	stats_all.s1.v_pswpout = cnt.v_swappgsout;
-	stats_all.s1.v_intr = cnt.v_intr;
+	stats_all.s3.v_pgpgin = cnt.v_vnodepgsin;
+	stats_all.s3.v_pgpgout = cnt.v_vnodepgsout;
+	stats_all.s3.v_pswpin = cnt.v_swappgsin;
+	stats_all.s3.v_pswpout = cnt.v_swappgsout;
+	stats_all.s3.v_intr = cnt.v_intr;
 	gettimeofday(&tm, (struct timezone *) 0);
-	stats_all.s1.v_intr -= hz*(tm.tv_sec - btm.tv_sec) +
+	stats_all.s3.v_intr -= hz*(tm.tv_sec - btm.tv_sec) +
 	    hz*(tm.tv_usec - btm.tv_usec)/1000000;
-	stats_all.s2.v_swtch = cnt.v_swtch;
+	stats_all.s3.v_swtch = cnt.v_swtch;
 
 	/* update disk transfers */
-	updatexfers(RSTAT_DK_NDRIVE, stats_all.s1.dk_xfer);
+	updatexfers(RSTAT_DK_NDRIVE, stats_all.s3.dk_xfer);
 
 	mib[0] = CTL_NET;
 	mib[1] = PF_LINK;
@@ -272,12 +273,11 @@
 		syslog(LOG_ERR, "sysctl(net.link.generic.system.ifcount): %m");
 		exit(1);
 	}
-
-	stats_all.s1.if_ipackets = 0;
-	stats_all.s1.if_opackets = 0;
-	stats_all.s1.if_ierrors = 0;
-	stats_all.s1.if_oerrors = 0;
-	stats_all.s1.if_collisions = 0;
+	stats_all.s3.if_ipackets = 0;
+	stats_all.s3.if_opackets = 0;
+	stats_all.s3.if_ierrors = 0;
+	stats_all.s3.if_oerrors = 0;
+	stats_all.s3.if_collisions = 0;
 	for (i = 1; i <= ifcount; i++) {
 		len = sizeof ifmd;
 		mib[3] = IFMIB_IFDATA;
@@ -287,19 +287,19 @@
 			if (errno == ENOENT)
 				continue;
 
-			syslog(LOG_ERR, "sysctl(net.link.ifdata.%d.general)"
-			       ": %m", i);
+			syslog(LOG_ERR, "sysctl(net.link.ifdata.%d.general): %m", i);
 			exit(1);
 		}
-
-		stats_all.s1.if_ipackets += ifmd.ifmd_data.ifi_ipackets;
-		stats_all.s1.if_opackets += ifmd.ifmd_data.ifi_opackets;
-		stats_all.s1.if_ierrors += ifmd.ifmd_data.ifi_ierrors;
-		stats_all.s1.if_oerrors += ifmd.ifmd_data.ifi_oerrors;
-		stats_all.s1.if_collisions += ifmd.ifmd_data.ifi_collisions;
+		stats_all.s3.if_ipackets += ifmd.ifmd_data.ifi_ipackets;
+		stats_all.s3.if_opackets += ifmd.ifmd_data.ifi_opackets;
+		stats_all.s3.if_ierrors += ifmd.ifmd_data.ifi_ierrors;
+		stats_all.s3.if_oerrors += ifmd.ifmd_data.ifi_oerrors;
+		stats_all.s3.if_collisions += ifmd.ifmd_data.ifi_collisions;
 	}
-	gettimeofday((struct timeval *)&stats_all.s3.curtime,
-		(struct timezone *) 0);
+
+	gettimeofday(&tm, (struct timezone *) 0);
+	stats_all.s3.curtime.tv_sec = tm.tv_sec;
+	stats_all.s3.curtime.tv_usec = tm.tv_usec;
 	alarm(1);
 }
 
@@ -307,12 +307,21 @@
 setup()
 {
 	char errbuf[_POSIX2_LINE_MAX];
-
 	int en;
+	static int is_kd_setup = 0;
 
-	if ((kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf)) == NULL) {
-		syslog(LOG_ERR, "rpc.rstatd, %s", errbuf);
-		exit(1);
+	/*  setup() is called after each dormant->active
+	 *  transition.  Since we never close the kvm files
+	 *  (there's no reason), make sure we don't open them
+	 *  each time, as that can lead to exhaustion of all open
+	 *  files!  */
+	if (!is_kd_setup) {
+		kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf);
+		if (kd == NULL) {
+			syslog(LOG_ERR, "%s", errbuf);
+			exit (1);
+		}
+		is_kd_setup = 1;
 	}
 
 	if ((en = kvm_nlist(kd, nl)) != 0) {

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->obrien 
Responsible-Changed-By: remko 
Responsible-Changed-When: Tue Mar 20 06:50:34 UTC 2007 
Responsible-Changed-Why:  
Hello David, you touched the code the last time (didn't look beyond 
that), so would you please be able to look into this? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=110563 
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Tue Mar 20 07:18:02 UTC 2007 
State-Changed-Why:  
This appears to be a duplicate of bin/92412, which also includes a more 
complete audit trail and a patch for a test harness to run.  Please let me 
know if I am missing something here. 

Hat:		bugmeister 

http://www.freebsd.org/cgi/query-pr.cgi?pr=110563 


From: Infraservice hostmaster <hostmaster@Infra-Service.ca>
To: linimon@FreeBSD.org (Mark Linimon)
Cc: obrien@FreeBSD.org, bug-followup@freebsd.org
Subject: Re: kern/110563: rpc.rstatd gives bogus info
Date: Tue, 20 Mar 2007 03:23:58 -0400 (EDT)

 | 
 | Synopsis: rpc.rstatd gives bogus info
 | 
 | State-Changed-From-To: open->closed
 | State-Changed-By: linimon
 | State-Changed-When: Tue Mar 20 07:18:02 UTC 2007
 | State-Changed-Why: 
 | This appears to be a duplicate of bin/92412, which also includes a more
 | complete audit trail and a patch for a test harness to run.  Please let me
 | know if I am missing something here.
 | 
 | Hat:		bugmeister
 | 
 | http://www.freebsd.org/cgi/query-pr.cgi?pr=110563
 
 
 	it is indeed, and i gave up on that one - I am getting very
 	tired of applying this patch to the many systems i manage
 	every time i upgrade  to the latest -STABLE
 
 

From: Remko Lodder <remko@elvandar.org>
To: Infraservice hostmaster <hostmaster@Infra-Service.ca>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org,
	bug-followup@FreeBSD.org
Subject: Re: misc/110563: rpc.rstatd gives bogus info
Date: Tue, 20 Mar 2007 08:37:52 +0100

 On Tue, Mar 20, 2007 at 03:14:03AM -0400, Infraservice hostmaster wrote:
 > | 
 > | Thank you very much for your problem report.
 > | It has the internal identification `misc/110563'.
 > | The individual assigned to look at your
 > | report is: freebsd-bugs. 
 > | 
 > | You can access the state of your problem report at any time
 > | via this link:
 > | 
 > | http://www.freebsd.org/cgi/query-pr.cgi?pr=110563
 > | 
 > | >Category:       misc
 > | >Responsible:    freebsd-bugs
 > | >Synopsis:       rpc.rstatd gives bogus info
 > | >Arrival-Date:   Tue Mar 20 06:10:05 GMT 2007
 > 
 > 
 > 	this PR supersedes 110560 which should be closed
 > 
 > 
 
 You should stop submitting new PR tickets and follow-up
 on already created tickets for the same issue. Thank you
 very much for the coorporation.
 -- 
 Kind regards,
 
      Remko Lodder               ** remko@elvandar.org
      FreeBSD                    ** remko@FreeBSD.org
 
      /* Quis custodiet ipsos custodes */

From: linimon@lonesome.com (Mark Linimon)
To: Infraservice hostmaster <hostmaster@Infra-Service.ca>
Cc: Mark Linimon <linimon@FreeBSD.org>, obrien@FreeBSD.org,
	bug-followup@freebsd.org
Subject: Re: kern/110563: rpc.rstatd gives bogus info
Date: Tue, 20 Mar 2007 02:42:27 -0500

 On Tue, Mar 20, 2007 at 03:23:58AM -0400, Infraservice hostmaster wrote:
 > | This appears to be a duplicate of bin/92412, which also includes a more
 > | complete audit trail and a patch for a test harness to run.  Please let me
 > | know if I am missing something here.
 > 
 > 	it is indeed, and i gave up on that one - I am getting very
 > 	tired of applying this patch to the many systems i manage
 > 	every time i upgrade to the latest -STABLE
 
 I'm afraid you don't understand how this situation works.
 
 By resending a PR, you aren't necessarily getting any closer to anyone
 actually solving your problems.  What you _do_ wind up accomplishing is
 getting someone like me to spend 20 minutes to figure out whether all
 these PRs indeed address the same problem, from the same person, and
 include the same patch (which is what I eventually concluded).
 
 Following up to the initial PR asking why nothing had been done on it
 would have been sufficient.
 
 The overall problem is that no one has taken responsibility for keeping
 the RPC code up to date.  These types of things happen in volunteer
 projects.  The code is intricate, crufty, and no fun to work on.  Other
 than asking for assistance on -current, there really aren't any magic
 buttons that you can push to get this patch committed.
 
 Believe me, there are lots of other PRs with patches that I would also
 like to see committed, but we have more of them than we currently have
 volunteers willing to work through all of them.  If you figure out a
 solution for _that_ problem, please let me know.
 
 mcl

From: Infraservice hostmaster <hostmaster@Infra-Service.ca>
To: linimon@lonesome.com (Mark Linimon)
Cc: obrien@FreeBSD.org, bug-followup@freebsd.org
Subject: Re: kern/110563: rpc.rstatd gives bogus info
Date: Tue, 20 Mar 2007 03:56:59 -0400 (EDT)

 | 
 | On Tue, Mar 20, 2007 at 03:23:58AM -0400, Infraservice hostmaster wrote:
 | > | This appears to be a duplicate of bin/92412, which also includes a more
 | > | complete audit trail and a patch for a test harness to run.  Please let me
 | > | know if I am missing something here.
 | > 
 | > 	it is indeed, and i gave up on that one - I am getting very
 | > 	tired of applying this patch to the many systems i manage
 | > 	every time i upgrade to the latest -STABLE
 | 
 | I'm afraid you don't understand how this situation works.
 | 
 | By resending a PR, you aren't necessarily getting any closer to anyone
 | actually solving your problems.  What you _do_ wind up accomplishing is
 | getting someone like me to spend 20 minutes to figure out whether all
 | these PRs indeed address the same problem, from the same person, and
 | include the same patch (which is what I eventually concluded).
 | 
 | Following up to the initial PR asking why nothing had been done on it
 | would have been sufficient.
 
 
 	I did that some time ago but got no respnse at all
 
 
 | The overall problem is that no one has taken responsibility for keeping
 | the RPC code up to date.  These types of things happen in volunteer
 | projects.  The code is intricate, crufty, and no fun to work on.  Other
 | than asking for assistance on -current, there really aren't any magic
 | buttons that you can push to get this patch committed.
 
 
 	I could lend a hand where i have expertise - that's why I
 	submitted the patch in the 1st place.  I agree it's crufty,
 	and if other code is typical of the mistakes in rpc.rstatd
 	then there might be a fair bit of work to do
 
 
 | Believe me, there are lots of other PRs with patches that I would also
 | like to see committed, but we have more of them than we currently have
 | volunteers willing to work through all of them.  If you figure out a
 | solution for _that_ problem, please let me know.
 
 
 	someone a while back misunderstood bin/92412 and decided it
 	was a patch to rup:
 
 
 "Synopsis:	[patch] rup(1): rpc.rstatd reports bogus packets/per/second info"
 
 
 	... so that was not very encouraging - that was when i decided
 	it might be better to resubmit it.
 
 
 	i would save you the time & install it into the source tree
 	myself if there was a safe way to do so :)
 
 
 	I appreciate the hard work & big pile of "to-do" you all face
 	(it's a familiar situation around here too...)
 
 Cheers,
 B.Becker

From: Remko Lodder <remko@elvandar.org>
To: Infraservice hostmaster <hostmaster@Infra-Service.ca>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org,
	bug-followup@FreeBSD.org
Subject: Re: misc/110563: rpc.rstatd gives bogus info
Date: Tue, 20 Mar 2007 08:37:52 +0100

 On Tue, Mar 20, 2007 at 03:14:03AM -0400, Infraservice hostmaster wrote:
 > | 
 > | Thank you very much for your problem report.
 > | It has the internal identification `misc/110563'.
 > | The individual assigned to look at your
 > | report is: freebsd-bugs. 
 > | 
 > | You can access the state of your problem report at any time
 > | via this link:
 > | 
 > | http://www.freebsd.org/cgi/query-pr.cgi?pr=110563
 > | 
 > | >Category:       misc
 > | >Responsible:    freebsd-bugs
 > | >Synopsis:       rpc.rstatd gives bogus info
 > | >Arrival-Date:   Tue Mar 20 06:10:05 GMT 2007
 > 
 > 
 > 	this PR supersedes 110560 which should be closed
 > 
 > 
 
 You should stop submitting new PR tickets and follow-up
 on already created tickets for the same issue. Thank you
 very much for the coorporation.
 -- 
 Kind regards,
 
      Remko Lodder               ** remko@elvandar.org
      FreeBSD                    ** remko@FreeBSD.org
 
      /* Quis custodiet ipsos custodes */

From: linimon@lonesome.com (Mark Linimon)
To: Infraservice hostmaster <hostmaster@Infra-Service.ca>
Cc: Mark Linimon <linimon@lonesome.com>, obrien@FreeBSD.org,
	bug-followup@freebsd.org
Subject: Re: kern/110563: rpc.rstatd gives bogus info
Date: Tue, 20 Mar 2007 10:12:30 -0500

 On Tue, Mar 20, 2007 at 03:56:59AM -0400, Infraservice hostmaster wrote:
 > 	someone a while back misunderstood bin/92412 and decided it
 > 	was a patch to rup:
 > 
 > "Synopsis:	[patch] rup(1): rpc.rstatd reports bogus packets/per/second info"
 
 That's probably me, as I try to triage the PRs.  I am trainable, so
 following up is your best bet.
 
 mcl
>Unformatted:
