From debbugs@buxtehude.debian.org Sat Feb 1 14:36:10 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 398237FB9 for ; Sat, 1 Feb 2014 14:36:10 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1C111304039 for ; Sat, 1 Feb 2014 12:36:09 -0800 (PST) X-ASG-Debug-ID: 1391286967-04cb6c6de387d00001-S8gJnT Received: from buxtehude.debian.org (buxtehude.debian.org [140.211.166.26]) by cuda.sgi.com with ESMTP id BTkIUBuV404WMKq2 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 01 Feb 2014 12:36:08 -0800 (PST) X-Barracuda-Envelope-From: debbugs@buxtehude.debian.org X-Barracuda-Apparent-Source-IP: 140.211.166.26 Received: from debbugs by buxtehude.debian.org with local (Exim 4.80) (envelope-from ) id 1W9hIN-0006z6-5K; Sat, 01 Feb 2014 20:36:07 +0000 X-Loop: owner@bugs.debian.org Subject: Bug#737340: pcp: use autotools-dev to update config.{sub,guess} for new arches Reply-To: Logan Rosen , 737340@bugs.debian.org X-ASG-Orig-Subj: Bug#737340: pcp: use autotools-dev to update config.{sub,guess} for new arches Resent-From: Logan Rosen Original-Sender: Logan Rosen Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: PCP Development Team X-Loop: owner@bugs.debian.org Resent-Date: Sat, 01 Feb 2014 20:36:02 +0000 Resent-Message-ID: X-Debian-PR-Message: report 737340 X-Debian-PR-Package: pcp X-Debian-PR-Keywords: patch X-Debian-PR-Source: pcp Received: via spool by submit@bugs.debian.org id=B.139128677325204 (code B); Sat, 01 Feb 2014 20:36:02 +0000 Received: (at submit) by bugs.debian.org; 1 Feb 2014 20:32:53 +0000 Received: from mail-qc0-f182.google.com ([209.85.216.182]) by buxtehude.debian.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from ) id 1W9hFF-0006YA-2f for submit@bugs.debian.org; Sat, 01 Feb 2014 20:32:53 +0000 Received: by mail-qc0-f182.google.com with SMTP id c9so9132418qcz.13 for ; Sat, 01 Feb 2014 12:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:from:to:subject:message-id:date; bh=CDgjXJWavcl0OX8FG1BSC6TjoDqgRPGgnWXvsojbK/E=; b=JdXVeL9vsxc4odml3+jLxP5utMUb2NAaK4dlXbAnt3Lqg1vnSqhGOwJx/mF7VnFkZ4 Wd/p/jzVdh/PaqboXWP0Sr8H9MRZStlEQxsET041iQs1XZd+P+ofqu96pITHo2/1OBp9 fdvlfGMwWKXJptmJgt0JY4hDL7GpuNrzzgGIXqhvHJ3ER77QZseUM9aTyEpiDDITc6Jm yoOzgp5mjrUW1ggAmhcceN6SCg2qSAHVH45nkRgKloETGpkTb5fnmBmlzjqaG4DRkHTP g4wg1MND1hZYVodOdJdgF+MV5P+jhB39ANIJrRxtNyHTgJmRo84YTYX3wx4xhV1l1C0A oH1g== X-Received: by 10.140.42.51 with SMTP id b48mr41057392qga.23.1391286766938; Sat, 01 Feb 2014 12:32:46 -0800 (PST) Received: from [127.0.1.1] (nat-128-84-124-0-627.cit.cornell.edu. [128.84.126.115]) by mx.google.com with ESMTPSA id o68sm19424847qge.8.2014.02.01.12.32.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Feb 2014 12:32:46 -0800 (PST) Sender: Logan Rosen Content-Type: multipart/mixed; boundary="===============2182504735896600445==" MIME-Version: 1.0 From: Logan Rosen To: Debian Bug Tracking System Message-ID: <20140201203247.3705.32398.reportbug@logan-VirtualBox> X-Mailer: reportbug 6.5.0ubuntu1 Date: Sat, 01 Feb 2014 15:32:47 -0500 Delivered-To: submit@bugs.debian.org Resent-Sender: Debian BTS X-Barracuda-Connect: buxtehude.debian.org[140.211.166.26] X-Barracuda-Start-Time: 1391286968 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144727 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature This is a multi-part MIME message sent by reportbug. --===============2182504735896600445== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Package: pcp Version: 3.8.12 Severity: normal Tags: patch User: ubuntu-devel@lists.ubuntu.com Usertags: origin-ubuntu trusty ubuntu-patch Dear Maintainer, Please use autotools-dev to update config.{sub,guess} for new architectures. For example, we needed these updates in Ubuntu for the new arm64 and ppc64el architectures. In Ubuntu, the attached patch was applied to achieve the following: * Use autotools-dev to update config.{sub,guess} for new arches. Thanks for considering the patch. Logan Rosen -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-6-generic (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --===============2182504735896600445== Content-Type: text/x-diff; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pcp_3.8.12ubuntu1.debdiff" === modified file 'debian/control' --- debian/control 2013-11-03 07:25:23 +0000 +++ debian/control 2014-02-01 20:31:34 +0000 @@ -2,9 +2,9 @@ Section: utils Priority: extra Homepage: http://oss.sgi.com/projects/pcp Maintainer: PCP Development Team Uploaders: Nathan Scott , Anibal Monsalve Salazar -Build-Depends: bison, flex, gawk, procps, pkg-config, debhelper (>= 5), perl (>= 5.6), libreadline-dev | libreadline5-dev | libreadline-gplv2-dev, chrpath, libbsd-dev [kfreebsd-any], libkvm-dev [kfreebsd-any], python-all, python-all-dev, libnspr4-dev, libnss3-dev, libsasl2-dev, libmicrohttpd-dev, libavahi-common-dev +Build-Depends: bison, flex, gawk, procps, pkg-config, debhelper (>= 5), perl (>= 5.6), libreadline-dev | libreadline5-dev | libreadline-gplv2-dev, chrpath, libbsd-dev [kfreebsd-any], libkvm-dev [kfreebsd-any], python-all, python-all-dev, libnspr4-dev, libnss3-dev, libsasl2-dev, libmicrohttpd-dev, libavahi-common-dev, autotools-dev #Architecture-dependent -- Build-Depends: libibumad-dev, libibmad-dev Standards-Version: 3.9.3 X-Python-Version: >= 2.6 === modified file 'debian/rules' --- debian/rules 2013-09-09 18:20:08 +0000 +++ debian/rules 2014-01-29 20:32:01 +0000 @@ -109,6 +109,7 @@ .census: @echo "== dpkg-buildpackage: configure" 1>&2 $(checkdir) + dh_autotools-dev_updateconfig $(configure_tools) ./configure $(configure_paths) touch .census @@ -119,6 +120,8 @@ $(MAKE) realclean -rm -rf $(alldir) -rm -f debian/*substvars debian/files* debian/*.debhelper + dh_autotools-dev_restoreconfig + dh_clean binary-indep: --===============2182504735896600445==-- From nscott@redhat.com Sun Feb 2 19:56:58 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id AAAB77F5D for ; Sun, 2 Feb 2014 19:56:58 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 8B3558F8040 for ; Sun, 2 Feb 2014 17:56:55 -0800 (PST) X-ASG-Debug-ID: 1391392614-04cb6c6de2a7d10001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id Zq3HNphiN8qnwBMt for ; Sun, 02 Feb 2014 17:56:54 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s131urru002010; Sun, 2 Feb 2014 20:56:53 -0500 Date: Sun, 2 Feb 2014 20:56:53 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Dave Brolley Cc: pcp@oss.sgi.com Message-ID: <1513605432.17499414.1391392613778.JavaMail.root@redhat.com> In-Reply-To: <52EBC1AF.3040107@redhat.com> References: <52EBC1AF.3040107@redhat.com> Subject: Re: [pcp] Another Possible Fresh Install Problem MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] Another Possible Fresh Install Problem Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: Another Possible Fresh Install Problem Thread-Index: HPLXLqsvrZnSen2nrqshBEa207u+Aw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1391392614 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144770 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > Got this while running qa test 646 as part of the 'sanity' group on my > new workstation. ANother possible fresh install problem? > > > mmv_stats_init failed : No such file or directory > > mmv_stats_init failed : No such file or directory > > /var/lib/pcp/tmp/mmv/test21668: No such file or directory > > /var/lib/pcp/tmp/mmv/notest21668: No such file or directory > This is a QA test failure - a few releases back we made a change to no longer enforce the security policy for the mmv directory. We now make it opt-in for new installs, so that the user chooses how they wish to setup the pmdammv <-> client communication, and can choose a more security-restrictive channel if they desire. For upgrades, the situation is that the pre-existing situation (where the pcp package installed a world-writable-sticky-bit-set directory for instrumented apps) continues on unchanged - hence, I'd not tripped over this yet. :) I'll fix up the test - thanks Dave. -- Nathan From debbugs@buxtehude.debian.org Sun Feb 2 20:21:14 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id F09EF7FC3 for ; Sun, 2 Feb 2014 20:21:13 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id C27248F8050 for ; Sun, 2 Feb 2014 18:21:10 -0800 (PST) X-ASG-Debug-ID: 1391394065-04cbb00c2aa3fd0001-S8gJnT Received: from buxtehude.debian.org (buxtehude.debian.org [140.211.166.26]) by cuda.sgi.com with ESMTP id 143fYQHGRGtIketC (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 02 Feb 2014 18:21:06 -0800 (PST) X-Barracuda-Envelope-From: debbugs@buxtehude.debian.org X-Barracuda-Apparent-Source-IP: 140.211.166.26 Received: from debbugs by buxtehude.debian.org with local (Exim 4.80) (envelope-from ) id 1WA99k-00011o-Ox; Mon, 03 Feb 2014 02:21:04 +0000 X-Loop: owner@bugs.debian.org Subject: Bug#737340: [pcp] Bug#737340: pcp: use autotools-dev to update config.{sub, guess} for new arches Reply-To: Nathan Scott , 737340@bugs.debian.org X-ASG-Orig-Subj: Bug#737340: [pcp] Bug#737340: pcp: use autotools-dev to update config.{sub, guess} for new arches Resent-From: Nathan Scott Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: PCP Development Team X-Loop: owner@bugs.debian.org Resent-Date: Mon, 03 Feb 2014 02:21:02 +0000 Resent-Message-ID: X-Debian-PR-Message: followup 737340 X-Debian-PR-Package: pcp X-Debian-PR-Keywords: patch X-Debian-PR-Source: pcp Received: via spool by 737340-submit@bugs.debian.org id=B737340.13913939042648 (code B ref 737340); Mon, 03 Feb 2014 02:21:02 +0000 Received: (at 737340) by bugs.debian.org; 3 Feb 2014 02:18:24 +0000 Received: from mx3-phx2.redhat.com ([209.132.183.24]) by buxtehude.debian.org with esmtp (Exim 4.80) (envelope-from ) id 1WA979-0000gN-Rt for 737340@bugs.debian.org; Mon, 03 Feb 2014 02:18:24 +0000 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s132ILf9005322; Sun, 2 Feb 2014 21:18:21 -0500 Date: Sun, 2 Feb 2014 21:18:21 -0500 (EST) From: Nathan Scott To: Logan Rosen , 737340@bugs.debian.org Message-ID: <1253670958.17500659.1391393901539.JavaMail.root@redhat.com> In-Reply-To: <20140201203247.3705.32398.reportbug@logan-VirtualBox> References: <20140201203247.3705.32398.reportbug@logan-VirtualBox> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: Bug#737340: pcp: use autotools-dev to update config.{sub, guess} for new arches Thread-Index: DWqFKZaDKcgpGdJVVg50Sni3H6Nmgg== Resent-Sender: Debian BTS X-Barracuda-Connect: buxtehude.debian.org[140.211.166.26] X-Barracuda-Start-Time: 1391394066 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144770 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > ... > Please use autotools-dev to update config.{sub,guess} for new architectures. > ... > Thanks for considering the patch. > Thanks Logan - merged in. I'll close this bug out when pcp-3.8.13 is released & uploaded (the usual release schedule should put that in about four weeks time). cheers. -- Nathan From nscott@redhat.com Mon Feb 3 00:27:04 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id F3CBC7F56 for ; Mon, 3 Feb 2014 00:27:03 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id DC4D98F8037 for ; Sun, 2 Feb 2014 22:27:03 -0800 (PST) X-ASG-Debug-ID: 1391408819-04cb6c6de2ad130001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id cd5sws6RcuOmobCl for ; Sun, 02 Feb 2014 22:26:59 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s136Qw39031907 for ; Mon, 3 Feb 2014 01:26:58 -0500 Date: Mon, 3 Feb 2014 01:26:58 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: PCP Message-ID: <1907127767.17558257.1391408818816.JavaMail.root@redhat.com> In-Reply-To: <1428599621.17558136.1391408670540.JavaMail.root@redhat.com> Subject: pcp updates: python time APIs, ubuntu build tweak MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: python time APIs, ubuntu build tweak Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: pcp updates: python time APIs, ubuntu build tweak Thread-Index: LFOmYcCSH4u2KZK9a/VjHXav8XERPw== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1391408819 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144776 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev debian/changelog | 1 + debian/control | 2 +- debian/rules | 3 +++ qa/737 | 29 +++++++++++++++++++++++++++++ qa/737.out | 5 +++++ qa/group | 1 + qa/src/GNUlocaldefs | 3 ++- qa/src/test_pcp_time.python | 32 ++++++++++++++++++++++++++++++++ src/python/pcp/pmapi.py | 41 ++++++++++++++++++++++++++--------------- 9 files changed, 100 insertions(+), 17 deletions(-) commit 004d8a3e46fe4c56b0ea4db27c2c618b86b54f76 Author: Nathan Scott Date: Mon Feb 3 17:13:12 2014 +1100 Fix and test python wrappers for pmLocaltime and pmCtime Several problems uncovered in the time-processing wrappers of the python PMAPI module after attempting to use 'em for the first time: - size of 'struct tm' did not match modern reality (missing the final two fields for Linux and BSD - sigsegv results); - system time.mktime python method does not take 9 arguments just one - fix the string-printing method for struct tm; - system time.mktime takes year field as an actual year, and not the number of years since 1900 - code didn't cater for this difference to struct tm form returned from localtime. - definition of the pmLocaltime return code was not correct; - definition of first pmCtime parameter was not correct; - code didn't cope with numeric input being passed in either float/integer format - pythonic time-in-seconds is float. - no memory allocated to hold the struct tm that pmLocaltime returns - pointer passed in pointing off into lala-land; - need to ensure a pointer to a ctypes c_long is passed into both of these routines - caller might well pass int (e.g. from a pmResult timestamp (struct timeval, tv_sec field). Fixed the above and added qa test (boeing) 737 to verify it. Some small cleanups as well, in the affected code - fixed a couple of typos in comments, and removed an unused import of struct_time from the system time module. commit 5550ecb6fd843466df5e998ee406d684e6fa5cdd Author: Nathan Scott Date: Mon Feb 3 14:00:21 2014 +1100 Make a changelog note about deb bug# fixed in next release commit efc5d9fb0b1ba80165a57dfdff1faa2036b4c219 Author: Logan Rosen Date: Mon Feb 3 13:09:50 2014 +1100 Use autotools-dev to update config.{sub,guess} for new architectures For example, we needed these updates in Ubuntu for the new arm64 and ppc64el architectures. In Ubuntu, the attached patch was applied to achieve the following: * Use autotools-dev to update config.{sub,guess} for new arches. From nscott@redhat.com Mon Feb 3 00:28:46 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 255457F5D for ; Mon, 3 Feb 2014 00:28:46 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 04AA68F8037 for ; Sun, 2 Feb 2014 22:28:45 -0800 (PST) X-ASG-Debug-ID: 1391408924-04cbb00c2aa9100001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id UV85cKHr22NvmQtF for ; Sun, 02 Feb 2014 22:28:44 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s136SiJX009426; Mon, 3 Feb 2014 01:28:44 -0500 Date: Mon, 3 Feb 2014 01:28:44 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Stan Cox Cc: PCP Message-ID: <1713917632.17558316.1391408924237.JavaMail.root@redhat.com> In-Reply-To: <1841151293.16935708.1391165636716.JavaMail.root@redhat.com> References: <52E83DD8.5020403@redhat.com> <1841151293.16935708.1391165636716.JavaMail.root@redhat.com> Subject: Re: [pcp] programmer's guide python documentation MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] programmer's guide python documentation Content-Type: multipart/mixed; boundary="----=_Part_17558314_369865671.1391408924234" X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: programmer's guide python documentation Thread-Index: ZmPfsYh/qadynOmo3UOPMKVJjEsUfR4yhZL1 X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1391408924 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144776 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ------=_Part_17558314_369865671.1391408924234 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Stan, ----- Original Message ----- > [...] - a python implementation of uptime(1). Attached; for your > review/perusal/amusement ... somewhere in section 3.9 - "Programming > Issues and Examples" would suit if you like it, after the C example > perhaps. Sadly, it does not yet work - its exposing a bug in the py > wrapper code for pmLocaltime(3) - also affects pmCtime(3) I think. The current dev branch contains the fixes (turned out to be several issues lurking here), and the attached uptime.py now works a treat. $ ./uptime.py && /usr/bin/uptime 17:15:29 up 1:42, 8 users, load average: 0.06, 0.25, 0.17 17:15:29 up 1:42, 8 users, load average: 0.06, 0.25, 0.17 Looking at uptime.py I can't help but wish we'd got around to taking on pmGetopt as discussed awhile back - with that, we'd have -h/-a/-S "for free" (well, one more line of python code!). Then, we'd get to answer questions like "what was the system uptime at 2pm yesterday - just prior to the outage?", etc - looking forward to that! cheers. -- Nathan ------=_Part_17558314_369865671.1391408924234 Content-Type: text/x-python; name=uptime.py Content-Disposition: attachment; filename=uptime.py Content-Transfer-Encoding: base64 IyEvdXNyL2Jpbi9weXRob24KIwojIENvcHlyaWdodCAoQykgMjAxNCBSZWQgSGF0LgojCiMgVGhp cyBwcm9ncmFtIGlzIGZyZWUgc29mdHdhcmU7IHlvdSBjYW4gcmVkaXN0cmlidXRlIGl0IGFuZC9v ciBtb2RpZnkgaXQKIyB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBM aWNlbnNlIGFzIHB1Ymxpc2hlZCBieSB0aGUKIyBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb247IGVp dGhlciB2ZXJzaW9uIDIgb2YgdGhlIExpY2Vuc2UsIG9yIChhdCB5b3VyCiMgb3B0aW9uKSBhbnkg bGF0ZXIgdmVyc2lvbi4KIyAKIyBUaGlzIHByb2dyYW0gaXMgZGlzdHJpYnV0ZWQgaW4gdGhlIGhv cGUgdGhhdCBpdCB3aWxsIGJlIHVzZWZ1bCwgYnV0CiMgV0lUSE9VVCBBTlkgV0FSUkFOVFk7IHdp dGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZiBNRVJDSEFOVEFCSUxJVFkKIyBvciBG SVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUgR05VIEdlbmVyYWwgUHVi bGljIExpY2Vuc2UKIyBmb3IgbW9yZSBkZXRhaWxzLgojCgoiIiIgVGVsbCBob3cgbG9uZyB0aGUg c3lzdGVtIGhhcyBiZWVuIHJ1bm5pbmcKCnVwdGltZS5weSBnaXZlcyBhIG9uZSBsaW5lIGRpc3Bs YXkgb2YgdGhlIGZvbGxvd2luZyBpbmZvcm1hdGlvbjoKICAgIFRoZSBjdXJyZW50IHRpbWU7CiAg ICBIb3cgbG9uZyB0aGUgc3lzdGVtIGhhcyBiZWVuIHJ1bm5pbmc7CiAgICBIb3cgbWFueSB1c2Vy cyBhcmUgY3VycmVudGx5IGxvZ2dlZCBvbjsgYW5kCiAgICBUaGUgc3lzdGVtIGxvYWQgYXZlcmFn ZXMgZm9yIHRoZSBwYXN0IDEsIDUsIGFuZCAxNSBtaW51dGVzLgoiIiIKCmZyb20gcGNwIGltcG9y dCBwbWFwaQpmcm9tIGNwbWFwaSBpbXBvcnQgUE1fVFlQRV9VMzIsIFBNX1RZUEVfRkxPQVQKCmRl ZiBwcmludF90aW1lc3RhbXAoc3RhbXApOgogICAgIiIiIFJlcG9ydCB0aGUgc2FtcGxlIHRpbWUg KHN0cnVjdCB0bSkgaW4gSEg6TU06U1MgZm9ybSAiIiIKICAgIHByaW50ICIgJTAyZDolMDJkOiUw MmQiICUgKHN0YW1wLnRtX2hvdXIsIHN0YW1wLnRtX21pbiwgc3RhbXAudG1fc2VjKSwKCmRlZiBw cmludF91cHRpbWUoc2Vjb25kcyk6CiAgICAiIiIgUmVwb3J0IG9uIHN5c3RlbSB1cC10aW1lIGlu IGRheXMsIGhvdXJzIGFuZCBtaW51dGVzICIiIgogICAgZGF5cyA9IHNlY29uZHMgLyAoNjAgKiA2 MCAqIDI0KQogICAgbWludXRlcyA9IHNlY29uZHMgLyA2MAogICAgaG91cnMgPSBtaW51dGVzIC8g NjAKICAgIGhvdXJzID0gaG91cnMgJSAyNAogICAgbWludXRlcyA9IG1pbnV0ZXMgJSA2MAogICAg cHJpbnQgInVwIiwKICAgIGlmIGRheXMgPiAxOgogICAgICAgIHByaW50ICIlZCBkYXlzLCIgJSBk YXlzLAogICAgZWxpZiBkYXlzICE9IDA6CiAgICAgICAgcHJpbnQgIjEgZGF5LCIsCiAgICBpZiBo b3VycyAhPSAwOgogICAgICAgIHByaW50ICclMmQ6JTAyZCwnICUgKGhvdXJzLCBtaW51dGVzKSwK ICAgIGVsc2U6CiAgICAgICAgcHJpbnQgJyVkIG1pbiwnICUgbWludXRlcywKCmRlZiBwcmludF91 c2VycyhudXNlcnMpOgogICAgIiIiIFJlcG9ydCB0aGUgbnVtYmVyIG9mIGxvZ2dlZCBpbiB1c2Vy cyBhdCBzYW1wbGUgdGltZSAiIiIKICAgIGlmIG51c2VycyA9PSAxOgogICAgICAgIHByaW50ICcx IHVzZXIsICcgCiAgICBlbHNlOgogICAgICAgIHByaW50ICclMmQgdXNlcnMsICcgJSBudXNlcnMs CgpkZWYgcHJpbnRfbG9hZChvbmUsIGZpdmUsIGZpZnRlZW4pOgogICAgIiIiIFJlcG9ydCAxLCA1 LCAxNSBtaW51dGUgbG9hZCBhdmVyYWdlcyBhdCBzYW1wbGUgdGltZSAiIiIKICAgIHByaW50ICds b2FkIGF2ZXJhZ2U6ICUuMmYsICUuMmYsICUuMmYnICUgKG9uZSwgZml2ZSwgZmlmdGVlbiksCgpk ZWYgdXB0aW1lKCk6CiAgICAiIiIgQ3JlYXRlIGEgUE1BUEkgY29udGV4dCAoY291bGQgYmUgZWl0 aGVyIGhvc3Qgb3IgYXJjaGl2ZSksCiAgICAgICAgZmV0Y2ggYW5kIHJlcG9ydCBhIGZpeGVkIHNl dCBvZiB2YWx1ZXMgcmVsYXRlZCB0byB1cHRpbWUuCiAgICAiIiIKICAgIGNvbnRleHQgPSBwbWFw aS5wbUNvbnRleHQoKQogICAgbWV0cmljcyA9ICgna2VybmVsLmFsbC51cHRpbWUnLCAna2VybmVs LmFsbC5udXNlcnMnLCAna2VybmVsLmFsbC5sb2FkJykKICAgIHBtaWRzID0gY29udGV4dC5wbUxv b2t1cE5hbWUobWV0cmljcykKICAgIGRlc2NzID0gY29udGV4dC5wbUxvb2t1cERlc2NzKHBtaWRz KQogICAgcmVzdWx0ID0gY29udGV4dC5wbUZldGNoKHBtaWRzKQoKICAgIHNhbXBsZV90aW1lID0g cmVzdWx0LmNvbnRlbnRzLnRpbWVzdGFtcC50dl9zZWMKICAgIHRpbWVfc3RydWN0ID0gY29udGV4 dC5wbUxvY2FsdGltZShzYW1wbGVfdGltZSkKICAgIHByaW50X3RpbWVzdGFtcCh0aW1lX3N0cnVj dCkKCiAgICBhdG9tID0gY29udGV4dC5wbUV4dHJhY3RWYWx1ZSgKCQlyZXN1bHQuY29udGVudHMu Z2V0X3ZhbGZtdCgwKSwKCQlyZXN1bHQuY29udGVudHMuZ2V0X3ZsaXN0KDAsIDApLAoJCWRlc2Nz WzBdLmNvbnRlbnRzLnR5cGUsIFBNX1RZUEVfVTMyKQogICAgcHJpbnRfdXB0aW1lKGF0b20udWwp CgogICAgYXRvbSA9IGNvbnRleHQucG1FeHRyYWN0VmFsdWUoCgkJcmVzdWx0LmNvbnRlbnRzLmdl dF92YWxmbXQoMSksCgkJcmVzdWx0LmNvbnRlbnRzLmdldF92bGlzdCgxLCAwKSwKCQlkZXNjc1sx XS5jb250ZW50cy50eXBlLCBQTV9UWVBFX1UzMikKICAgIHByaW50X3VzZXJzKGF0b20udWwpCgog ICAgYXZlcmFnZXMgPSBbMSwgNSwgMTVdCiAgICBmb3IgaW5zdGFuY2UgaW4geHJhbmdlKDMpOgog ICAgICAgIGF2ZXJhZ2VzW2luc3RhbmNlXSA9IGNvbnRleHQucG1FeHRyYWN0VmFsdWUoCgkJCQly ZXN1bHQuY29udGVudHMuZ2V0X3ZhbGZtdCgyKSwKCQkJCXJlc3VsdC5jb250ZW50cy5nZXRfdmxp c3QoMiwgaW5zdGFuY2UpLAoJCQkJZGVzY3NbMl0uY29udGVudHMudHlwZSwgUE1fVFlQRV9GTE9B VCkKICAgIHByaW50X2xvYWQoYXZlcmFnZXNbMF0uZiwgYXZlcmFnZXNbMV0uZiwgYXZlcmFnZXNb Ml0uZikKCiAgICBjb250ZXh0LnBtRnJlZVJlc3VsdChyZXN1bHQpCgppZiBfX25hbWVfXyA9PSAn X19tYWluX18nOgogICAgdXB0aW1lKCkK ------=_Part_17558314_369865671.1391408924234-- From nscott@redhat.com Mon Feb 3 02:55:11 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 459F77F5D for ; Mon, 3 Feb 2014 02:55:11 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 151D18F8037 for ; Mon, 3 Feb 2014 00:55:07 -0800 (PST) X-ASG-Debug-ID: 1391417702-04bdf0121ebf6d0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id f6vrFDvUWGBwijtP for ; Mon, 03 Feb 2014 00:55:02 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s138t2qZ000460; Mon, 3 Feb 2014 03:55:02 -0500 Date: Mon, 3 Feb 2014 03:55:02 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: pcp@oss.sgi.com Message-ID: <1582655005.17610093.1391417702242.JavaMail.root@redhat.com> In-Reply-To: References: <1288830274.15173866.1390972567394.JavaMail.root@redhat.com> <2079478185.15183762.1390974204857.JavaMail.root@redhat.com> <850081097.15891604.1391033712900.JavaMail.root@redhat.com> Subject: Re: Multi-lib support problem & possible fix MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Multi-lib support problem & possible fix Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: Multi-lib support problem & possible fix Thread-Index: psaUaQnOCjQZO7fRfpZNSS5VtrpLuQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1391417702 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144779 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hey Frank, ----- Original Message ----- > > Hi, Nathan - > > >> If the pcp sources we ship continue working, and our pmdas continue > >> installing, that's good enough. > > > > No, thats not good enough IMO - we need to take steps to prevent > > breakage to out of tree PMDAs too. There are very valid reasons > > for being out-of-tree - like proprietary h/ware monitoring libs, > > etc [...] > > Out-of-tree developers need to stay involved in the community, so we > can know what their actual needs are, what the actual impact of > changes would be. Still no. We have no place putting demands on out-of-tree developers in terms of what they "need" to do. We provide a mechanism which we've documented as the Right Way to implement and install PMDAs and the onus is 100% on us to now maintain that and not break anything in our stable release series. Think of the developers of PMDAs which extract instrumentation from an in-house application, using some custom export (say, predating MMV) - they have every reason to expect stable PCP upgrades to (continue to) work. And they have no reason to expect to be involved with upstream work to keep their existing setup working. We can choose to redo this whole process (PMDA Install), but that then becomes major (pcp v4, v5, ...) release material. This level of small packaging issue is not the sort of thing I'd really want to trigger the onset of such a major disruption to the installed base - the numbers are all wrong. Small number of people care, relatively small advances, but large numbers of people disrupted. FWIW, the mindset I use is "if I had to do a live upgrade to thousands of production machines with this new code, do I expect it to continue to work everywhere? And/or would I be happy to get called at 2am (by an annoyed, sleepy sysadmin colleague) to start fixing the potentially catastrophic mess I just caused when it was rolled out?" Then extend those questions beyond self, to cover every user of pcp on this (stable) release series, and all of their deployment scenarios. > If we don't have access to code to test, or other > information, and no consultation, we can't allow ourselves to stop. *nod* - definitely no need to stop - we even have one other possible (and backward-compatible) solution here already, no doubt there are others - we just need to be creative. > > [...] those build files are part of the PMDA Install runtime for > > some PMDAs. > > Identical files are permitted to be included in more than one RPM. So > if some of these build-configuration files are required to just > install a PMDA (btw does it have to be that way?), we could also (for this stable release series, yes, it certainly does. for future release series, wider consultation & discussion would be needed - but sure, it could be changed) > include those build-configuration files in the per-arch package that > contains the PMDAs. Those are not -libs nor -libs-devel, so we don't > have to worry about multi-lib issues. Starting to sound a bit like that original plan I'd described ... I'll experiment with something along those lines shortly, and report back. > > I also overlooked the *link-only* requirements some PMDAs have had > > in the past (database PMDAs were the classic case) - which means > > that a full -devel install is not required to still make use of > > builddefs and a PMDA makefile after all (as we thought yesterday). > > -devel is a heavy-weight install too, so not a package I'd want as > > part of every server install - we should not force that onto folks. > > For code that requires linking *or* full compilation, -devel > requirements are traditional and appropriate. Folks stuck with such > PMDAs, who cannot accept the 700 kilobytes of pcp-libs-devel but do > accept 22 megabytes for binutils, Or ... some other sizes - hey, pmdarpm will know! ;) $ pminfo -f rpm.size | egrep '"coreutils|"pcp-libs-devel' inst [863 or "pcp-libs-devel-3.8.13-1.x86_64"] value 1766815 inst [1002 or "coreutils-libs-8.4-19.el6.x86_64"] value 5576 inst [1656 or "coreutils-8.4-19.el6.x86_64"] value 12847030 > ... could perhaps compile on one machine and ship linked binaries > around. *nod* - good points indeed. The mentality may have originated in old-skool Unixen (IRIX) where the linker was always available but not necessarily an entire cc toolchain (and cc was licensed, as in "fork out cash to use it"). Anyway, all academic at this stage... it turns out moving builddefs & co into -libs-devel doesn't help us after all - we're requested to make -libs-devel multilib also (which introduces other, different challenges). Thanks for the input! cheers. -- Nathan From wwwrun@oss.sgi.com Mon Feb 3 03:19:24 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,NO_RELAYS autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: by oss.sgi.com (Postfix, from userid 30) id D68E27FE1; Mon, 3 Feb 2014 03:19:24 -0600 (CST) From: bugzilla-daemon@oss.sgi.com To: pcp@oss.sgi.com Subject: [Bug 1046] pmlogger heavy duplication in .meta output Date: Mon, 03 Feb 2014 09:19:23 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Classification: Unclassified X-Bugzilla-Product: pcp X-Bugzilla-Component: pcp X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: nathans@debian.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: pcp@oss.sgi.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: multipart/alternative; boundary="1391419164.FAD662.21203"; charset="us-ascii" X-Bugzilla-URL: http://oss.sgi.com/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 --1391419164.FAD662.21203 Date: Mon, 3 Feb 2014 03:19:24 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" http://oss.sgi.com/bugzilla/show_bug.cgi?id=1046 Nathan Scott changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nathans@debian.org --- Comment #3 from Nathan Scott --- (In reply to comment #2) > From having dipped into the code, we'd need to do a couple of things: > [...] OK, sounds tricky but promising. > The changing-the-definition part merits thought about how we envision > handling smallish changes to the archive format. Must we bump > archive-major-version numbers? Sounds very likely, based on my understanding of your description. > Or can we tolerate old version > tools to slightly misbehave on newer data (as opposed to refusing to > process them outright)? Depends on the definition of "slightly misbehave", but it certainly sounds like a format version bump would be required and a planned transition will be needed. That's easily doable though, even in a stable series... opt-in initially (e.g. pmlogger command line arg to enable it, and defaulting to back-compatible v2 format) until a future major release where it could become default. cheers. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. --1391419164.FAD662.21203 Date: Mon, 3 Feb 2014 03:19:24 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" changed bug 1046
What Removed Added
CC   nathans@debian.org

Comment # 3 on bug 1046 from 
(In reply to comment #2)
> From having dipped into the code, we'd need to do a couple of things:
> [...]

OK, sounds tricky but promising.

> The changing-the-definition part merits thought about how we envision
> handling smallish changes to the archive format.  Must we bump
> archive-major-version numbers?

Sounds very likely, based on my understanding of your description.

>  Or can we tolerate old version
> tools to slightly misbehave on newer data (as opposed to refusing to
> process them outright)?

Depends on the definition of "slightly misbehave", but it certainly sounds like
a format version bump would be required and a planned transition will be
needed.  That's easily doable though, even in a stable series... opt-in
initially (e.g. pmlogger command line arg to enable it, and defaulting to
back-compatible v2 format) until a future major release where it could become
default.

cheers.

You are receiving this mail because:
  • You are on the CC list for the bug.
  • You are the assignee for the bug.
--1391419164.FAD662.21203-- From wwwrun@oss.sgi.com Mon Feb 3 14:12:32 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,NO_RELAYS autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: by oss.sgi.com (Postfix, from userid 30) id 0D58A7FFA; Mon, 3 Feb 2014 14:12:32 -0600 (CST) From: bugzilla-daemon@oss.sgi.com To: pcp@oss.sgi.com Subject: [Bug 1046] pmlogger heavy duplication in .meta output Date: Mon, 03 Feb 2014 20:12:31 +0000 X-Bugzilla-Reason: CC AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Classification: Unclassified X-Bugzilla-Product: pcp X-Bugzilla-Component: pcp X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: kenj@internode.on.net X-Bugzilla-Status: NEW X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: pcp@oss.sgi.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: multipart/alternative; boundary="1391458352.768Cda3.2810"; charset="us-ascii" X-Bugzilla-URL: http://oss.sgi.com/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 --1391458352.768Cda3.2810 Date: Mon, 3 Feb 2014 14:12:32 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" http://oss.sgi.com/bugzilla/show_bug.cgi?id=1046 --- Comment #4 from Ken McDonell --- Frank, thanks for the investigation. Your plan matches what I expected would be involved. > - change lipcp/src/logmeta.c addindom and/or searchindom to merge > rather than replace new instlist/namelist entries Are you suggesting reconstructing the temporal series of indom sets as per the current format? I have always been concerned that this is a huge VM soak for any application that opens an archive with a big, dynamic indom. If we're going to attack this area, perhaps we should consider a more efficient data structure and processing algorithms ... certainly lazy instantiation is an option and because this data is often not used at all (the application is interested in some _other_ metric from the archive) or the common use involves mapping internal instance ids to external instance names at some point in time. > - change pmlogger/src/callback.c log_callback to handle the needindom=1 > case's numval^2 search with more finesse, that is to identify missing > inst#'s individually, and emit a smaller incremental __pmLogPutInDom. > > (We are assuming that instance strings never change. That's not quite > correct: proc.* pid<->name strings should vary as processes exec(), > but the linux_proc pmda happens not to track that.) Since you need to identify new instances and dropped instances, I am not sure this can be done better than a 2*O(numval) algorithm. I don't follow the reference to strings ... it is the internal instance id's that matter so I think this should be a search and mark operation over a set of integer keys. And I'm with Nathan, bump the archive version number to V.3 to accommodate the migration. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. --1391458352.768Cda3.2810 Date: Mon, 3 Feb 2014 14:12:32 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 4 on bug 1046 from 
Frank, thanks for the investigation.

Your plan matches what I expected would be involved.

> - change lipcp/src/logmeta.c addindom and/or searchindom to merge
>  rather than replace new instlist/namelist entries

Are you suggesting reconstructing the temporal series of indom sets as per the
current format?  I have always been concerned that this is a huge VM soak for
any application that opens an archive with a big, dynamic indom.  If we're
going to attack this area, perhaps we should consider a more efficient data
structure and processing algorithms ... certainly lazy instantiation is an
option and because this data is often not used at all (the application is
interested in some _other_ metric from the archive) or the common use involves
mapping internal instance ids to external instance names at some point in time.

> - change pmlogger/src/callback.c log_callback to handle the needindom=1
>   case's numval^2 search with more finesse, that is to identify missing
>   inst#'s individually, and emit a smaller incremental __pmLogPutInDom.
>
> (We are assuming that instance strings never change.  That's not quite
> correct: proc.* pid<->name strings should vary as processes exec(),
> but the linux_proc pmda happens not to track that.)

Since you need to identify new instances and dropped instances, I am not sure
this can be done better than a 2*O(numval) algorithm.  I don't follow the
reference to strings ... it is the internal instance id's that matter so I
think this should be a search and mark operation over a set of integer keys.

And I'm with Nathan, bump the archive version number to V.3 to accommodate the
migration.

You are receiving this mail because:
  • You are on the CC list for the bug.
  • You are the assignee for the bug.
--1391458352.768Cda3.2810-- From fche@redhat.com Mon Feb 3 15:34:23 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 80E077FF0 for ; Mon, 3 Feb 2014 15:34:23 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 19FA3AC003 for ; Mon, 3 Feb 2014 13:34:22 -0800 (PST) X-ASG-Debug-ID: 1391463258-04bdf0121ddabe0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id iVgx9FW5hXzreJhi for ; Mon, 03 Feb 2014 13:34:19 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s13LYEsC022544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Feb 2014 16:34:14 -0500 Received: from fche.csb (vpn-234-16.phx2.redhat.com [10.3.234.16]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s13LYDuS030111; Mon, 3 Feb 2014 16:34:13 -0500 Received: by fche.csb (Postfix, from userid 2569) id BC71858103; Mon, 3 Feb 2014 16:34:12 -0500 (EST) Date: Mon, 3 Feb 2014 16:34:12 -0500 From: "Frank Ch. Eigler" To: pcp@oss.sgi.com, kenj@internode.on.net Subject: archive format history, was Re: [Bug 1046] pmlogger heavy duplication in .meta output Message-ID: <20140203213412.GB6491@redhat.com> X-ASG-Orig-Subj: archive format history, was Re: [Bug 1046] pmlogger heavy duplication in .meta output References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1391463259 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi, Ken - > > - change lipcp/src/logmeta.c addindom and/or searchindom to merge > > rather than replace new instlist/namelist entries > Are you suggesting reconstructing the temporal series of indom sets > as per the current format? I was talking more about representation on disk, as opposed to a particular reading/caching algorithm. > [...] If we're going to attack this area, perhaps we should > consider a more efficient data structure and processing algorithms > ... certainly lazy instantiation is an option and because this data > is often not used at all [...] Righto. Curious about another aspect of the history. Can someone explain how come we ended up with a .meta file that's separate from the main volume? The records could be intermingled in one (the pmFetch PDU's might just need a tag prefix, or maybe not even that). Both sets accumulate timewise. If the .meta data is a small fraction of the total, it could be replicated in subsequent volumes without much fuss. So why a separate file? If we had the meta+metric data together, we could have instantly a pipe/streaming format - something we've wanted for special PMDA purposes, but could come in handy in other ways. - FChE From nscott@redhat.com Mon Feb 3 17:19:35 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 697787F9F for ; Mon, 3 Feb 2014 17:19:35 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 5D350304082 for ; Mon, 3 Feb 2014 15:19:35 -0800 (PST) X-ASG-Debug-ID: 1391469569-04cbb00c29cadc0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id tlhpLsRQ3tFVtWln for ; Mon, 03 Feb 2014 15:19:30 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s13NJTpK019294; Mon, 3 Feb 2014 18:19:29 -0500 Date: Mon, 3 Feb 2014 18:19:29 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Dave Brolley Cc: PCP Message-ID: <1816751253.18456831.1391469569087.JavaMail.root@redhat.com> In-Reply-To: <683908729.18452164.1391468197324.JavaMail.root@redhat.com> Subject: pmie vs local: - not going the af_unix route by default MIME-Version: 1.0 X-ASG-Orig-Subj: pmie vs local: - not going the af_unix route by default Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: pmie vs local: - not going the af_unix route by default Thread-Index: Tm3LTX7lEeJoyAxL6GFzPsVvkwu+BQ== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1391469570 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, DOMAIN_4U2, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144803 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 DOMAIN_4U2 URI: Domain name containing a "4u" variant 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi Dave, As mentioned on IRC, pmie doesn't appear to use local: connection by default - looks like a hostname is associated with each metric at some point, and that is used when it comes to the crunch of fetching values for a metric (instead of the local: context which we do also establish earlier on in argument parsing, it seems). There's a pmie config in the IRC log below that shows the problem using the proc metrics (which give permission errors when no auth info available). A gdb breakpoint on pmNewContext shows where we start wandering off the expected path. So, removing :'local:' in that config (explicit host) shows the problem - as-is, the config below *does* do an af_unix connection because of that workaround. cheers. i want to count the number of httpd processes in pmie so I thought of something like this (count_inst > 5 && match_inst "httpd") ah, and using the proc.* metrics? not sure if I am using count_inst corerctly yes yeah, i'd be surprised if count_inst does what you want there hmmm (thinking, thinking) so far, the only way i can think of doing (using stock pcp code) it is via a pmie rule with match_inst, then using %i in the rule evaluation, then counting the passed-in arguments in the action (shell script) a couple of more involved approaches would be to use the cgroups support in current pmdaproc, if you can ensure all httpd processes start in a named cgroup or, resurrecting pmdahotproc (src/pmdas/hotproc) (match_inst "httpd" proc.cmd ) -> print "httpd procs %i"; tried that, syntax error - near line 11 of file status.pmie logical expression expected to follow regular expression can you show me an example of count_inst ? yeah, thats not a valid pmie expression I realise that see the man page example, i.e. match_inst "^dks[23]d" disk.dev.total > 20; yes. just that proc.psinfo.cmd is text something like this might work... match_inst "bash" proc.psinfo.pid > 0; s/bash/httpd mm, that gives and error in pmie, but works on pminfo Instance domain for metric proc.psinfo.pid from host hr1.dev.m4u.com.au not (currently) available pmGetIndom failed: No permission to perform requested operation yeah, just looking into that atm ok, some progress ... hang on a tick I think if I can use proc.psinfo.threads, I will get what I need ok, this works... cat /tmp/pmie some_inst ( match_inst ".*bash" proc.psinfo.pid :'local:' > 0 ) -> print " '%i',pid=%v"; pmie -c /tmp/pmie -t 1 -v -v -e Tue Feb 4 09:05:43 2014: '010766 bash',pid=10766 '011349 bash',pid=11349 '015594 -bash',pid=15594 expr_1 (Tue Feb 4 09:05:43 2014): true Tue Feb 4 09:05:44 2014: '010766 bash',pid=10766 '011349 bash',pid=11349 '015594 -bash',pid=15594 expr_1 (Tue Feb 4 09:05:44 2014): true ah thanks np - the local: bit there resolves the permissions issue not really sure why thats not happening by default, i'll need to dig into that ok, that makes sense that worked good stuff -- Nathan From kenj@internode.on.net Tue Feb 4 16:37:28 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id D74F37F51 for ; Tue, 4 Feb 2014 16:37:28 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 9B38B8F8040 for ; Tue, 4 Feb 2014 14:37:28 -0800 (PST) X-ASG-Debug-ID: 1391553443-04bdf0121d129ad0001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id tCi7JWYfZhWpypKF for ; Tue, 04 Feb 2014 14:37:23 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjOVAFJr8VJ20SXkPGdsb2JhbABZgwyDPoUMpBOSSQMCgQ4XAwEBAQE4NYIlAQEEAQgCHhIcHAwIAwIGA0YZIAoUAgQBHQUJAodiB84qF458hDgEjymdEoFSKA Received: from ppp118-209-37-228.lns20.mel4.internode.on.net (HELO bozohorize) ([118.209.37.228]) by ipmail06.adl6.internode.on.net with ESMTP; 05 Feb 2014 09:07:19 +1030 From: "Ken McDonell" To: "'Frank Ch. Eigler'" , References: <20140203213412.GB6491@redhat.com> In-Reply-To: <20140203213412.GB6491@redhat.com> Subject: RE: archive format history, was Re: [Bug 1046] pmlogger heavy duplication in .meta output Date: Wed, 5 Feb 2014 09:37:17 +1100 X-ASG-Orig-Subj: RE: archive format history, was Re: [Bug 1046] pmlogger heavy duplication in .meta output Message-ID: <000001cf21f9$a967a8f0$fc36fad0$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQD6XDahYCyu5yw1Yqk+370zR3zIAwEjV14/AcAABeCcOBhdcA== Content-Language: en-au X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1391553443 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144842 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== G'day Frank. More History 101 below ... 8^)> > > > - change lipcp/src/logmeta.c addindom and/or searchindom to merge > > > rather than replace new instlist/namelist entries > > > Are you suggesting reconstructing the temporal series of indom sets as > > per the current format? > > I was talking more about representation on disk, as opposed to a particular > reading/caching algorithm. Hmm ... then I don't understand what "merge" means in the original suggestion. Can you provide a bit more detail of your thoughts? > Curious about another aspect of the history. Can someone explain how > come we ended up with a .meta file that's separate from the main volume? > The records could be intermingled in one (the pmFetch PDU's might just > need a tag prefix, or maybe not even that). Both sets accumulate timewise. > If the .meta data is a small fraction of the total, it could be replicated in > subsequent volumes without much fuss. > So why a separate file? Both the .meta and the .N files may grow over the period of pmlogger's life (remember pmlc can dramatically effect what is being logged, although most of the recent attention has been devoted to dynamic instance domains and indom bloat in the .meta files ... something that was not possible in the early days due to restrictions on the proc pmda, but that is another story). Now, the only operating system I know (and love) that offers a file system that supports multiple growing logical segments within the one file container is the Michigan Terminal System (MTS) that was an OS/360 alternative in the days before Unix escaped from Bell Labs. So with the file systems we have to work with, the only option would be to have variant records in the one file and intermix the metadata and pmResult data. But the metadata includes the PMNS and the metric descriptors and if there was a single data stream all applications would have to read and process EVERY record in the archive before they could answer the simplest questions about the PMNS or the metric descriptors. Given the expected relative size of the metadata compared to the archive in toto (one, two, three or four orders of magnitude), it was felt that the cost of reading all of the data to extract the metadata was excessive. To expedite random access into the archives we have an index, the .index file, and this also grows over the life of pmlogger. If the metadata was combined with the pmResult data then one needs to consider what to do with the index data ... putting it in the one file is a waste of time unless you have MTS and the ability to create a third growing segment in the file (if you need to read the file to extract the index, you don't need the index!), else put the index in another file, at which point the archive becomes multi-file and a separate .meta file makes life only a very little more difficult. I still think this is the _right_ solution for Unix/Linux style file systems. Of course if there was a free, fast, multi-platform, reliable DBMS at the time we designed the PCP archive format it may not have evolved as files in the filesystem ... but it is not clear to me that this would have solved more problems than it would have created (our data does not map well onto the relational model, so we'd probably ended up with binary blobs for all the stuff that really mattered and the DB infrastructure would not have provided much leverage). > If we had the meta+metric data together, we could have instantly a > pipe/streaming format - something we've wanted for special PMDA > purposes, but could come in handy in other ways. What are the "special PMDA purposes"? The PMDA operates with a pull model, so the data stream is defined by the client request sequence ... when being read, not written, PCP archives are subjected to the same operational semantics in terms of the client request sequence. The "across the API" behaviour for a client is the same for PMCD (and so PMDA) and archives and this is an intermixed sequence of data types, but I don't think of this a streaming or pipe semantics. I am interested to hear more .... From nscott@redhat.com Tue Feb 4 21:09:58 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id E792B7F51 for ; Tue, 4 Feb 2014 21:09:58 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id A84EA8F804C for ; Tue, 4 Feb 2014 19:09:55 -0800 (PST) X-ASG-Debug-ID: 1391569793-04bdf0121f13c0e0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id qkSPq7IHwsGHWCGw for ; Tue, 04 Feb 2014 19:09:54 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1539rmI022092 for ; Tue, 4 Feb 2014 22:09:53 -0500 Date: Tue, 4 Feb 2014 22:09:53 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp@oss.sgi.com Message-ID: <57528932.19502818.1391569793059.JavaMail.root@redhat.com> Subject: pcp updates: docs, pmdammv fix MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: docs, pmdammv fix Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: pcp updates: docs, pmdammv fix Thread-Index: i44c6u5IufaGefXfZe+fksvaC7Y09w== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1391569794 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144850 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev man/man1/pmclient.1 | 13 ++----------- qa/213 | 23 +++++++++++++++++++++-- qa/646 | 26 +++++++++++++++++++++++--- src/libpcp_pmda/src/tree.c | 3 +++ src/pmclient/GNUmakefile | 8 +++++--- src/pmclient/README | 22 ++++++++++++---------- src/pmclient/pmlogger.config | 16 ++++++++++++++++ src/pmdas/mmv/src/mmv.c | 26 +++++++++++++++++++++----- 8 files changed, 103 insertions(+), 34 deletions(-) commit 7f7a5ccc11231c4349026b295e321e5d9ad01095 Author: Nathan Scott Date: Wed Feb 5 14:05:26 2014 +1100 Resolve pmdammv sigsegv when no MMV tempdir present There were situations where we could call into the PMDA tree code (dynamic namespaces) with a NULL pmns pointer, which it would dereference. Add checks to that code (as other tree API calls have already) and ensure pmdammv no longer calls it in this anti-social way. QA tests 213 and 646 updated to function with a missing MMV temporary directory as well. commit 9b6d8dc797da00721509ed4036f864a957fff1d5 Author: Nathan Scott Date: Tue Feb 4 10:41:40 2014 +1100 Update MMV test to work after new install with no MMV tmpdir state commit 96f8fc9cf03c09ab8e07c2bcae4603f14b87b626 Author: Nathan Scott Date: Tue Feb 4 10:38:40 2014 +1100 Updates to pmclient after reading the PCP_PG examples section From fche@redhat.com Tue Feb 4 22:14:33 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id CF9687F51 for ; Tue, 4 Feb 2014 22:14:32 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 60B85AC003 for ; Tue, 4 Feb 2014 20:14:29 -0800 (PST) X-ASG-Debug-ID: 1391573664-04cbb00c2b12d450001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id qJZweqkKvAFSlR1R for ; Tue, 04 Feb 2014 20:14:25 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s154EKwW010732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Feb 2014 23:14:20 -0500 Received: from fche.csb (vpn-234-16.phx2.redhat.com [10.3.234.16]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s154EJRq027877; Tue, 4 Feb 2014 23:14:20 -0500 Received: by fche.csb (Postfix, from userid 2569) id 59F0958110; Tue, 4 Feb 2014 23:14:19 -0500 (EST) Date: Tue, 4 Feb 2014 23:14:19 -0500 From: "Frank Ch. Eigler" To: Ken McDonell Cc: pcp@oss.sgi.com Subject: Re: archive format history, was Re: [Bug 1046] pmlogger heavy duplication in .meta output Message-ID: <20140205041419.GC6491@redhat.com> X-ASG-Orig-Subj: Re: archive format history, was Re: [Bug 1046] pmlogger heavy duplication in .meta output References: <20140203213412.GB6491@redhat.com> <000001cf21f9$a967a8f0$fc36fad0$@internode.on.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001cf21f9$a967a8f0$fc36fad0$@internode.on.net> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1391573665 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi, Ken - > More History 101 below ... 8^)> Thanks! > > I was talking more about representation on disk, as opposed to a > > particular reading/caching algorithm. > > Hmm ... then I don't understand what "merge" means in the original > suggestion. Can you provide a bit more detail of your thoughts? (With respect to instance-domain updates, that each record could be differential to the one in effect at the previous timestamp. I used "merge" when perhaps I should have used "diff" and "patch" instead.) > [...] > > So why a separate [.meta] file? > > [...] > Now, the only operating system I know (and love) that offers a file system > that supports multiple growing logical segments within the one file > container is the Michigan Terminal System (MTS) that was an OS/360 > alternative in the days before Unix escaped from Bell Labs. Careful -- you might start dating yourself! > So with the file systems we have to work with, the only option would > be to have variant records in the one file and intermix the metadata > and pmResult data. But the metadata includes the PMNS and the > metric descriptors and if there was a single data stream all > applications would have to read and process EVERY record in the > archive before they could answer the simplest questions about the > PMNS or the metric descriptors. [...] Understood. That scanning EVERY record business could be beaten if the PMNS/metric/indom data were located in convenient spots. For example, if they were generally interleaved with pmResult data in time order but also replicated at predictable places such as the end of the file, and contained links (file offsets) to earlier metadata records, then a complete metadata-only search could take O(number-of-metadata-updates) rather than O(number-of-pmResults). > To expedite random access into the archives we have an index, the .index > file, and this also grows over the life of pmlogger. If the metadata was > combined with the pmResult data then one needs to consider what to do with > the index data ... putting it in the one file is a waste of time unless you > have MTS and the ability to create a third growing segment in the file (if > you need to read the file to extract the index, you don't need the index!), > [...] Again, it depends where the index is placed. If it's in predictable locations, one can eschew the full scan. > I still think this is the _right_ solution for Unix/Linux style file > systems. It's been a fine solution. I'm wondering whether the benefits we'd get from a streamable format would be worth the moderate complexity. > Of course if there was a free, fast, multi-platform, reliable DBMS > at the time we designed the PCP archive format [...] we'd probably > ended up with binary blobs for all the stuff that really mattered > and the DB infrastructure would not have provided much leverage). Right. > > If we had the meta+metric data together, we could have instantly a > > pipe/streaming format - something we've wanted for special PMDA > > purposes, but could come in handy in other ways. > > What are the "special PMDA purposes"? [...] Perhaps "PMDA purposes" was misleading, sorry. Some possibilities include having tools such as systemtap, or live importers, or summary/stats engines, generate & consume archive-format streams. Perhaps it could turn out to feed a more workable version of that earlier "tail -f archive" effort Max/Greg were talking about. - FChE From nscott@redhat.com Tue Feb 4 23:25:05 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8CF4C7F51 for ; Tue, 4 Feb 2014 23:25:05 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7034F304053 for ; Tue, 4 Feb 2014 21:25:02 -0800 (PST) X-ASG-Debug-ID: 1391577900-04cbb00c281309b0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 1B9tNKSH6mIGTAOI for ; Tue, 04 Feb 2014 21:25:00 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s155OxHG020595 for ; Wed, 5 Feb 2014 00:24:59 -0500 Date: Wed, 5 Feb 2014 00:24:59 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: PCP Message-ID: <1540000956.19532876.1391577899859.JavaMail.root@redhat.com> In-Reply-To: <9727779.19530802.1391577571079.JavaMail.root@redhat.com> Subject: pcp-gui updates: gadgets (WIP) MIME-Version: 1.0 X-ASG-Orig-Subj: pcp-gui updates: gadgets (WIP) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: pcp-gui updates: gadgets (WIP) Thread-Index: kjJ1DEb/sKU7Sf6kiH9IBjWLfvc1iQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1391577900 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144853 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp-gui.git gadgets man/man1/pmchart.1 | 2 man/man1/pmgadgets.1 | 703 ++++++++++++ man/man1/pmgcisco.1 | 124 ++ man/man1/pmgcluster.1 | 133 ++ man/man1/pmgshping.1 | 164 +++ man/man1/pmgsys.1 | 196 +++ src/gadgets/pmgadgets-args.sh | 411 +++++++ src/gadgets/pmgcisco.sh | 299 +++++ src/gadgets/pmgcluster.sh | 323 +++++ src/gadgets/pmgshping.sh | 286 ++++- src/gadgets/pmgsys.c++ | 2296 +++++++++++++++++++++--------------------- src/gadgets/pmgsys.py | 380 ++++++ 12 files changed, 4086 insertions(+), 1231 deletions(-) commit 4cdc5a04f2713cf26c1109f9458a42f6e8857d70 Author: Nathan Scott Date: Wed Feb 5 16:17:04 2014 +1100 Rewrite the pmgsys application in python pmgsys was originally written as a C++ program, which made a number of things painful (esp. tweaking and extending it). Since we can now use the PMAPI in python tools, rewriting it was relatively straight forward. Biggest missing thing from this first iteration is the logic to group disks by their controllers. This is non-trivial in Linux (cmp IRIX, where the block device driver helps no end) as we do not have this mapping readily available. We may want to generalise this mapping concept too - e.g. some people may wish to show the partitions/disks mapping, others may be interested in mapping NUMA nodes to the CPUs they contain (drawing lines to link 'em). Some interesting potential anyway, and using python hopefully will encourage experimentation in this area. commit 4f991f583338e74b43cb9c0e19fad3a521aefda6 Author: Nathan Scott Date: Wed Feb 5 16:07:51 2014 +1100 Resolve symlink security vulnerabilities in gadgets scripts Nest tmp files under mktemp subdirs, as was done a couple of years ago in all other PCP scripts. Previously these scripts manipulated predictable files in /tmp allowing for symlink race vulnerabilities. commit 038972e5590f7d7c29218ab69aa92ba121ffff5e Author: Nathan Scott Date: Wed Feb 5 15:53:08 2014 +1100 Import pmgadgets frontend code as open sourced by SGI in Feb 2009. commit 887b5549708d95b89c7ac37e32df743a9949ff2f Author: Nathan Scott Date: Wed Feb 5 15:08:48 2014 +1100 Fix a teensy man page typo in pmchart.1 From bounce@bbsbusiness.com Wed Feb 5 18:39:10 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.7 required=5.0 tests=DATE_IN_PAST_06_12, HTML_MESSAGE autolearn=no version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 1B2EF7F54 for ; Wed, 5 Feb 2014 18:39:10 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 9EBCBAC003 for ; Wed, 5 Feb 2014 16:39:09 -0800 (PST) X-ASG-Debug-ID: 1391647142-04bdf0121e16ba10001-S8gJnT Received: from www.planinnova.com (mail2.planinnova.com [188.94.13.45]) by cuda.sgi.com with ESMTP id Q3E4z3G5BreOL0yb for ; Wed, 05 Feb 2014 16:39:02 -0800 (PST) X-Barracuda-Envelope-From: bounce@bbsbusiness.com X-Barracuda-Apparent-Source-IP: 188.94.13.45 Received: from www.portalaican.com ([192.168.1.44]) by www.planinnova.com with Microsoft SMTPSVC(7.0.6002.18264); Thu, 6 Feb 2014 01:38:30 +0100 To: pcp@oss.sgi.com Subject: =?UTF-8?B?Q29uc3VsdG9yIGRlIEVtcHJlc2EgQ2VydGlmaWNhZG8gU0dFIDkwMCB8IENvbXBldGVuY2lhLCBDYXBhY2lkYWQsIExlZ2l0aW1pZGFkIFByb2Zlc2lvbmFsIHkgUmVjb25vY2ltaWVudG8gfCBQcm9ncmFtYSBkZSBDZXJ0aWZpY2FjacOzbiBPZmljaWFs?= Message-ID: X-ASG-Orig-Subj: =?UTF-8?B?Q29uc3VsdG9yIGRlIEVtcHJlc2EgQ2VydGlmaWNhZG8gU0dFIDkwMCB8IENvbXBldGVuY2lhLCBDYXBhY2lkYWQsIExlZ2l0aW1pZGFkIFByb2Zlc2lvbmFsIHkgUmVjb25vY2ltaWVudG8gfCBQcm9ncmFtYSBkZSBDZXJ0aWZpY2FjacOzbiBPZmljaWFs?= Date: Wed, 05 Feb 2014 14:56:11 +0100 From: "Plan Innova" Reply-To: informacion@planinnova.com MIME-Version: 1.0 X-Mailer-LID: 115 List-Unsubscribe: X-Mailer-RecptId: 11235106 X-Mailer-SID: 314 x-job: www_portalaican_com-12581 X-Mailer-Sent-By: 3 Content-Type: multipart/alternative; charset="UTF-8"; boundary="b1_3d0108be3fd637da74962b0a461d7e8e" Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 06 Feb 2014 00:38:30.0027 (UTC) FILETIME=[C1B3E5B0:01CF22D3] X-Barracuda-Connect: mail2.planinnova.com[188.94.13.45] X-Barracuda-Start-Time: 1391647142 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.11 X-Barracuda-Spam-Status: No, SCORE=1.11 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DATE_IN_PAST_06_12, DATE_IN_PAST_06_12_2, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144878 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 DATE_IN_PAST_06_12 Date: is 6 to 12 hours before Received: date 0.00 HTML_MESSAGE BODY: HTML included in message 1.10 DATE_IN_PAST_06_12_2 DATE_IN_PAST_06_12_2 --b1_3d0108be3fd637da74962b0a461d7e8e Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Esta información contiene imágenes, si no puedes verlas pulsa aquí [http://www.portalaican.com/mmd/display.php?M=11235106&C=b95409fc5f5593c179ab83c2faffc7ad&S=314&L=115&N=221] Programa de Certificación Oficial por la Norma Referencial Internacional SGE 900 Consultor de Empresa Certificado SGE 900 El mayor reconocimiento en el mercado a nivel internacional SGE 900, mucho más que un sello o un título. Un instrumento de Trabajo de Alto Valor Añadido para obtener mayor reconocimiento y retribución profesional. Dirigido a todos aquellos profesionales dedicados a la consultoría y a nuevos profesionales que deseen dedicarse a este área de actividad, aportándoles las competencias, criterios de realización, instrumentos y destrezas necesarios para desarrollar su actividad. El Consultor de Empresa Certificado SGE 900 es un profesional cualificado y acreditado que ofrece servicios contrastados de asesoramiento profesional a gerentes, empresas y profesionales ayudándoles a alcanzar sus objetivos, realizando actividades de planificación, organización, gestión, control y mejora que optimizan e incrementan la Calidad de los procesos críticos de negocio en los diferentes niveles. Con el objetivo de contribuir significativamente a la Excelencia en los Resultados determinantes para la consolidación y Crecimiento de las empresas Un programa que te aporta: - Competencia Disponer de Conocimientos, Criterios de Realización y Destrezas sobre los requerimientos reconocidos internacionalmente en el ejercicio profesional - Capacidad Disponer de los recursos y medios tecnológicos, materiales e inmateriales para aplicar las competencias - Legitimidad Profesional Obtenida gracias a la transparencia, seguridad, Imparcialidad y objetividad del proceso de Certificación Evaluación de conocimientos, criterios de realización y destrezas por auditor competente independiente que evidencia la competencia para el ejercicio profesional - Reconocimiento Mayor reconocimiento internacional a todas las partes implicadas de la competencia, capacidad y legitimidad profesional Certificado Expedido por entidad certificadora acreditada con reconocimiento en 62 países Quiero información para participar en el Programa [http://www.portalaican.com/mmd/link.php?M=11235106&N=314&L=483&F=T] Telefono: 902 11 45 07 - Email: info@planinnova.com Plan Innova es un Clúster de Innovación promovido por Best Business Service. De conformidad con lo dispuesto en la Ley Orgánica 15/1999, de Protección de Datos Personales, le informamos que su dirección de email forma parte de un fichero informático propiedad de Best Business Service, cuya finalidad es servir como soporte de información a la gestión fiscal, administrativa, comercial y contable, así como para acciones de divulgación, información y promoción; pudiendo ejercer en cualquier momento sus derechos de acceso, rectificación, oposición y cancelación dirigiéndose por vía e-mail a info@bbsbusiness.com, manifestando su voluntad al respecto. Si no desea recibir más este boletín de noticias pulse aquí [http://www.portalaican.com/mmd/unsubscribe.php?M=11235106&C=b95409fc5f5593c179ab83c2faffc7ad&L=115&N=314] --b1_3d0108be3fd637da74962b0a461d7e8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit
 
Esta información contiene imágenes, si no puedes verlas pulsa aquí
Programa de Certificación Oficial por la Norma Referencial Internacional SGE 900
 
 
Consultor de Empresa Certificado SGE 900
 
 
 
 
El mayor reconocimiento en el mercado a nivel internacional
 
 
SGE 900, mucho más
que un sello o un título.
 
Un instrumento de
Trabajo de Alto Valor
Añadido para obtener
mayor reconocimiento y
retribución profesional.
 
Dirigido a todos aquellos profesionales dedicados a la consultoría y a nuevos profesionales que deseen dedicarse a este área de actividad, aportándoles las competencias, criterios de realización, instrumentos y destrezas necesarios para desarrollar su actividad.
 
El Consultor de Empresa Certificado SGE 900 es un profesional cualificado y acreditado que ofrece servicios contrastados de asesoramiento profesional a gerentes, empresas y profesionales ayudándoles a alcanzar sus objetivos, realizando actividades de planificación, organización, gestión, control y mejora que optimizan e incrementan la Calidad de los procesos críticos de negocio en los diferentes niveles. Con el objetivo de contribuir significativamente a la Excelencia en los Resultados determinantes para la consolidación y Crecimiento de las empresas.
 
  
 
Un programa que te aporta:
 
Competencia
Disponer de Conocimientos, Criterios de Realización y Destrezas sobre los requerimientos reconocidos internacionalmente en el ejercicio profesional
 
Capacidad
Disponer de los recursos y medios tecnológicos, materiales e inmateriales para aplicar las competencias
 
Legitimidad Profesional
Obtenida gracias a la transparencia, seguridad, Imparcialidad y objetividad del proceso de Certificación
  • Evaluación de conocimientos, criterios de realización y destrezas por auditor competente independiente que evidencia la competencia para el ejercicio profesional
Reconocimiento
Mayor reconocimiento internacional a todas las partes implicadas de la competencia, capacidad y legitimidad profesional
  • Certificado Expedido por entidad certificadora acreditada con reconocimiento en 62 países
 
  
 
Más información
 

Telefono: 902 11 45 07  - Email: info@planinnova.com
Plan Innova es un Clúster de Innovación promovido por Best Business Service. De conformidad con lo dispuesto en la Ley Orgánica 15/1999, de Protección de Datos Personales, le informamos que su dirección de email forma parte de un fichero informático propiedad de Best Business Service, cuya finalidad es servir como soporte de información a la gestión fiscal, administrativa, comercial y contable, así como para acciones de divulgación, información y promoción; pudiendo ejercer en cualquier momento sus derechos de acceso, rectificación, oposición y cancelación dirigiéndose por vía e-mail a info@bbsbusiness.com, manifestando su voluntad al respecto.
 Si no desea recibir más este boletín de noticias pulse aquí

--b1_3d0108be3fd637da74962b0a461d7e8e-- From fche@redhat.com Wed Feb 5 20:00:39 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 9A1967F54 for ; Wed, 5 Feb 2014 20:00:39 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7E18230406B for ; Wed, 5 Feb 2014 18:00:39 -0800 (PST) X-ASG-Debug-ID: 1391652035-04cb6c6de115d2c0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id TbS6mNE6g2PJIBD4 for ; Wed, 05 Feb 2014 18:00:35 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1620Y8e008776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 5 Feb 2014 21:00:34 -0500 Received: from fche.csb (vpn-234-16.phx2.redhat.com [10.3.234.16]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1620X0g018120 for ; Wed, 5 Feb 2014 21:00:34 -0500 Received: by fche.csb (Postfix, from userid 2569) id 2A48F58182; Wed, 5 Feb 2014 21:00:33 -0500 (EST) To: pcp@oss.sgi.com Subject: Re: pmmgr pmlogger default behaviour References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1583484726.15908616.1391037005341.JavaMail.root@redhat.com> <20140130181134.GA7584@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> X-ASG-Orig-Subj: Re: pmmgr pmlogger default behaviour From: fche@redhat.com (Frank Ch. Eigler) Date: Wed, 05 Feb 2014 21:00:32 -0500 In-Reply-To: <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> (Nathan Scott's message of "Thu, 30 Jan 2014 17:08:39 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1391652035 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - >> What kinds of file corruption can one expect to deal with on modern >> systems, that would affect these files so badly? Do we want to be in >> the storage-safety department just on their account? > > Oh all manner of corruption - and using a wide umbrella there for > "corruption", covering accidentally overwriting the start of a file > (which, bizarrely, happens more than I'd expect); fat-fingers on > sysadmins - accidental file removal; Considering that the pcp log/archive files are world-readable, there is little reason for a privileged user to be poking around in the directories. Fat-fingered sysadmins are in a class of risk that is better served with backups or limited accounts, not inconveniencing ordinary users. > system crash with no data flush - tail of the file corruption, etc, > etc. The last one is the most common, I think. [...] The inputs to merging are cleaned up by pmmgr only after the merging processes successfully complete. If that completion is premature in your sense, then we must add an fsync()-equivalent into the various archive-generating tools at their exit/close time. This is independent of pmmgr. >> [...] I know of no modern file processing tool that deliberately >> slices up its own data, just to protect it from unspecified >> hypothetical breakage. > For example all modern filesystems do this sort of thing - putting > multiple copies of critical data structures all over the place, and > going to great lengths to keep them at arms length from each other > for recovery purposes We weren't talking about replicating or checksumming, which we don't do ourselves. We were talking about artificially slicing up data, hoping to isolate damage to individual chunks. Not many filesystems do this, to my knowledge; in fact many deliberately put related data (inodes+blocks/directory-entries) as close to each other as practical for speed. Databases don't do this either AFAIK - they assume reliable storage. I'm also unaware of analogous system-log-type data being cut up this way specifically against fat-fingered sysadmins. > There is a huge difference between losing one days worth of data vs > two weeks+. The + is because current pmmgr scheme loses more and > more data as the collection period is increased, whereas thats not > the case for pmlogger_daily. No, the pmmgr scheme "loses" (present tense?!) no data: pmmgr instead preserves data in its original form in case of errors. What can lose data are hypothetical manual administrative interference or hardware/OS failures, both of which are non-pcp-specific and thus have traditional procedures to deal with. > [...] Something else that just occurred to me is that the pmmgr > model of changing *every single archive* involved, *every single > day* further increases the loss risk. [...] No, pmmgr does not "change" archives in the sense of rewriting or modifying them. pmmgr's "pmlogmerge" option creates *new ones*. The extra disk I/O does represent additional I/O but not casual corruption risk. (If one cannot trust one's kernel to write new files of a hundred megabytes once a day, without losing parts, one needs to switch to linux. :-) This thread hardly acknowledged the fact that there is a trade-off being discussed here. The positive side is that merging makes it easy for a PCP user to use the data. She doesn't have to remember how to splice it together; to play with multiple -a options or comma-separated -a suboptions; or clumsy gui dialog boxes; or manual pmlogextract steps. It's already in one convenient chunk for instant gratification. It's as close to "grand-unified" as we can get to today. I believe there is value in making convenient defaults new PCP users. It's the defaults of a new tool we're talking about, not changing the behaviors of the ones that established installations have gotten accustomed to (and are quite capable of overriding defaults). In that context, let's not be afraid to experiment with more sophisticated defaults in the future too, as long as they maximize new-user utility. - FChE From nscott@redhat.com Thu Feb 6 03:59:22 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 7F1DE7F53 for ; Thu, 6 Feb 2014 03:59:22 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 2887A8F804B for ; Thu, 6 Feb 2014 01:59:19 -0800 (PST) X-ASG-Debug-ID: 1391680757-04bdf0121f17b7e0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id jVLKptU66m9VRLjn for ; Thu, 06 Feb 2014 01:59:17 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s169xG47031580; Thu, 6 Feb 2014 04:59:16 -0500 Date: Thu, 6 Feb 2014 04:59:16 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: pcp@oss.sgi.com Message-ID: <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> In-Reply-To: References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1583484726.15908616.1391037005341.JavaMail.root@redhat.com> <20140130181134.GA7584@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> Subject: Re: [pcp] pmmgr pmlogger default behaviour MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmmgr pmlogger default behaviour Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: pmmgr pmlogger default behaviour Thread-Index: QE5AfEkyT7VS8o6v0MFCmRLuTm5UvA== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1391680757 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144887 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi Frank, Phew, this one is going on and on too. Onward... ----- Original Message ----- > ... > No, pmmgr does not "change" archives in the sense of rewriting or > modifying them. pmmgr's "pmlogmerge" option creates *new ones*. The *nod* I understand what its doing, my choice of words in "change" was poor, sorry. What I meant was at the end of that pmlogmerge every single byte in the (new) wun beeg log is different to what was in the file of the same name on the day before. Same data at different offsets == different data to backup tools, cp, whatever is reading it. This is very important - in fact, I can't think of any example of a log-file-tool that behaves this way (chops off the start and adds to the end of a data stream, then writes out the entire data stream, every day for all of recorded history)? Always, in the ones I can think of, they use rotation to a new file and only the most recently written data is ever in-flight. [ sar, argus, syslog, log4j, pcp ... examples of the more regular style of log rotation from the production environments I know - none ever write the entire contents of the file since recording begins, each and every day ] > This thread hardly acknowledged the fact that there is a trade-off > being discussed here. The positive side is that merging makes it easy Well, in my defence, that's not really true - my exact words were: "There are advantages & disadvantages to this. The advantage is we get a single archive (well, except for todays data) which means the tools can directly operate on more than a single days worth of data. And that is great!!!" Count 'em - that's three exclamation marks! It really is great!!! So, I understand full well this advantage and did acknowledge it, honest! Conversely, there's been no acknowledgement that there are zero advantages to wun-beeg-log should libpcp be extended to support transparent multi-archives, as is planned. Zero. None. Nada. Zip. Anyway - I was convinced then, and am increasingly convinced, that the disadvantages far, far outweigh that one advantage. Don't get me wrong - initially I thought this was a great feature too! But then the subtle issues started to dawn. I must not have explained my concerns well. Let me try a different tack using a real (really real, not some hypothetical) production example from a real system serving a small-medium-size web presence. Within one data centre we'd typically use the centralised logging setup as laid out in the book. A logger server with roughly 20-30 hosts being logged close by it (same rack, or pair of racks), all closely co-operating hosts so often need to be analysed together. Each host would have a daily log size in the order of 100-200MB depending on its function (well instrumented applications, so much bigger logs there). Its critical performance data, losing it is bad, bad news (KPI reports that customers see are driven by this, not to mention regular problem analysis and fire-fighting) but at the same time we cannot be putting more than a minimal load on all systems under observation (including the logger host: resources are tight!). So, at least twenty hosts * 100MB per day, often alot more. Merging logs for 1 day of that size is not a problem, any host can do it (i.e. no special memory/storage configuration needed). And the length of time we retain data for has no impact on this, the default PCP setup. Now, lets imagine the logger host begins using a wun beeeeg log model. >100MB * 14 days == >1GB per host in steady state (so after the first 14 days, we need to manage merging this amount of data every day for every host). The log merging for all 20 hosts happens around the same time (it needs to, out of business hours), so while we're merging the >20GB worth of data (i.e. read(2) >20GB into the page cache, write(2) it out to a new file with todays data appended, but the earliest day removed) - 20GB clean data, another 20GB dirty to the new file; => significant page cache pressure, significant read and write I/O; => significant impact on this system. Now we have >20GB of dirty data to writeout. That data is all dirty and it covers everything we have logged to date, if we lose it we are toast. As an aside - yet another subtle problem - note here that our merging efforts require *twice* as much ondisk space to hold all the data for the temporary merge file (which becomes the new file in the end) alongside the existing data - temporarily, but still need that space. Anyway, there's a big window in there where all of our data (and the metadata about our data) is in-flux. We are at hugely increased risk no matter how you slice and dice this (yes, can reduce the risk with fsyncs, but its not entirely removed). TBH, its hard to conjure up a worse I/O pattern than we have created for ourselves here. OTOH, the other scheme is near-optimal - no merging at all if there's just the one log, which is the typical case (ie no pmcd/pmlogger restarts on that day), otherwise only small amounts of I/O of the latest data. Now, extend - consider those folks who think "hey, a 2 weeks default is not for me, I want to keep 2 months worth of data here". Extend again, 20 hosts? Bah, I need 120 hosts for this upcoming launch of a product. So, the behaviour of the wun-beeg-log scheme gets worse and worse - in every way I can think of. Storage, memory, potential data loss - we even manage to burn more CPU time merging, every day, than we used to. > for a PCP user to use the data. She doesn't have to remember how to > splice it together; to play with multiple -a options or > comma-separated -a suboptions; or clumsy gui dialog boxes; or manual > pmlogextract steps. It's already in one convenient chunk for instant > gratification. It's as close to "grand-unified" as we can get to today. That's not the case - one could set up a daily task that creates a summary-style archive, taking the most important metrics from the daily logs each day, and producing one merged archive from them to summarise the last week or month. Using existing tools - people do this sort of thing. But, we have better plans for the future, lets keep attacking those. > I believe there is value in making convenient defaults new PCP users. *nod*, certainly. > It's the defaults of a new tool we're talking about, not changing the > behaviors of the ones that established installations have gotten > accustomed to (and are quite capable of overriding defaults). In that > context, let's not be afraid to experiment with more sophisticated > defaults in the future too, as long as they maximize new-user utility. My main fear here is for the data loss this scheme will induce. But there are many other fears too - both Ken and I listed several more. So there's no fear of experimentation - its welcome and a wonderful thing. But with that experimentation we need to reflect after each experiment, and see what has worked well and what hasn't ... in this case we need to change the defaults to provide an acceptable level of data safety (amongst other things), and move on to addressing the remaining challenges in novel and exciting ways. Both Ken and I have now independently advised this is not a good default setting, I think the case has been well made and is compelling - please can you look into changing it for the next release? (I'm happy to have the option still there, personally, though perhaps others are not? Good for running experiments and for folks who understand the risks and trade offs involved - but not switched on by default). Thanks!! cheers. -- Nathan From fche@redhat.com Thu Feb 6 07:32:27 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 78A6E7F54 for ; Thu, 6 Feb 2014 07:32:27 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 0D374AC005 for ; Thu, 6 Feb 2014 05:32:26 -0800 (PST) X-ASG-Debug-ID: 1391693542-04bdf012201841e0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 1byce28vZr4THB3l for ; Thu, 06 Feb 2014 05:32:22 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s16DWL8n019567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 6 Feb 2014 08:32:22 -0500 Received: from fche.csb (vpn-234-16.phx2.redhat.com [10.3.234.16]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s16DWLsM008403; Thu, 6 Feb 2014 08:32:21 -0500 Received: by fche.csb (Postfix, from userid 2569) id 57266580FA; Thu, 6 Feb 2014 08:32:20 -0500 (EST) Date: Thu, 6 Feb 2014 08:32:20 -0500 From: "Frank Ch. Eigler" To: Nathan Scott Cc: pcp@oss.sgi.com Subject: Re: [pcp] pmmgr pmlogger default behaviour Message-ID: <20140206133220.GC5017@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pmmgr pmlogger default behaviour References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1583484726.15908616.1391037005341.JavaMail.root@redhat.com> <20140130181134.GA7584@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1391693542 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - > [ sar, argus, syslog, log4j, pcp ... examples of the more regular > style of log rotation from the production environments I know - none > ever write the entire contents of the file since recording begins, > each and every day ] What some of those have in common is that they include no suite of processing tools for analyzing the rich data again. Sysadmins are stuck with manual identification of the slices and/or plain per-file/line text search tools. Contrast to fancier analysis tools like splunk/chainsaw/journald, that integrate. We should grasp toward the latter. > [...] Conversely, there's been no acknowledgement that there are > zero advantages to wun-beeg-log should libpcp be extended to support > transparent multi-archives, as is planned. [...] The defaults today are only for the state of the software today. > [...] > I must not have explained my concerns well. Let me try a different > tack using a real (really real, not some hypothetical) production > example from a real system serving a small-medium-size web presence. > > Within one data centre we'd typically use the centralised logging > setup as laid out in the book. A logger server with roughly 20-30 > hosts being logged [...] The scaling stories are interesting and compelling. But our pmmgr defaults log exactly one host, local:. (pmmgr, like the other pcp daemons, probably aren't even enabled by default!) The moment you're talking about 20-30 hosts being logged, you've left the realm of the defaults entirely. No one has asserted that all defaults are appropriate for much larger scales. On the contrary, I have been emphasizing the tautology that people who run non-default setups will need to use non-default settings. > > [...] She doesn't have to remember how to splice it together; to > > play with multiple -a options or comma-separated -a suboptions; or > > clumsy gui dialog boxes; or manual pmlogextract steps. It's > > already in one convenient chunk for instant gratification. It's > > as close to "grand-unified" as we can get to today. > That's not the case - one could set up a daily task that creates a > summary-style archive, taking the most important metrics from the > daily logs each day, and producing one merged archive from them to > summarise the last week or month. [...] Yes, and this is not a counterexample! We don't provide such a daily task, so you're in effect asking the new-to-PCP person to invent one. > [...] My main fear here is for the data loss this scheme will > induce. [...] I hope I have cleared up tangible data-loss related worries in detail. If there is data loss risk today, one'd be caused by the lack of fsync()'s, which affects the whole suite. I'll work on that immediately. And I'll work on adding more pmmgr log-management options with different performance/utility tradeoffs (but all safe from data loss). - FChE From minnus@buffalo.edu Thu Feb 6 09:08:28 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 85CB47F54 for ; Thu, 6 Feb 2014 09:08:28 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 0A568AC001 for ; Thu, 6 Feb 2014 07:08:24 -0800 (PST) X-ASG-Debug-ID: 1391699300-04cbb00c2b171750001-S8gJnT Received: from mtareserve1.acsu.buffalo.edu (mtareserve5.acsu.buffalo.edu [128.205.6.3]) by cuda.sgi.com with ESMTP id xExC5rxSETIvl73z for ; Thu, 06 Feb 2014 07:08:20 -0800 (PST) X-Barracuda-Envelope-From: minnus@buffalo.edu X-Barracuda-Apparent-Source-IP: 128.205.6.3 Received: from localmailA.acsu.buffalo.edu (localmaila.acsu.buffalo.edu [128.205.5.196]) by mtareserve1.acsu.buffalo.edu (Postfix) with ESMTP id 46FEC108D for ; Thu, 6 Feb 2014 10:08:20 -0500 (EST) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 43342107D2 for ; Thu, 6 Feb 2014 10:08:20 -0500 (EST) Received: from localmailA.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailA.acsu.buffalo.edu (Postfix) with ESMTP id E2BA5107C9 for ; Thu, 6 Feb 2014 10:08:19 -0500 (EST) Received: from smtp.buffalo.edu (smtp3.acsu.buffalo.edu [128.205.5.226]) by localmailA.acsu.buffalo.edu (Prefixe) with ESMTP id DE209107C8 for ; Thu, 6 Feb 2014 10:08:19 -0500 (EST) Received: from [128.205.28.209] (slash.eng.buffalo.edu [128.205.28.209]) (Authenticated sender: minnus@buffalo.edu) by smtp.buffalo.edu (Postfix) with ESMTPSA id D31C89C5A for ; Thu, 6 Feb 2014 10:08:19 -0500 (EST) Message-ID: <52F3A564.4060007@buffalo.edu> Date: Thu, 06 Feb 2014 10:08:20 -0500 From: Martins Innus User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: nfsclient pmda Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ASG-Orig-Subj: nfsclient pmda Content-Transfer-Encoding: 7bit X-PM-EL-Spam-Prob: : 8% X-Barracuda-Connect: mtareserve5.acsu.buffalo.edu[128.205.6.3] X-Barracuda-Start-Time: 1391699300 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA717 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144892 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_SA717 Custom Rule BSF_SC0_SA717 Hello, Was the nfsclient pmda referenced here: http://oss.sgi.com/archives/pcp/2011-10/msg00029.html ever integrated? If not, does anyone have a pointer to get the most recent version if its available? Thanks Martins From nscott@redhat.com Thu Feb 6 17:19:41 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 8B40C7F51 for ; Thu, 6 Feb 2014 17:19:41 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 53E3C8F8052 for ; Thu, 6 Feb 2014 15:19:38 -0800 (PST) X-ASG-Debug-ID: 1391728773-04bdf0122019d3f0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id OkcNyWLxVjnW4fin for ; Thu, 06 Feb 2014 15:19:33 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s16NJV3Q019919; Thu, 6 Feb 2014 18:19:32 -0500 Date: Thu, 6 Feb 2014 18:19:31 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Martins Innus Cc: pcp@oss.sgi.com Message-ID: <1469416634.21700255.1391728771761.JavaMail.root@redhat.com> In-Reply-To: <52F3A564.4060007@buffalo.edu> References: <52F3A564.4060007@buffalo.edu> Subject: Re: [pcp] nfsclient pmda MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] nfsclient pmda Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: nfsclient pmda Thread-Index: N3FFuRV2BD8wlcbvCSZCSHb0ClPSvQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1391728773 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144901 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Martins, ----- Original Message ----- > Hello, > Was the nfsclient pmda referenced here: > > http://oss.sgi.com/archives/pcp/2011-10/msg00029.html > > ever integrated? If not, does anyone have a pointer to get the most > recent version if its available? It was not merged. IIRC, Max had some review comments and questions that I don't think were tackled - now that I re-read he did suggest "could be useful to get this pmda into the official tree but not include it into the packages just yet." which I failed to follow up on, I got distracted by the rest of the thread most likely. There have been several advances since that post too - the perl API grew support for the pmdaCache routines that Max talks about there. Also, python became an option for PMDAs in the interim - if someone is keen to pick up those review comments and hack on this further, might be worth considering that aspect too (python, too, can use the pmdaCache APIs). An automated test to exercise the logic would be a welcome addition as well (e.g. qa/553 "Exercise the gluster PMDA" would make a good reference there). So, you guide me - would it be helpful in the tree and not packaged as Max suggested? From nscott@redhat.com Thu Feb 6 17:52:30 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 554D97F51 for ; Thu, 6 Feb 2014 17:52:30 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 298B9304032 for ; Thu, 6 Feb 2014 15:52:29 -0800 (PST) X-ASG-Debug-ID: 1391730748-04bdf0121e19e140001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id nhhG2dUTkiJLAfOS for ; Thu, 06 Feb 2014 15:52:28 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s16NqQOa025475; Thu, 6 Feb 2014 18:52:27 -0500 Date: Thu, 6 Feb 2014 18:52:26 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Martins Innus Cc: pcp@oss.sgi.com Message-ID: <415441515.21704894.1391730746823.JavaMail.root@redhat.com> In-Reply-To: <1469416634.21700255.1391728771761.JavaMail.root@redhat.com> References: <52F3A564.4060007@buffalo.edu> <1469416634.21700255.1391728771761.JavaMail.root@redhat.com> Subject: Re: [pcp] nfsclient pmda MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] nfsclient pmda Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: nfsclient pmda Thread-Index: N3FFuRV2BD8wlcbvCSZCSHb0ClPSvV7dF9RT X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1391730748 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144902 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Martinns, Forgot to mention - I chatted briefly to Ben on IRC today - he believes that is the most recent version of the code (the series posted back then), so that'd be the best spot to start I guess. cheers. -- Nathan From minnus@buffalo.edu Thu Feb 6 20:17:09 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=MIME_QP_LONG_LINE autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C7E077F51 for ; Thu, 6 Feb 2014 20:17:09 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 645F9AC002 for ; Thu, 6 Feb 2014 18:17:06 -0800 (PST) X-ASG-Debug-ID: 1391739421-04bdf012201a1d60001-S8gJnT Received: from mtareserve1.acsu.buffalo.edu (mtareserve5.acsu.buffalo.edu [128.205.6.3]) by cuda.sgi.com with ESMTP id WUXuW2Kdh38Gx7kG for ; Thu, 06 Feb 2014 18:17:01 -0800 (PST) X-Barracuda-Envelope-From: minnus@buffalo.edu X-Barracuda-Apparent-Source-IP: 128.205.6.3 Received: from localmailD.acsu.buffalo.edu (localmaild.acsu.buffalo.edu [128.205.5.208]) by mtareserve1.acsu.buffalo.edu (Postfix) with ESMTP id 3B3FC10A4; Thu, 6 Feb 2014 21:17:01 -0500 (EST) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 327C9C48B; Thu, 6 Feb 2014 21:17:01 -0500 (EST) Received: from localmailD.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailD.acsu.buffalo.edu (Postfix) with ESMTP id 722A5C483; Thu, 6 Feb 2014 21:17:00 -0500 (EST) Received: from smtp.buffalo.edu (smtp4.acsu.buffalo.edu [128.205.5.229]) by localmailD.acsu.buffalo.edu (Prefixe) with ESMTP id 5CF25C482; Thu, 6 Feb 2014 21:17:00 -0500 (EST) Received: from [10.0.1.3] (cpe-69-204-8-250.buffalo.res.rr.com [69.204.8.250]) (Authenticated sender: minnus@buffalo.edu) by smtp.buffalo.edu (Postfix) with ESMTPSA id 36A31A59F; Thu, 6 Feb 2014 21:17:00 -0500 (EST) References: <52F3A564.4060007@buffalo.edu> <1469416634.21700255.1391728771761.JavaMail.root@redhat.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1469416634.21700255.1391728771761.JavaMail.root@redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: "pcp@oss.sgi.com" X-Mailer: iPhone Mail (11B554a) From: Martins Innus Subject: Re: [pcp] nfsclient pmda Date: Thu, 6 Feb 2014 21:16:58 -0500 X-ASG-Orig-Subj: Re: [pcp] nfsclient pmda To: Nathan Scott X-PM-EL-Spam-Prob: XX: 28% X-Barracuda-Connect: mtareserve5.acsu.buffalo.edu[128.205.6.3] X-Barracuda-Start-Time: 1391739421 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144905 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars Nathan, Yes that would be great to get it in the tree. We are very interested in t= hese metrics and would look at getting it up and running. Thanks! Martins=20 > On Feb 6, 2014, at 6:19 PM, Nathan Scott wrote: >=20 > Hi Martins, >=20 > ----- Original Message ----- >> Hello, >> Was the nfsclient pmda referenced here: >>=20 >> http://oss.sgi.com/archives/pcp/2011-10/msg00029.html >>=20 >> ever integrated? If not, does anyone have a pointer to get the most >> recent version if its available? >=20 > It was not merged. IIRC, Max had some review comments and questions > that I don't think were tackled - now that I re-read he did suggest >=20 > "could be useful to get this pmda into the official tree but not > include it into the packages just yet." >=20 > which I failed to follow up on, I got distracted by the rest of the > thread most likely. >=20 > There have been several advances since that post too - the perl API > grew support for the pmdaCache routines that Max talks about there. >=20 > Also, python became an option for PMDAs in the interim - if someone > is keen to pick up those review comments and hack on this further, > might be worth considering that aspect too (python, too, can use the > pmdaCache APIs). An automated test to exercise the logic would be > a welcome addition as well (e.g. qa/553 "Exercise the gluster PMDA" > would make a good reference there). >=20 > So, you guide me - would it be helpful in the tree and not packaged > as Max suggested? =20 >=20 >=20 From nscott@redhat.com Fri Feb 7 01:25:44 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 03B817F53 for ; Fri, 7 Feb 2014 01:25:44 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id CF007304071 for ; Thu, 6 Feb 2014 23:25:40 -0800 (PST) X-ASG-Debug-ID: 1391757935-04bdf0121d1a94d0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id 9DczvZEZLSvaOTKY for ; Thu, 06 Feb 2014 23:25:36 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s177PZQX022972; Fri, 7 Feb 2014 02:25:35 -0500 Date: Fri, 7 Feb 2014 02:25:35 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: PCP Message-ID: <633105491.21839148.1391757935531.JavaMail.root@redhat.com> In-Reply-To: <20140206133220.GC5017@redhat.com> References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1583484726.15908616.1391037005341.JavaMail.root@redhat.com> <20140130181134.GA7584@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> <20140206133220.GC5017@redhat.com> Subject: Re: [pcp] pmmgr pmlogger default behaviour MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmmgr pmlogger default behaviour Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: pmmgr pmlogger default behaviour Thread-Index: 4zUJYw7lY83fKCtq6pmffEzheIDKog== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1391757936 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144910 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi Frank, Wow. I'm almost at a loss for words at this point, I was sure with so many overwhelming reasons not to do this, that the discussion would be over and we'd be laughing about it over a drink by now! ----- Original Message ----- > > > [ sar, argus, syslog, log4j, pcp ... examples of the more regular > > style of log rotation from the production environments I know - none > > ever write the entire contents of the file since recording begins, > > each and every day ] > > What some of those have in common is that they include no suite of > processing tools for analyzing the rich data again. Sysadmins are > stuck with manual identification of the slices and/or plain > per-file/line text search tools. Contrast to fancier analysis tools > like splunk/chainsaw/journald, that integrate. We should grasp toward > the latter. > Again, wow. You're not really trying to convince me that any of these read their entire history of collected data, every day, change the data and then write it all out ... and that this is something we should strive toward? They do not, of course - its a terrible I/O model, in hind-sight. Yes, we want good querying mechanisms, even better than we have, but the costs down this particular path are prohibitive, and there are more promising paths to explore. I'll stew on this over the weekend, and attempt to come up with some possible directions forward for us here, seeking compromise. It feels a bit like we're going in circles by email here now, and we need a new tack as we're stale-mated on each others needs/concerns. > The defaults today are only for the state of the software today. > ...[snip fsync discussion, attempting to address one problem]... > I'll work on that immediately. Right - my point exactly. :) Providing data integrity is not as simple as you're thinking, also. fsync(2) alone is not enough to provide the guarantee you seek. If you want to tackle this problem, lets discuss that separately - its a great goal IMO. It is not fixable via a sprinkling of fsync calls through code, and I would not expect it to be fixable and tested before the next release. Trust me on this one... my spidey sense is acute when it comes to I/O, and its in overdrive here. > I hope I have cleared up tangible data-loss related worries in detail. I'm not 100% certain you're following all of the subtleties (they are subtle! so, hard to tell by email), nor the size of the disparity between daily vs one-big-log in terms of risk. Comments like the "affects the whole suite" and "caused by a lack of fsync" ... it actually only affects a couple of tools (logmerge/logextract tools, pmmgr/pmlogger_daily interaction). This is not the "whole suite" of tools by any stretch of the imagination. So sadly the worries remain. > If there is data loss risk today, one'd be caused by the lack of > fsync()'s, which affects the whole suite. Maybe also focussing too much on that one issue; probably because it does concern me so much. There were many, many issues listed. Many that I listed, and many that Ken listed. They are not things that can be fixed quickly, if at all - reading and writing all of the history ... requiring 2x the disk space for merging ... those are simply not fixable problems. And there are so many of them. > And I'll work on adding more pmmgr log-management > options with different performance/utility tradeoffs (but all safe > from data loss). OK sounds good. That will certainly help - in fact, if we could list a series of possible configurations and how to achieve each (perhaps in a table/spreadsheet - or even go straight into a new pmmgr(1) section?), and explicitly state the pros and cons of each ... we may all be in a better position to choose a default we're all comfortable with then? Everything is a bit mixed up all through the emails now, and new issues were thought of as we worked it through - so, yeah, a central point to focus us would be a good next step I think. I need to set this discussion aside for a bit - eating alot of my time, and the buglist is ever growing. Maybe we could tee up a call and talk it all through? cheers. -- Nathan From nscott@redhat.com Fri Feb 7 04:42:10 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C13CB7F62 for ; Fri, 7 Feb 2014 04:42:10 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 3B5C5AC002 for ; Fri, 7 Feb 2014 02:42:07 -0800 (PST) X-ASG-Debug-ID: 1391769722-04cbb00c2a1954f0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id 9kd4dE66i0SG9ZW4; Fri, 07 Feb 2014 02:42:02 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s17AfuBK024220; Fri, 7 Feb 2014 05:41:56 -0500 Date: Fri, 7 Feb 2014 05:41:56 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Martins Innus Cc: pcp@oss.sgi.com, Ben Myers , Max Matveev Message-ID: <742242243.21951337.1391769716120.JavaMail.root@redhat.com> In-Reply-To: References: <52F3A564.4060007@buffalo.edu> <1469416634.21700255.1391728771761.JavaMail.root@redhat.com> Subject: Re: [pcp] nfsclient pmda MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] nfsclient pmda Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: nfsclient pmda Thread-Index: ZCCuadqzcze4K+KYuV5zr7m2rzAzPg== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1391769722 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144913 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Martins, ----- Original Message ----- > Nathan, > Yes that would be great to get it in the tree. We are very interested in > these metrics and would look at getting it up and running. > OK, its merged now and disabled from packaging pending your review, updating, testing & so on. Good luck, and have fun! > > There have been several advances since that post too - the perl API > > grew support for the pmdaCache routines that Max talks about there. > > > > Also, python became an option for PMDAs in the interim - if someone > > is keen to pick up those review comments and hack on this further, > > might be worth considering that aspect too (python, too, can use the > > pmdaCache APIs). An automated test to exercise the logic would be > > a welcome addition as well (e.g. qa/553 "Exercise the gluster PMDA" > > would make a good reference there). > > > > So, you guide me - would it be helpful in the tree and not packaged > > as Max suggested? > > cheers. -- Nathan From nscott@redhat.com Fri Feb 7 04:48:07 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CE9E77F56 for ; Fri, 7 Feb 2014 04:48:07 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9199E304084 for ; Fri, 7 Feb 2014 02:48:07 -0800 (PST) X-ASG-Debug-ID: 1391770082-04bdf0121e1ae8a0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id ciXDHINJI3b0iodo for ; Fri, 07 Feb 2014 02:48:02 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s17Am2YX002880 for ; Fri, 7 Feb 2014 05:48:02 -0500 Date: Fri, 7 Feb 2014 05:48:02 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: PCP Message-ID: <108188970.21953131.1391770082150.JavaMail.root@redhat.com> In-Reply-To: <288474744.21952790.1391769999316.JavaMail.root@redhat.com> Subject: pcp updates: bpm & fche merges MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: bpm & fche merges Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: pcp updates: bpm & fche merges Thread-Index: jWECyqn7c2QsCf2yPmHSiabu0XDZ/A== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1391770082 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144913 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev man/man1/pcpintro.1 | 3 man/man1/pmmgr.1 | 5 man/man5/pcp-archive.5 | 375 ++++++++++++++++++++++- src/pmdas/GNUmakefile | 4 src/pmdas/nfsclient/GNUmakefile | 44 ++ src/pmdas/nfsclient/Install | 27 + src/pmdas/nfsclient/Remove | 23 + src/pmdas/nfsclient/pmdanfsclient.pl | 560 ++++++++++++++++++++++++++++++++++- src/pmmgr/TODO | 4 src/pmmgr/pmmgr.cxx | 16 - src/pmns/stdpmid.pcp | 1 11 files changed, 1025 insertions(+), 37 deletions(-) commit 6710c9ae6ebce1d1958ff9bed55611b6d76e0059 Author: Frank Ch. Eigler Date: Tue Feb 4 15:12:12 2014 -0500 pmmgr: note possibilities for tie-breaking between alternate pmcd paths commit 5881ddf67d6d0d2a5c2e23d81f66ce53072f58ba Author: Frank Ch. Eigler Date: Mon Feb 3 11:19:53 2014 -0500 man5/pcp-archive.5: clarify archive-label magic values for .meta/.index commit 02c1a63e038d5b531988c0aad1cb021bedd3d607 Author: Frank Ch. Eigler Date: Fri Jan 31 15:43:33 2014 -0500 man5/pcp-archive.5: note treatment of instance-domain updates in .meta files This is relevant to http://oss.sgi.com/bugzilla/show_bug.cgi?id=1046 commit 29754eabe7f881805d1f8727fe8737184f405e5f Author: Frank Ch. Eigler Date: Fri Jan 31 14:59:34 2014 -0500 man5/pm-archive.5: insignificant microtweakage commit de85afe6582addf581d9441a6337b4010e09f12e Author: Frank Ch. Eigler Date: Thu Jan 30 21:50:22 2014 -0500 man5/pcp-archive.5: add some meat commit e04fa98fc7af173e03462c71607f7ad7320f3574 Author: Frank Ch. Eigler Date: Wed Jan 29 16:38:14 2014 -0500 man5/pcp-archive.5: the beginning commit 1d17919107f803f90506837778126a940ae7fe61 Author: Frank Ch. Eigler Date: Mon Jan 27 21:36:24 2014 -0500 pmmgr: new TODO commit 15b0d90b60b95d7cf0c967702b597d628f390ebb Author: Frank Ch. Eigler Date: Mon Jan 27 21:34:30 2014 -0500 pmmgr: use pmSortInstances() instead of same thing open-coded locally commit 0da976370605a9f04f3eb712dff6035eb1bc8cf1 Author: Nathan Scott Date: Fri Feb 7 20:32:27 2014 +1100 Insert nfsclient PMDA into the build (not yet packaged) As discussed on-list, Martinns is interested in continuing on with Max's initial review on pmda nfsclient. Pending review, tweaks and a QA test or two, also as discussed and originally suggested by Max, this is built but not packaged yet. Have fun, and a belated thank-you for the contribution Ben! commit 447a5dba581ad1f96a9062abedc1d4f8442aecfa Author: Ben Myers Date: Fri Feb 7 20:28:50 2014 +1100 Add rpc operation metrics to the nfsclient pmda The nfs client keeps per rpc operation stats. Add these to the nfsclient pmda. Here we have only gathered the nfs v3 operations. v2 and v4 still need to be done. commit 72404f90b7bb2ea4b120ef23eb699daa23028b06 Author: Ben Myers Date: Fri Feb 7 20:18:25 2014 +1100 Add transport counter metrics to the nfsclient pmda The nfs client has some transport specific counters. Add these to the nfsclient pmda. At this point we only gather tcp transport data. commit 36baa2cc0e476ea2b3006cd7a6e79f1eb84bc155 Author: Ben Myers Date: Fri Feb 7 20:17:22 2014 +1100 Add byte counter metrics to the nfsclient pmda The nfs client has a set of byte counters that are reported via /proc/self/mountstats. Add them to the nfs client pmda. commit e56bfffd7d0ea3f1ae4cec7659a831c841e5861a Author: Ben Myers Date: Fri Feb 7 20:16:50 2014 +1100 Add event counter metrics to the nfsclient pmda The nfs client has a set of specific event counters that are reported via /proc/self/mountstats. Add them to the nfsclient pmda. commit 131774551dbf194281f6122cb5f4bf50bb408f01 Author: Ben Myers Date: Fri Feb 7 20:14:33 2014 +1100 Basic nfsclient pmda, a basic makefile, and Install/Remove scripts From nscott@redhat.com Fri Feb 7 05:29:23 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 161F97F53 for ; Fri, 7 Feb 2014 05:29:23 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id BD04D8F8068 for ; Fri, 7 Feb 2014 03:29:19 -0800 (PST) X-ASG-Debug-ID: 1391772557-04bdf0121e1afa00001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id kik4rzjTxj7LmAsK for ; Fri, 07 Feb 2014 03:29:17 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s17BTD9t010077; Fri, 7 Feb 2014 06:29:13 -0500 Date: Fri, 7 Feb 2014 06:29:13 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" , Ken McDonell Cc: PCP Message-ID: <2133757769.21973706.1391772553504.JavaMail.root@redhat.com> In-Reply-To: <633105491.21839148.1391757935531.JavaMail.root@redhat.com> References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1583484726.15908616.1391037005341.JavaMail.root@redhat.com> <20140130181134.GA7584@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> <20140206133220.GC5017@redhat.com> <633105491.21839148.1391757935531.JavaMail.root@redhat.com> Subject: Logged data integrity improvement ideas MIME-Version: 1.0 X-ASG-Orig-Subj: Logged data integrity improvement ideas Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: pmmgr pmlogger default behaviour Thread-Index: 4zUJYw7lY83fKCtq6pmffEzheIDKor97+BeP X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1391772557 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144914 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi guys, ----- Original Message ----- > ... > > Providing data integrity is not as simple as you're thinking, also. > fsync(2) alone is not enough to provide the guarantee you seek. Have just come across commit 5a3a2494 in fche/dev, and it seems I was too late sending this mail as the following has already been attempted. If only the missing QA for pmmgr was tackled so vigorously! ;) -- I would be so happy. Anyhow... [ git://sourceware.org/git/pcpfans.git fche/dev ] $ git show 5a3a249497cc3e3a93495fa77b41559e8b706ab4 | diffstat include/pcp/impl.h | 12 ++++++++++++ libpcp/src/logutil.c | 11 ++++++----- libpcp_import/src/archive.c | 4 ++++ pmlogextract/pmlogextract.c | 5 ++++- pmlogger/src/pmlogger.c | 12 ++++++++++-- pmloglabel/pmloglabel.c | 8 ++++---- pmlogreduce/logio.c | 2 +- pmlogreduce/pmlogreduce.c | 4 ++++ pmlogrewrite/pmlogrewrite.c | 8 ++++++-- 9 files changed, 51 insertions(+), 15 deletions(-) ["logging durability: add fsync(2) when closing log archives"] Can you describe the testing done for this change or planned? Also, thoughts on the impact the newly introduced latency will have on these code paths and the tools/scripts using them? (I haven't thought it through, so keen to hear thoughts - or any observations/measurements so far) If anyone has not come across it before, I'd highly recommend an article Valerie Aurora wrote discussing fsync/rename here: http://lwn.net/Articles/351422/ Note also the mentions she makes of performance implications, important for us folks attempting to minimise our impact on the observed system. There's also other subtleties discussed on the fsync(1) man page, its well worth a careful read too - the directory paragraph is relevant to our needs. OK, enough for this week - will chat later. cheers. -- Nathan From pevans@redhat.com Fri Feb 7 05:49:08 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C63727F51 for ; Fri, 7 Feb 2014 05:49:08 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 51E52AC005 for ; Fri, 7 Feb 2014 03:49:05 -0800 (PST) X-ASG-Debug-ID: 1391773744-04bdf0121f1b0270001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id DgeU9nq5clADLEue for ; Fri, 07 Feb 2014 03:49:04 -0800 (PST) X-Barracuda-Envelope-From: pevans@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s17Bn3bD013524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Feb 2014 06:49:04 -0500 Received: from [10.36.6.238] (vpn1-6-238.ams2.redhat.com [10.36.6.238]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s17Bn2Lj010713; Fri, 7 Feb 2014 06:49:03 -0500 Message-ID: <52F4C82E.1050007@redhat.com> Date: Fri, 07 Feb 2014 11:49:02 +0000 From: Paul Evans User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nathan Scott CC: PCP Mailing List Subject: pmdagfs2: Updates to documentation and install script Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ASG-Orig-Subj: pmdagfs2: Updates to documentation and install script Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1391773744 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Changes committed to git://github.com/pauljevans/pcp.git dev man/man1/pmdagfs2.1 | 4 ++++ src/pmdas/gfs2/Install | 26 +++++++++++++++++--------- src/pmdas/gfs2/README | 7 +++++++ 3 files changed, 28 insertions(+), 9 deletions(-) commit afe3cd4ff009baebe4b011b340614ab436bd4393 Author: Paul Evans Date: Fri Feb 7 11:32:26 2014 +0000 pmdagfs2: Update install script to check for pmcd before install Additional checking logic in the Install script to check to see if pmcd is running on the system before attempting to install. commit 1152b0a6303524e84f9392c21e71fd7cdab20d9d Author: Paul Evans Date: Fri Feb 7 11:24:59 2014 +0000 pmdagfs2: Update documentation to improve install instructions Updated README and the pmdagfs2.1 man page to reflect the need for pmcd to be started and running in order to successfully be able to install the PMDA. Two quick updates to attend to the issues pointed out in bug 1062443 by Andy, Please let me know of any issues and as always feedback is welcome. Cheers, Paul From fche@redhat.com Fri Feb 7 10:40:51 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id CCB0229DF8 for ; Fri, 7 Feb 2014 10:40:51 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id AFEA18F8052 for ; Fri, 7 Feb 2014 08:40:48 -0800 (PST) X-ASG-Debug-ID: 1391791243-04cb6c6de01a2580001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id WhZkb9siEeiESnIy for ; Fri, 07 Feb 2014 08:40:44 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s17GebU9017455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Feb 2014 11:40:38 -0500 Received: from fche.csb (vpn-234-16.phx2.redhat.com [10.3.234.16]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s17Gea0S012709; Fri, 7 Feb 2014 11:40:36 -0500 Received: by fche.csb (Postfix, from userid 2569) id ECFC35817F; Fri, 7 Feb 2014 11:40:35 -0500 (EST) To: Nathan Scott Cc: Ken McDonell , pcp@oss.sgi.com Subject: Re: Logged data integrity improvement ideas References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1583484726.15908616.1391037005341.JavaMail.root@redhat.com> <20140130181134.GA7584@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> <20140206133220.GC5017@redhat.com> <633105491.21839148.1391757935531.JavaMail.root@redhat.com> <2133757769.21973706.1391772553504.JavaMail.root@redhat.com> X-ASG-Orig-Subj: Re: Logged data integrity improvement ideas From: fche@redhat.com (Frank Ch. Eigler) Date: Fri, 07 Feb 2014 11:40:35 -0500 In-Reply-To: <2133757769.21973706.1391772553504.JavaMail.root@redhat.com> (Nathan Scott's message of "Fri, 7 Feb 2014 06:29:13 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1391791244 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - > Have just come across commit 5a3a2494 in fche/dev, and it seems > I was too late sending this mail as the following has already > been attempted. Yup. > If only the missing QA for pmmgr was tackled so vigorously! ;) -- I > would be so happy. The anticipation will be worth it. ;-) Sorry it's been taking so long. > ["logging durability: add fsync(2) when closing log archives"] > > Can you describe the testing done for this change or planned? The pcpqa suite, plus strace examination that the fsync(2)'s are going out at the right time. There are still some known problems. > Also, thoughts on the impact the newly introduced latency will have > on these code paths and the tools/scripts using them? [...] Note > also the mentions she makes of performance implications, important > for us folks attempting to minimise our impact on the observed > system. This one's tricky to measure well. fsync does not increase I/O amount, only compresses it along the time axis. The latency suffered by the archive-producing tool exits vary by the speed/volume of their output generation: batch pmlog* manipulation tools will be affected far more than pmlogger. I'll try to measure this by hand. > There's also other subtleties discussed on the fsync(1) man page, > its well worth a careful read too - the directory paragraph is > relevant to our needs. Yup. We're a long way from the sort of robustness guarantees we might like to have. This was just "low-hanging fruit" as they say, and should mostly solve one particular problem you had encountered. - FChE From nscott@redhat.com Fri Feb 7 16:57:37 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 299057CBE for ; Fri, 7 Feb 2014 16:57:37 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id AFE25AC009 for ; Fri, 7 Feb 2014 14:57:33 -0800 (PST) X-ASG-Debug-ID: 1391813850-04cb6c6de31aae30001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id K5NYzzW3LO7pePSi for ; Fri, 07 Feb 2014 14:57:31 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s17MvUSS026677; Fri, 7 Feb 2014 17:57:30 -0500 Date: Fri, 7 Feb 2014 17:57:30 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Paul Evans Cc: PCP Mailing List Message-ID: <540859557.22515469.1391813850484.JavaMail.root@redhat.com> In-Reply-To: <52F4C82E.1050007@redhat.com> References: <52F4C82E.1050007@redhat.com> Subject: Re: pmdagfs2: Updates to documentation and install script MIME-Version: 1.0 X-ASG-Orig-Subj: Re: pmdagfs2: Updates to documentation and install script Content-Type: multipart/mixed; boundary="----=_Part_22515467_917755133.1391813850483" X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF17 (Linux)/8.0.3_GA_5664) Thread-Topic: pmdagfs2: Updates to documentation and install script Thread-Index: g3ACF2f2QvNwsPoKJiFM1BKEzDl/lg== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1391813851 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144926 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ------=_Part_22515467_917755133.1391813850483 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Paul, Thanks for looking into this! ----- Original Message ----- > Changes committed to git://github.com/pauljevans/pcp.git dev > > man/man1/pmdagfs2.1 | 4 ++++ > src/pmdas/gfs2/Install | 26 +++++++++++++++++--------- > src/pmdas/gfs2/README | 7 +++++++ > 3 files changed, 28 insertions(+), 9 deletions(-) > > commit afe3cd4ff009baebe4b011b340614ab436bd4393 > Author: Paul Evans > Date: Fri Feb 7 11:32:26 2014 +0000 > > pmdagfs2: Update install script to check for pmcd before install > I'm not sure this is the best spot to tackle the problem as this issue affects all PMDA install scripts (gfs2 was just an unlucky victim here). I'd begun to look into this yesterday, but got distracted before finishing up - sorry 'bout that! The attached patch is where I was at - it looks to see if the root namespace file exists before attempting to add the new sub tree, and if not, Rebuilds it and flags pmcd to be started later on. I've not tested it though, and its something that needs a few more eyes on it (affects every PMDA install). If you could look over it and give it a whirl, that'd be much appreciated. cheers. -- Nathan ------=_Part_22515467_917755133.1391813850483 Content-Type: text/x-patch; name=pmdaproc.patch Content-Disposition: attachment; filename=pmdaproc.patch Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3NyYy9wbWNkL3BtZGFwcm9jLnNoIGIvc3JjL3BtY2QvcG1kYXByb2Muc2gK aW5kZXggNDNjZmZhNy4uYmFiMDE2MSAxMDA2NDQKLS0tIGEvc3JjL3BtY2QvcG1kYXByb2Muc2gK KysrIGIvc3JjL3BtY2QvcG1kYXByb2Muc2gKQEAgLTExNjMsNiArMTE2MywyMiBAQCBfaW5zdGFs bCgpCiAgICAgIyBJbnN0YWxsIHRoZSBuYW1lc3BhY2UKICAgICAjCiAKKyAgICBpZiBbICEgLWYg JE5BTUVTUEFDRSBdCisgICAgdGhlbgorCSMgV2UgbWF5IGJlIGluc3RhbGxpbmcgYW4gYWdlbnQg cmlnaHQgYWZ0ZXIgYW4gaW5zdGFsbCAtCisJIyBiZWZvcmUgcG1jZCBzdGFydHVwLCB3aGljaCBo YXMgYSBwcmUtZXhlY3V0aW9uIHN0ZXAgb2YKKwkjIHJlYnVpbGRpbmcgdGhlIG5hbWVzcGFjZSBy b290LiAgRG8gc28gbm93LgorCWlmIFsgLXggJFBNTlNESVIvUmVidWlsZCBdCisJdGhlbgorCSAg ICBlY2hvICIkcHJvZzogY2Fubm90IFJlYnVpbGQgdGhlIFBNTlMgZm9yIFwiJE5BTUVTUEFDRVwi IgorCSAgICBleGl0IDEKKwlmaQorCWNkICRQTU5TRElSCisJLi9SZWJ1aWxkIC1kdXMKKwljZCAk X19oZXJlCisJZm9yY2VkX3Jlc3RhcnQ9dHJ1ZQorICAgIGZpCisKICAgICBmb3IgX19uIGluICRw bW5zX25hbWUKICAgICBkbwogCWlmIHBtaW5mbyAkX19uc19vcHQgJF9fbiA+L2Rldi9udWxsIDI+ JjEK ------=_Part_22515467_917755133.1391813850483-- From noreply@release.debian.org Sat Feb 8 10:39:32 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CDF967F3F for ; Sat, 8 Feb 2014 10:39:32 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id B1707304067 for ; Sat, 8 Feb 2014 08:39:29 -0800 (PST) X-ASG-Debug-ID: 1391877564-04cb6c6de11c7ba0001-S8gJnT Received: from picconi.debian.org (picconi.debian.org [5.153.231.3]) by cuda.sgi.com with ESMTP id 2VgmmmmBITcxL8IO (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 08 Feb 2014 08:39:25 -0800 (PST) X-Barracuda-Envelope-From: noreply@release.debian.org X-Barracuda-Apparent-Source-IP: 5.153.231.3 Received: from franck.debian.org ([138.16.160.12]) from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=franck.debian.org,EMAIL=hostmaster@franck.debian.org (verified) by picconi.debian.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WCAw6-00015d-O0 for pcp@packages.debian.org; Sat, 08 Feb 2014 16:39:22 +0000 Received: from release by franck.debian.org with local (Exim 4.80) (envelope-from ) id 1WCAw0-0006Kp-MH; Sat, 08 Feb 2014 16:39:16 +0000 From: Debian testing watch Precedence: bulk X-Trille: 0.120315.1711 Subject: pcp 3.8.12 MIGRATED to testing X-Testing-Watch-Package: pcp X-ASG-Orig-Subj: pcp 3.8.12 MIGRATED to testing X-Testing-Watch-Version: 3.8.12 To: pcp@packages.debian.org Message-Id: Sender: Release Managers Date: Sat, 08 Feb 2014 16:39:16 +0000 Delivered-To: pcp@packages.debian.org X-Barracuda-Connect: picconi.debian.org[5.153.231.3] X-Barracuda-Start-Time: 1391877564 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144944 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header FYI: The status of the pcp source package in Debian's testing distribution has changed. Previous version: 3.8.10 Current version: 3.8.12 -- This email is automatically generated once a day. As the installation of new packages into testing happens multiple times a day you will receive later changes on the next day. See http://release.debian.org/testing-watch/ for more information. From pevans@redhat.com Sun Feb 9 17:41:15 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id AAC697F4E for ; Sun, 9 Feb 2014 17:41:15 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 8C3AC8F8035 for ; Sun, 9 Feb 2014 15:41:15 -0800 (PST) X-ASG-Debug-ID: 1391989271-04cb6c6de322a800001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id Tb15o3B383IoYXcG for ; Sun, 09 Feb 2014 15:41:11 -0800 (PST) X-Barracuda-Envelope-From: pevans@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s19NfB73021121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 9 Feb 2014 18:41:11 -0500 Received: from [10.36.4.110] (vpn1-4-110.ams2.redhat.com [10.36.4.110]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s19Nf9YF006342; Sun, 9 Feb 2014 18:41:10 -0500 Message-ID: <52F81215.3090300@redhat.com> Date: Sun, 09 Feb 2014 23:41:09 +0000 From: Paul Evans User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Nathan Scott CC: PCP Mailing List Subject: Re: pmdagfs2: Updates to documentation and install script References: <52F4C82E.1050007@redhat.com> <540859557.22515469.1391813850484.JavaMail.root@redhat.com> X-ASG-Orig-Subj: Re: pmdagfs2: Updates to documentation and install script In-Reply-To: <540859557.22515469.1391813850484.JavaMail.root@redhat.com> Content-Type: multipart/mixed; boundary="------------010804010304020607050009" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1391989271 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 This is a multi-part message in MIME format. --------------010804010304020607050009 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Nathan, On 02/07/2014 10:57 PM, Nathan Scott wrote: > The attached patch is where I was at - it looks to see if the > root namespace file exists before attempting to add the new sub > tree, and if not, Rebuilds it and flags pmcd to be started later > on. I've not tested it though, and its something that needs a > few more eyes on it (affects every PMDA install). If you could > look over it and give it a whirl, that'd be much appreciated. > I've taken a quick looksee at the patch you provided and had to make some slight alterations in order to get it to allow an error free PMDA install with this scenario on my RHEL 7 machine. With the alterations the attached patch seems to work well and the PMDA installed works when PMCD is later started. After changing the logic of the test for Rebuild to continue if found I ran into an issue where PMCPP would error and bail whilst parsing a PMDA root (PMDADIR/root) if it included stdpmid. For lack of it existing yet. I found that generating an initial copy of stdpmid using the available Make.stdpmid before calling Rebuild allowed the PMDA install to continue and complete successfully with only a verbal warning for being unable to lock the root ($PCP_VAR_DIR/pmns/ root.lock). Becauseit does not exist yet. --- Terminal output ---- [root@localhost gfs2]# ./Install You will need to choose an appropriate configuration for installation of the "gfs2" Performance Metrics Domain Agent (PMDA). collector collect performance statistics on this system monitor allow this system to monitor local and/or remote systems both collector and monitor configuration for this system Please enter c(ollector) or m(onitor) or b(oth) [b] Updating the Performance Metrics Name Space (PMNS) ... lockpmns: Warning: Unable to acquire lock (root.lock) after 120 seconds ... continuing anyway Terminate PMDA if already installed ... Updating the PMCD control file, and notifying PMCD ... Rebuilding PMNS ... Starting pmcd ... Check gfs2 metrics have appeared ... 203 metrics and 193 values --- Terminal output ---- Cheers, Paul --------------010804010304020607050009 Content-Type: text/x-patch; name="pmdaproc-ammed.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pmdaproc-ammed.patch" >From 0a724dafb408edce468104b089eeb1b760b79bed Mon Sep 17 00:00:00 2001 From: Paul Evans Date: Sun, 9 Feb 2014 11:24:04 +0000 Subject: [PATCH 1/1] pmdaproc.sh patch: Amendment after testing with RHEL 7 Small change with the proposed patch by Nathan with regards to the logic checking if Rebuild exists. Upon testing on RHEL 7 any pmda's which included stdpmid in their root would fail parsing the pmda's root (pmcpp would fail, pmcpp: root[5]: To counter this call Make.stdpmid. PMDA installs work correctly now, there is just a verbal warning on locking the global root the first time a PMDA is installed (lockpmns: Warning: Unable to acquire lock (root.lock) after 120 seconds ... continuing anyway), but again this down to a global root not yet existing in the scenario. --- src/pmcd/pmdaproc.sh | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/src/pmcd/pmdaproc.sh b/src/pmcd/pmdaproc.sh index 43cffa7..b273422 100644 --- a/src/pmcd/pmdaproc.sh +++ b/src/pmcd/pmdaproc.sh @@ -1163,6 +1163,27 @@ _install() # Install the namespace # + if [ ! -f $NAMESPACE ] + then + # We may be installing an agent right after an install - + # before pmcd startup, which has a pre-execution step of + # rebuilding the namespace root. Do so now. + # + # pmcpp exits with file not found when reading a pmda root + # that includes stdpmid. (Does not exist yet). Generate one now. + if [ ! -x $PMNSDIR/Rebuild ] + then + echo "$prog: cannot Rebuild the PMNS for \"$NAMESPACE\"" + exit 1 + fi + cd $PCP_VAR_DIR/pmns/ + ./Make.stdpmid + cd $PMNSDIR + ./Rebuild -dus + cd $__here + forced_restart=true + fi + for __n in $pmns_name do if pminfo $__ns_opt $__n >/dev/null 2>&1 -- 1.7.11.7 --------------010804010304020607050009-- From nscott@redhat.com Sun Feb 9 21:26:56 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 0C8767F4E for ; Sun, 9 Feb 2014 21:26:56 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id C3D75304043 for ; Sun, 9 Feb 2014 19:26:52 -0800 (PST) X-ASG-Debug-ID: 1392002807-04bdf01220248390001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id bvwNEKhfRhcDooZL for ; Sun, 09 Feb 2014 19:26:48 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1A3Ql7N032757; Sun, 9 Feb 2014 22:26:47 -0500 Date: Sun, 9 Feb 2014 22:26:47 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Paul Evans Cc: PCP Mailing List Message-ID: <1850819988.1234046.1392002807455.JavaMail.zimbra@redhat.com> In-Reply-To: <52F81215.3090300@redhat.com> References: <52F4C82E.1050007@redhat.com> <540859557.22515469.1391813850484.JavaMail.root@redhat.com> <52F81215.3090300@redhat.com> Subject: Re: pmdagfs2: Updates to documentation and install script MIME-Version: 1.0 X-ASG-Orig-Subj: Re: pmdagfs2: Updates to documentation and install script Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmdagfs2: Updates to documentation and install script Thread-Index: qp04M5HofjytV94ZssEzLK1OgYacpQ== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392002808 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144983 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi Paul, ----- Original Message ----- > Hi Nathan, > > On 02/07/2014 10:57 PM, Nathan Scott wrote: > > The attached patch is where I was at - it looks to see if the > > root namespace file exists before attempting to add the new sub > > tree, and if not, Rebuilds it and flags pmcd to be started later > > on. I've not tested it though, and its something that needs a > > few more eyes on it (affects every PMDA install). If you could > > look over it and give it a whirl, that'd be much appreciated. > > > I've taken a quick looksee at the patch you provided and had > to make some slight alterations in order to get it to allow an > error free PMDA install with this scenario on my RHEL 7 machine. > With the alterations the attached patch seems to work well and > the PMDA installed works when PMCD is later started. Thanks! Good to hear it - I'll take it for a full QA spin and check all the wierd and wonderful corner cases, verifying lots of PMDA install scripts in the process. > After changing the logic of the test for Rebuild to continue > if found I ran into an issue where PMCPP would error and bail > whilst parsing a PMDA root (PMDADIR/root) if it included > stdpmid. For lack of it existing yet. I think that ones an unrelated bug (fixed already) - 1059004 and tackled via commit 80601bca. Thus, I think that second step you added is superfluous when that other fix is in place. > I found that generating an initial copy of stdpmid using the > available Make.stdpmid before calling Rebuild [...] > Because it does not exist yet. So, it should have, just some dope (me) managed to not install it, in his eagerness to tackle some other unrelated issue. If I could just stop introducing a bug for every bug I fix, well, we'd all be better off. :) cheers. -- Nathan From nscott@redhat.com Sun Feb 9 23:47:53 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 858537F3F for ; Sun, 9 Feb 2014 23:47:53 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 6CEA6304043 for ; Sun, 9 Feb 2014 21:47:50 -0800 (PST) X-ASG-Debug-ID: 1392011265-04cbb00c2a234190001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id F7Hw4HAw6UD3xC0i for ; Sun, 09 Feb 2014 21:47:45 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1A5linh021448; Mon, 10 Feb 2014 00:47:44 -0500 Date: Mon, 10 Feb 2014 00:47:44 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Stan Cox Cc: PCP Mailing List Message-ID: <1064102940.1296710.1392011264511.JavaMail.zimbra@redhat.com> In-Reply-To: <52F50F51.1020504@redhat.com> References: <52F50F51.1020504@redhat.com> Subject: Re: pcp-programmers-guide.xml MIME-Version: 1.0 X-ASG-Orig-Subj: Re: pcp-programmers-guide.xml Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp-programmers-guide.xml Thread-Index: dZPZGCqiD6zkbWI2T/v/ljNHKpjyjg== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392011265 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144985 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > Here is my latest round: Looks good. Here's a few more refinements ... - c -> C (language name, so uppercase probably best) - the C synopsis for pmDupContext was accidentally removed? - pmNameID vs pmNameInDom -> different style (str vs "string") - pmWhichZone() - same issue - actually, lots with this inconsistency - pmAddProfile vs pmDelProfile use "Python" vs "Python Bindings" - pmSetMode, same issue - actually, lots with this inconsistency - were you moving to the latter or the former? either seems fine, pick one. - "mode is defined in the c_api.PM_MODE* constants defined in by importing cpmapi." reads oddly ... too many "defined in" occurrences? - the code snippets in this section (eg 3.8.6.*) use the phrase "code snippets" - could change those to "C code snippets"? In most/all places the return code listed as, eg: int status = pmUseZone(int tz_handle) The "tz_handle" name is in italics, but "status" is not - maybe it should be too? *shrug* We should add words to pmDestroyContext and pmNewContext stating that these are not ever called directly from python code, rather they are implicitly called when an context object is created and destroyed. Oh, pmLookupText and pmLookupInDomText appear to be missing their python counterparts? 3.8.7 missing python bindings (WIP?) - these are in "import pmgui" I think (hmmm, we seem to have no direct tests - but, pmcollectl and pmatop both use 'em so maybe we've got coverage there) 3.8.8.1 pmGetArchiveLabel returns a loglabel (ctypes struct), as is described for C API - not an int. 3.8.8.2 pmGetArchiveEnd returns ctypes timeval pointer, not int. 3.8.10.1 pmGetConfig starts to use a different whitespace style to everything preceding (and to C synopsis), also lacks str type information for call parameter 3.8.10.2. pmErrStr missing return type str? or did you prefer the other convention (i think str is nice & clear, FWIW, but it adds redundant info given the double quotes ... *shrug*). Same whitespace quirk as getconfig. 3.8.10.11. pmPrintValue missing whitespace in pmResultpmresult. FILE* here is a (py native) PyFile, according to the code? 3.8.10.12. pmflush is same in python, not camel-cased 3.8.10.13. pmprintf missing python wrapper - same call convention (varargs) from a look at the code. 3.8.10.16. pmParseMetricSpec has whitespace/comma issues in the return values for python. 3.9.1 - pmgenmap rejig in C example - excellent, thanks! :) 3.9.2, 3.9.3 - nice, matching py examples - good stuff. There is a python pmtimevalSleep like used by the C API, btw. It'd be good to use that, as the common-arg-parsing stuff I'm looking at will use a timeval like in C (via -t auto-parsing) Example 3.23. C code has: char *host = "localhost"; Hmm, don't let Dave & Frank see that - could you tweak that to "local:" while you're in there? thx. Re the python exception handling - er, wow - its that easy? :] Can you really import a module within an exception handler? (I have no idea) Also, should the "print freemem" be earlier on? It kinda reads like we execute that after the exception handler, too, which I would expect to explode with an uninitialised variable? Good going!! - its a tough slog working on these books - the pain is all coming back to me now. :) cheers. -- Nathan From pcolby@gmail.com Mon Feb 10 04:09:07 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 75A267F3F for ; Mon, 10 Feb 2014 04:09:07 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 017E9AC004 for ; Mon, 10 Feb 2014 02:09:03 -0800 (PST) X-ASG-Debug-ID: 1392026938-04cbb00c2b239dc0001-S8gJnT Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) by cuda.sgi.com with ESMTP id qKQ3P2V6YfkROQbE (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 10 Feb 2014 02:08:58 -0800 (PST) X-Barracuda-Envelope-From: pcolby@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.160.177 X-Barracuda-IPDD: Level1 [gmail.com/209.85.160.177] Received: by mail-yk0-f177.google.com with SMTP id q200so6472394ykb.8 for ; Mon, 10 Feb 2014 02:08:58 -0800 (PST) X-Barracuda-IPDD: Level1 [gmail.com/209.85.160.177] X-Barracuda-IPDD: Level1 [gmail.com/209.85.160.177] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=fvE7A/aZG47UzLFX+b7o//V0LhsDd/dNUBlin2soKA4=; b=z58PasOxCMU8m/si8iCEPrz+JFR7QJupRk/zzQaVCCHinoN6919vc4SOwWL7O8nQbS ROlUICML9FW7ypO89NVTwxcCM5RLYGG8Naqt2wx3y0zn3AUYACGk0ppTQHm4WfVWg1Ki fRX4HXR94zLtKVOrCCIiTvg/qcX9LExFDOqkzyt4Aw4g/acEPeSHhTWEgQdEOLkqBghM j+wdIQapGxNBhmQhA+4n3F7nYGvavQMxeDtV5+5h1VR8fURUnP9VE1NqNKdjcR8yOLTC iShY3RXuUXH1FdnFM8bE4lEimA8CWb7l61eHJFgvOGXEsC9dhdx8/+9hw8pDEDMfSSii QFAA== MIME-Version: 1.0 X-Received: by 10.236.228.137 with SMTP id f9mr16067847yhq.44.1392026938133; Mon, 10 Feb 2014 02:08:58 -0800 (PST) Sender: pcolby@gmail.com Received: by 10.170.159.196 with HTTP; Mon, 10 Feb 2014 02:08:57 -0800 (PST) Date: Mon, 10 Feb 2014 21:08:57 +1100 X-Google-Sender-Auth: V35HPQGWLzFgLf0q7PbPzsdZjDM Message-ID: Subject: Official domain number for my Qpid PMDA project? From: Paul Colby X-ASG-Orig-Subj: Official domain number for my Qpid PMDA project? To: pcp@oss.sgi.com Content-Type: multipart/alternative; boundary=001a1132f28e2a502304f20a87b8 X-Barracuda-Connect: mail-yk0-f177.google.com[209.85.160.177] X-Barracuda-Start-Time: 1392026938 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-BRTS-Evidence: colby.id.au X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144990 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message --001a1132f28e2a502304f20a87b8 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, I'm close to the first release of a PMDA I've been writing for exposing metrics from Apache Qpid message brokers (project is hosted on github - https://github.com/pcolby/pcp-pmda-qpid). Is it possible to get an official domain number allocated for this PMDA? Or should I just choose something randomly from the "End-User PMDAs and demo PMDAs" range? Thanks, Paul Colby ---- http://colby.id.au --001a1132f28e2a502304f20a87b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys,

I'm close to the first rel= ease of a PMDA I've been writing for exposing metrics from Apache Qpid = message brokers (project is hosted on github - https://github.com/pcolby/pcp-pmda-qpid).

Is it possible to get an official domain number allocat= ed for this PMDA? =A0Or should I just choose something randomly from the &q= uot;End-User PMDAs and demo PMDAs" range?

Thanks,
Paul Colby
----
http://colby.id.au=
--001a1132f28e2a502304f20a87b8-- From pcolby@gmail.com Mon Feb 10 04:14:43 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 19CC87F3F for ; Mon, 10 Feb 2014 04:14:43 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id F37BA8F8033 for ; Mon, 10 Feb 2014 02:14:42 -0800 (PST) X-ASG-Debug-ID: 1392027281-04cbb00c2b239fa0001-S8gJnT Received: from mail-yh0-f41.google.com (mail-yh0-f41.google.com [209.85.213.41]) by cuda.sgi.com with ESMTP id TmsagW242bHqoXjJ (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 10 Feb 2014 02:14:41 -0800 (PST) X-Barracuda-Envelope-From: pcolby@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.213.41 X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.41] Received: by mail-yh0-f41.google.com with SMTP id f73so4883332yha.0 for ; Mon, 10 Feb 2014 02:14:41 -0800 (PST) X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.41] X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.41] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=hmc0K5pCymMrINnxcUuGn7YxRTtVdJ42d39mi0ktR8U=; b=DNbc8FLG3BFdTNCQJS72zM/cxRPHc1ndhP5IR3YIB1LFNz2ggX/ZCwFPKs0hCMzwiF UfFLdwGT9urt7dDfPL4ZbGQhrpwyD5zloCW72QLgq2YR6VJ7QqT3q3wOnZiydSS5ZKpY RN4K7mD5HfBdP1jciCO/5mwKYYLKDkMWUCQAeQzCaA7gaAx6Goc1BKGPtZ7m4RdlA522 SyCzcmS+jKmq9nvHK/k8VGBzHH5KTP2eGs8Z49BDWTJK4c+1k4/o1zOziNH3EkxWV/xF 2PQwk6N+7cetENTK31xHd1P5l/BP/myf12FfyitiMNhvV/ooX/XIkUCZFeK94ooRhG4J j8XA== MIME-Version: 1.0 X-Received: by 10.236.2.166 with SMTP id 26mr602318yhf.79.1392027281063; Mon, 10 Feb 2014 02:14:41 -0800 (PST) Sender: pcolby@gmail.com Received: by 10.170.159.196 with HTTP; Mon, 10 Feb 2014 02:14:41 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Feb 2014 21:14:41 +1100 X-Google-Sender-Auth: eEMrr5gE0qCJEE3LpVFgI26ugNM Message-ID: Subject: Fwd: Official domain number for my Qpid PMDA project? From: Paul Colby X-ASG-Orig-Subj: Fwd: Official domain number for my Qpid PMDA project? To: pcp@oss.sgi.com Content-Type: multipart/alternative; boundary=089e013a10529b052504f20a9b70 X-Barracuda-Connect: mail-yh0-f41.google.com[209.85.213.41] X-Barracuda-Start-Time: 1392027281 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-BRTS-Evidence: colby.id.au X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144990 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message --089e013a10529b052504f20a9b70 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, I'm close to the first release of a PMDA I've been writing for exposing metrics from Apache Qpid message brokers (project is hosted on github - https://github.com/pcolby/pcp-pmda-qpid). Is it possible to get an official domain number allocated for this PMDA? Or should I just choose something randomly from the "End-User PMDAs and demo PMDAs" range? Thanks, Paul Colby ---- http://colby.id.au --089e013a10529b052504f20a9b70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys,
<= br>
I'm close to the first release of a PMDA I've been wr= iting for exposing metrics from Apache Qpid message brokers (project is hos= ted on github - https://github.com/pcolby/pcp-pmda-qpid).

Is it possible to get an official domain number allocat= ed for this PMDA? =A0Or should I just choose something randomly from the &q= uot;End-User PMDAs and demo PMDAs" range?

Thanks,
Paul Colby
----
= http://colby.id.au

--089e013a10529b052504f20a9b70-- From nscott@redhat.com Mon Feb 10 04:27:41 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8E7037F3F for ; Mon, 10 Feb 2014 04:27:41 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7AB29304043 for ; Mon, 10 Feb 2014 02:27:38 -0800 (PST) X-ASG-Debug-ID: 1392028046-04cb6c6de2244a90001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id yA3svqdZpz0k81Ak for ; Mon, 10 Feb 2014 02:27:26 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1AARP5Q005614; Mon, 10 Feb 2014 05:27:25 -0500 Date: Mon, 10 Feb 2014 05:27:24 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Paul Colby Cc: pcp@oss.sgi.com Message-ID: <480923908.1506080.1392028044682.JavaMail.zimbra@redhat.com> In-Reply-To: References: Subject: Re: [pcp] Fwd: Official domain number for my Qpid PMDA project? MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] Fwd: Official domain number for my Qpid PMDA project? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Official domain number for my Qpid PMDA project? Thread-Index: VFM1qQWuUyyqaejE3eKdVaxlfb02WQ== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392028046 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.144990 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Paul, ----- Original Message ----- > Hi guys, > > I'm close to the first release of a PMDA I've been writing for exposing > metrics from Apache Qpid message brokers (project is hosted on github - > https://github.com/pcolby/pcp-pmda-qpid ). Congrats, nice work. > Is it possible to get an official domain number allocated for this PMDA? Or > should I just choose something randomly from the "End-User PMDAs and demo > PMDAs" range? > The next free slot was 124 - its all yours. Let us know if you'd like any code review - I don't know anything about Qpid though. Do you want a link or two on http://oss.sgi.com/projects/pcp/source.html for those trees? cheers. -- Nathan From wwwrun@oss.sgi.com Mon Feb 10 16:40:56 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,NO_RELAYS autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: by oss.sgi.com (Postfix, from userid 30) id 878D77F53; Mon, 10 Feb 2014 16:40:56 -0600 (CST) From: bugzilla-daemon@oss.sgi.com To: pcp@oss.sgi.com Subject: [Bug 947] Mising QA for apache PMDA Date: Mon, 10 Feb 2014 22:40:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Classification: Unclassified X-Bugzilla-Product: pcp X-Bugzilla-Component: pcp X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: nathans@debian.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: mort@sgi.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: multipart/alternative; boundary="1392072056.bA2C32.16857"; charset="us-ascii" X-Bugzilla-URL: http://oss.sgi.com/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 --1392072056.bA2C32.16857 Date: Mon, 10 Feb 2014 16:40:56 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" http://oss.sgi.com/bugzilla/show_bug.cgi?id=947 Nathan Scott changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nathans@debian.org Resolution|--- |FIXED --- Comment #1 from Nathan Scott --- This PMDA is exercised via qa test 755 now. -- You are receiving this mail because: You are on the CC list for the bug. --1392072056.bA2C32.16857 Date: Mon, 10 Feb 2014 16:40:56 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" changed bug 947
What Removed Added
Status NEW RESOLVED
CC   nathans@debian.org
Resolution --- FIXED

Comment # 1 on bug 947 from 
This PMDA is exercised via qa test 755 now.

You are receiving this mail because:
  • You are on the CC list for the bug.
--1392072056.bA2C32.16857-- From wwwrun@oss.sgi.com Mon Feb 10 16:40:56 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,NO_RELAYS autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: by oss.sgi.com (Postfix, from userid 30) id BFA527F53; Mon, 10 Feb 2014 16:40:56 -0600 (CST) From: bugzilla-daemon@oss.sgi.com To: pcp@oss.sgi.com Subject: [Bug 948] PMDAs should not be shipped without some QA coverage Date: Mon, 10 Feb 2014 22:40:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Classification: Unclassified X-Bugzilla-Product: pcp X-Bugzilla-Component: pcp X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: nathans@debian.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: kenj@internode.on.net X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: multipart/alternative; boundary="1392072056.6ea7F4.16857"; charset="us-ascii" X-Bugzilla-URL: http://oss.sgi.com/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 --1392072056.6ea7F4.16857 Date: Mon, 10 Feb 2014 16:40:56 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" http://oss.sgi.com/bugzilla/show_bug.cgi?id=948 Bug 948 depends on bug 947, which changed state. Bug 947 Summary: Mising QA for apache PMDA http://oss.sgi.com/bugzilla/show_bug.cgi?id=947 What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug. --1392072056.6ea7F4.16857 Date: Mon, 10 Feb 2014 16:40:56 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Bug 948 depends on bug 947, which changed state.
What Removed Added
Status NEW RESOLVED
Resolution --- FIXED

You are receiving this mail because:
  • You are on the CC list for the bug.
--1392072056.6ea7F4.16857-- From nscott@redhat.com Mon Feb 10 16:59:43 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 62D6F7F3F for ; Mon, 10 Feb 2014 16:59:43 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id D5151AC00B for ; Mon, 10 Feb 2014 14:59:42 -0800 (PST) X-ASG-Debug-ID: 1392073177-04cb6c6de025c350001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id 3Gi8doL5hNDbim6s for ; Mon, 10 Feb 2014 14:59:37 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1AMxbHl021569 for ; Mon, 10 Feb 2014 17:59:37 -0500 Date: Mon, 10 Feb 2014 17:59:37 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: PCP Mailing List Message-ID: <1886819671.2652837.1392073177289.JavaMail.zimbra@redhat.com> In-Reply-To: <712415083.2652508.1392073122259.JavaMail.zimbra@redhat.com> Subject: pcp updates: docs, stdpmid, pmda installs MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: docs, stdpmid, pmda installs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: docs, stdpmid, pmda installs Thread-Index: hW6EQaUF88+q2oHAgI3CmM48KYnzyw== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392073177 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145007 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev man/man1/pmdakernel.1 | 4 -- qa/755 | 98 ++++++++++++++++++++++++++++++++++++++++++++++++++ qa/755.out | 23 +++++++++++ qa/group | 2 + src/pmcd/pmdaproc.sh | 16 ++++++++ src/pmns/stdpmid.pcp | 3 + 6 files changed, 142 insertions(+), 4 deletions(-) commit 0b1500ff74341c54c3da4412eb8ee8db9c58cf41 Author: Nathan Scott Date: Tue Feb 11 09:54:07 2014 +1100 Allow PMDA Install scripts to be run even when pmcd is stopped. Following the Install recipe from the GFS2 PMDA man page, users can run into difficulty if pmcd is not running first. There's no mention of that, and the error message is cryptic. This fix extends the generic PMDA installation process to allow any PMDA to kick-start the pmcd process if it needs to. The one wrinkle there is a chicken-and-egg with the namespace setup, but that's tackled via addition of a Rebuild call in the right spot. Reported by Andrew Price, tested by Paul Evans, myself and now also PCP QA test 755. Resolves Red Hat bug #1062443. commit 1e4c93c4000a6b3314c6995d1f38ed8703736114 Author: Nathan Scott Date: Mon Feb 10 21:31:56 2014 +1100 Add nfsclient PMDA domain number to stdpmid list, missed earlier commit 2ffaf381f12853c3f6196ad943ac22e32f14a263 Author: Nathan Scott Date: Mon Feb 10 21:28:54 2014 +1100 Reserve domain numbers for nfsclient and Qpid PMDAs commit b3bdc8db5fd1b9ae4eae7339e936c8fa56a4879d Author: Nathan Scott Date: Mon Feb 10 13:56:31 2014 +1100 Fix errors on the recently added kernel PMDAs man page There is a separate pmdaproc man page, so listing that here gives warnings ("file listed twice") during packaging phase. Also, "kernel PMDA" is too generic a term to use in the NAME section as 'apropos kernel' then hits on this man page - fix that as well. From pcolby@gmail.com Mon Feb 10 17:31:15 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 0641E7F3F for ; Mon, 10 Feb 2014 17:31:15 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id CC0CB304032 for ; Mon, 10 Feb 2014 15:31:11 -0800 (PST) X-ASG-Debug-ID: 1392075066-04bdf0122026fae0001-S8gJnT Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) by cuda.sgi.com with ESMTP id qVR1iTxCehKR2F2H (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Mon, 10 Feb 2014 15:31:07 -0800 (PST) X-Barracuda-Envelope-From: pcolby@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.213.44 X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.44] Received: by mail-yh0-f44.google.com with SMTP id f73so6022003yha.17 for ; Mon, 10 Feb 2014 15:31:06 -0800 (PST) X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.44] X-Barracuda-IPDD: Level1 [gmail.com/209.85.213.44] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WnotccXl/qvkibwgurhj0i9Mmgo2do3UwDiGtHDPI+4=; b=bzYOBHWf5dFsY8iZ3flF5xKoWF2pfX1KPQkOO+iJ/RUZAsXAiffL9aRl3e+TRd4PCl bQB9mZpGxJ2RgidmAhRaNWX4toyogp4VbQPxrFkd24xB3LB11GqVpIg9/76BumnD83kG HaC305IG9D755u39VresCAeLlYadI6abd5lcXfnRGbXk1aktEcoT+U/FT4OedZxcEtQ1 64f3dkqBTyDx07YNHv9XP69zwEWmFceA0WGurmox5e4A/ZIg2p4Izkmhkz/ul1zEsWgH 82g/Y4te5D17isHn1xoFLVXf8aPNQD3CxrQ6t7CV5c7r187S7j3yPKssOlFK3CJbjuHO bTJg== MIME-Version: 1.0 X-Received: by 10.236.79.196 with SMTP id i44mr4163804yhe.80.1392075066532; Mon, 10 Feb 2014 15:31:06 -0800 (PST) Sender: pcolby@gmail.com Received: by 10.170.159.196 with HTTP; Mon, 10 Feb 2014 15:31:06 -0800 (PST) In-Reply-To: <480923908.1506080.1392028044682.JavaMail.zimbra@redhat.com> References: <480923908.1506080.1392028044682.JavaMail.zimbra@redhat.com> Date: Tue, 11 Feb 2014 10:31:06 +1100 X-Google-Sender-Auth: CLXJguk-4UX9BIJdQRFimIvPmKs Message-ID: Subject: Re: [pcp] Fwd: Official domain number for my Qpid PMDA project? From: Paul Colby X-ASG-Orig-Subj: Re: [pcp] Fwd: Official domain number for my Qpid PMDA project? To: Nathan Scott Cc: pcp@oss.sgi.com Content-Type: text/plain; charset=ISO-8859-1 X-Barracuda-Connect: mail-yh0-f44.google.com[209.85.213.44] X-Barracuda-Start-Time: 1392075067 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145009 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature > > I'm close to the first release of a PMDA I've been writing for exposing > > metrics from Apache Qpid message brokers (project is hosted on github - > > https://github.com/pcolby/pcp-pmda-qpid ). > > Congrats, nice work. Thanks :) > The next free slot was 124 - its all yours. Perfect! Thanks :) > Let us know if you'd like any > code review - I don't know anything about Qpid though. Code review would be excellent. There's still lots about PCP (and Qpid) that I haven't fully grok'd yet, so I'm sure there's plenty of opportunities for improvement. > Do you want a link > or two on http://oss.sgi.com/projects/pcp/source.html for those trees? Yes, I would really like that :) Thanks again, Paul. From nscott@redhat.com Tue Feb 11 02:20:39 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C0DFC7F3F for ; Tue, 11 Feb 2014 02:20:39 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 65B12AC009 for ; Tue, 11 Feb 2014 00:20:39 -0800 (PST) X-ASG-Debug-ID: 1392106833-04cb6c6de3275f30001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id BgXsvc0OFDIhxGre for ; Tue, 11 Feb 2014 00:20:33 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1B8KWt4030121 for ; Tue, 11 Feb 2014 03:20:32 -0500 Date: Tue, 11 Feb 2014 03:20:32 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: PCP Mailing List Message-ID: <1610352573.2944972.1392106832135.JavaMail.zimbra@redhat.com> In-Reply-To: <1932184367.2944003.1392106719881.JavaMail.zimbra@redhat.com> Subject: pcp updates: multilib support MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: multilib support Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: multilib support Thread-Index: 3x9MxzFqpPvi2RWtdCdt3u2Jg1dRxA== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392106833 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145020 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev VERSION.pcp | 4 build/rpm/fedora.spec | 30 ++ build/rpm/pcp.spec.in | 35 ++- configure | 13 - configure.in | 6 debian/GNUmakefile | 13 + debian/changelog | 5 debian/control | 17 + debian/libpcp3.dirs | 1 debian/libpcp3.install | 3 debian/pcp-conf.dirs | 1 debian/pcp-conf.install | 3 debian/rules | 8 qa/156 | 5 qa/156.out.3 | 329 +++++++++++++++++++++++++++++++ qa/642 | 5 qa/642.out.4 | 95 ++++++++ src/include/buildrules | 1 src/include/pcp/.gitignore | 1 src/include/pcp/GNUmakefile | 12 - src/include/pcp/config.h.in | 24 +- src/include/pcp/config32.h | 23 ++ src/include/pcp/config64.h | 23 ++ src/include/pcp/configsz.h.in | 24 ++ src/pmdas/sample/.gitignore | 1 src/pmdas/sample/GNUmakefile | 28 -- src/pmdas/sample/domain.h | 4 src/pmdas/sample/src/.gitignore | 3 src/pmdas/sample/src/GNUmakefile | 22 +- src/pmdas/sample/src/GNUmakefile.install | 53 ++++ src/pmdas/sample/src/events.c | 6 src/pmdas/sample/src/percontext.c | 6 src/pmdas/sample/src/pmda.c | 8 src/pmdas/sample/src/sample.c | 12 - src/pmdas/txmon/GNUmakefile | 3 35 files changed, 734 insertions(+), 93 deletions(-) commit 8fe72ef673aa98b419077f4a4f9852336dce4df0 Author: Nathan Scott Date: Tue Feb 11 19:16:55 2014 +1100 Final phase of rpm multilib support - workaround config.h differences Use the http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks technique ("myautoconf.h files with a size in them") for avoiding the final problem in terms of multilib support. commit 8d4a8eb3fcbee1d0f0e90cc6207b6db7b90dd5c8 Author: Nathan Scott Date: Tue Feb 11 15:48:16 2014 +1100 Changes to pcp.conf packaging to support "multilib" packaging Move the configuration files (pcp.conf in particular, as it is not architecture neutral) from pcp-libs into a new pcp-conf package for both rpm and deb formats. As this is a fairly major packaging shift that people will at times probably need to refer back to, bump the minor version number (3.8.x -> 3.9.0). A dependency exists between pcp-libs and pcp-conf of course, but this is no longer arch dependent. This is part two of three for rpm "multilib" support for pcp, where both 32 and 64 bit variants of the -libs and -libs-devel packages can be simultaneously installed. It also happens to resolve a long-standing Debian bug, so its got that goin' for it, which is nice. commit 5f102b1aa2816fc2e8c5e24674b83075f988ab03 Author: Nathan Scott Date: Tue Feb 11 12:27:04 2014 +1100 Changes to pmdatxmon to support multlib devel packages This removes architecture-dependent files in the development package related to pmdatxmon. Instead of installing prebuilt binaries, we now use the pmdasimple/pmdatrivial technique of installing a makefile and generating them. commit 56ebe5fde238569be2c8b5b4babc9430eedb3616 Author: Nathan Scott Date: Tue Feb 11 10:48:14 2014 +1100 Changes to pmdasample to support multlib devel packages This removes architecture-dependent files in the development package related to pmdasample. Instead of installing prebuilt binaries, we now use the pmdasimple/pmdatrivial technique of installing a makefile and generating them. There's a bit of code tweaking in terms of header includes and domain number file generation, making pmdasample code match up more closely now with the other devel PMDAs. From nscott@redhat.com Tue Feb 11 16:46:24 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A13CA7F50 for ; Tue, 11 Feb 2014 16:46:24 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 44616AC013 for ; Tue, 11 Feb 2014 14:46:24 -0800 (PST) X-ASG-Debug-ID: 1392158778-04cbb00c2a2afa70001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id i3C71pSdaDl3syP6 for ; Tue, 11 Feb 2014 14:46:19 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1BMkIsO018588 for ; Tue, 11 Feb 2014 17:46:18 -0500 Date: Tue, 11 Feb 2014 17:46:17 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp@oss.sgi.com Message-ID: <1534384404.4479991.1392158777904.JavaMail.zimbra@redhat.com> In-Reply-To: <1582655005.17610093.1391417702242.JavaMail.root@redhat.com> References: <1288830274.15173866.1390972567394.JavaMail.root@redhat.com> <2079478185.15183762.1390974204857.JavaMail.root@redhat.com> <850081097.15891604.1391033712900.JavaMail.root@redhat.com> <1582655005.17610093.1391417702242.JavaMail.root@redhat.com> Subject: Re: [pcp] Multi-lib support problem & possible fix MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] Multi-lib support problem & possible fix Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Multi-lib support problem & possible fix Thread-Index: psaUaQnOCjQZO7fRfpZNSS5VtrpLuewRQLfm X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392158779 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145035 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > ----- Original Message ----- > > ... > Starting to sound a bit like that original plan I'd described ... I'll > experiment with something along those lines shortly, and report back. Just closing the loop on this - turned out the original plan worked out (the big question mark was the dependency mixing of 32 vs 64 configs), and pcp-libs and pcp-libs-devel multilib code was committed last night. After much rpm2cpio diff verification and installation combo testing, it'd appear we have now achieved multilib goodness. > $ pminfo -f rpm.size | egrep '"coreutils|"pcp-libs-devel' > inst [863 or "pcp-libs-devel-3.8.13-1.x86_64"] value 1766815 > inst [1656 or "coreutils-8.4-19.el6.x86_64"] value 12847030 BTW, I got this bit wrong in hindsight - we were discussing binutils and not coreutils. But oddly that is even smaller (on RHEL6): inst [65 or "binutils-2.20.51.0.2-5.34.el6.x86_64"] value 9814650 *shrug* ... somehow its doubled in size in more recent versions (or both 32 & 64 bit variants installed). Doesn't really matter, just pointing out the error of my ways there. cheers. -- Nathan From scox@redhat.com Wed Feb 12 13:07:46 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 37E447F4E for ; Wed, 12 Feb 2014 13:07:46 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 1BD378F8064 for ; Wed, 12 Feb 2014 11:07:45 -0800 (PST) X-ASG-Debug-ID: 1392232061-04bdf01d0b078f0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id RzzdD8cnNngQfR7w for ; Wed, 12 Feb 2014 11:07:41 -0800 (PST) X-Barracuda-Envelope-From: scox@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1CJ7emQ014755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 12 Feb 2014 14:07:40 -0500 Received: from [10.10.50.16] (vpn-50-16.rdu2.redhat.com [10.10.50.16]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1CJ7eJB009266; Wed, 12 Feb 2014 14:07:40 -0500 Message-ID: <52FBC67B.5020300@redhat.com> Date: Wed, 12 Feb 2014 14:07:39 -0500 From: Stan Cox User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Scott CC: PCP Mailing List Subject: Re: pcp-programmers-guide.xml References: <52F50F51.1020504@redhat.com> <1064102940.1296710.1392011264511.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: pcp-programmers-guide.xml In-Reply-To: <1064102940.1296710.1392011264511.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392232061 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 I think I caught everything you noted. The current version is on: ssh://sourceware.org/git/pcpfans.git branch "scox/pcp-books" > - pmNameID vs pmNameInDom -> different style (str vs "string") I went with the "string description" style. I put every user variable name in italics. > Re the python exception handling - er, wow - its that easy? :] > Can you really import a module within an exception handler? > Also, should the "print freemem" be earlier on? Yes indeed. I pulled that from a live example. The print is okay, just a pythonism, it is undented after the exception handler. > Its a tough slog working on these books I tried using xmlcopyeditor but ended up using emacs nXML mode side by side with the pdf output. From brolley@redhat.com Wed Feb 12 16:23:52 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 793557F52 for ; Wed, 12 Feb 2014 16:23:52 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 4C2348F8035 for ; Wed, 12 Feb 2014 14:23:49 -0800 (PST) X-ASG-Debug-ID: 1392243828-04bdf01d0b16660001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id cGAoQB60kymnj3U6 for ; Wed, 12 Feb 2014 14:23:48 -0800 (PST) X-Barracuda-Envelope-From: brolley@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1CMNlhp020518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 12 Feb 2014 17:23:48 -0500 Received: from [10.15.16.178] (dhcp-10-15-16-178.yyz.redhat.com [10.15.16.178]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1CMNltp011207 for ; Wed, 12 Feb 2014 17:23:47 -0500 Message-ID: <52FBF489.2080401@redhat.com> Date: Wed, 12 Feb 2014 17:24:09 -0500 From: Dave Brolley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: PCP Updates: IPv6 and Unix Domain Sockets for pmlogger and pmlc Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ASG-Orig-Subj: PCP Updates: IPv6 and Unix Domain Sockets for pmlogger and pmlc Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392243828 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 commit 5246cf21147191e3b1ef6d9448f0b92f5a2e9d2a Merge: 64ba262 8fe72ef Author: Dave Brolley Date: Wed Feb 12 17:06:22 2014 -0500 Merge remote-tracking branch 'origin/dev' into brolley/dev commit 64ba262d1beb232703013db4001cb512d1790ff3 Author: Dave Brolley Date: Wed Feb 12 17:02:49 2014 -0500 Support ipv6 and unix domain socket control connections in pmlogger and pmlc. pmlogger now listens on ipv6 and on a local unix domain socket (on supported platforms) for control connections. pmlc can now use ipv6 addresses as well as unix:{path] and local:[path] urls to connect to pmlogger. commit dcf64bb7b71d3d0aa3717ec79ff3a3c1d613031b Author: Dave Brolley Date: Wed Feb 12 10:37:12 2014 -0500 pmlc: ConnectPMCD: Catch potential NULL return from strdup. commit 8e8684fd55ed95627bca8b20f67c3c633e651721 Author: Dave Brolley Date: Wed Feb 12 10:32:53 2014 -0500 Handle PR_AF_LOCAL in the NSPR implementation of __pmGetNameInfo. Was already handled by the native implementation. --------------------------------------------------- With these changes, on supported platforms, pmlogger now opens IPv6 sockets on the configured ports and a unix domain docket for control connections. The unix domain socket is named pmlogger..socket and is created in PCP_RUN_DIR (the same location as pmcd.socket). If the pmlogger is primary, a hard link to the socket called pmlogger.primary.socket is also created in the same directory. On supported platforms, pmlc can now connect to pmlogger via its ipv6 and unix domain sockets. Ipv6 addresses may now be specified on the -h option. As with pmcd, the -h option of pmlc now also supports the unix:[path] and local:[path] urls. As with pmcd, the local: url means to try unix: first followed by localhost, if unsuccessful. These urls are used in combination with the -P, -p and arguments to select the correct socket as follows: -h unix:/some/path - attempts to connect using the socket at /some/path -h unix:/some/path -P - rejected: conflicting requests -h unix:/some/path -p - rejected: unix domain sockets do not use a port number -h unix:/some/path - rejected: conflicting requests -h unix: - rejected: not enough information -h unix: -P - attempts to connect using the socket at $PCP_RUN_DIR/pmlogger.primary.socket -h unix: -p - rejected: unix domain sockets do not use a port number -h unix: - attempts to connect using the socket at $PCP_RUN_DIR/pmlogger..socket -h local:/some/path - attempts to connect using the socket at /some/path -h local:/some/path -P - attempts to connect using the socket at /some/path if unsuccessful, tries to connect as in -h localhost -P -h local:/some/path -p - attempts to connect using the socket at /some/path if unsuccessful, tries to connect as in -h localhost -p -h local:/some/path - attempts to connect using the socket at /some/path if unsuccessful, tries to connect as in -h localhost -h local: - rejected: not enough information -h local -P - attempts to connect using the socket at $PCP_RUN_DIR/pmlogger.primary.socket if unsuccessful, tries to connect as in -h localhost -P -h local: -p - attempts to connect as in -h localhost -p -h local: - attempts to connect using the socket at $PCP_RUN_DIR/pmlogger..socket if unsuccessful, tries to connect as in -h localhost The default for -h is now local: Similarly, unix:[path] and local:[path] urls are now allowed on 'show loggers' and 'connect' commands in the pmlc interactive command interpreter. They have the same effect on selection of a pmlogger as above. IPv6 addresses are not supported here because inet addresses are also not currently supported. The pmlogger access controls have also been updated, in the same way as pmcd was, to accept ipv6 addresses and wildcards as well as unix:[path] and local:[path] urls and wildcards. The default pmlogger access control has been changed to [access] disallow .* : all; disallow :* : all; allow local:* : enquire; and pmlogconf.sh has been updated accordingly along with _writable_primary_logger and _restore_primary_logger in qa/common.check. With respect to pmlogconf.sh, I expected it to be run as part of the build process or as part of the rpm install, however it does not appear to be. These access control changes are now necessary for correct accesss to pmlogger since the old "disallow * : all;" prevents access via unix:. A similar change was required for the default pmcd access controls at the time they were implemented. How do we ensure that all users get the updated access config for pmlogger? There is some qa fallout due to altered output for some tests with respect to host names. I am in the process of addressing these. Comments please! Dave From nscott@redhat.com Wed Feb 12 23:14:07 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 0091E7F58 for ; Wed, 12 Feb 2014 23:14:07 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id D93018F8037 for ; Wed, 12 Feb 2014 21:14:03 -0800 (PST) X-ASG-Debug-ID: 1392268438-04cb6c6de1330c90001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id Tw7M4dY7XQJIrie6 for ; Wed, 12 Feb 2014 21:13:59 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1D5Dvaa028522; Thu, 13 Feb 2014 00:13:57 -0500 Date: Thu, 13 Feb 2014 00:13:57 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Paul Colby Cc: pcp@oss.sgi.com Message-ID: <2141282812.6069067.1392268437554.JavaMail.zimbra@redhat.com> In-Reply-To: References: <480923908.1506080.1392028044682.JavaMail.zimbra@redhat.com> Subject: Re: [pcp] Fwd: Official domain number for my Qpid PMDA project? MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] Fwd: Official domain number for my Qpid PMDA project? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Official domain number for my Qpid PMDA project? Thread-Index: gqpKrflsjODfNknnJUlD2oDIpMR8eA== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392268438 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145071 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Paul, ----- Original Message ----- > > ... > > code review - I don't know anything about Qpid though. > > Code review would be excellent. There's still lots about PCP (and > Qpid) that I haven't fully grok'd yet, so I'm sure there's plenty of > opportunities for improvement. > Wow, that is some neat code - I bet you have no loose papers on your desk ;) - all tested, valgrind used, the class encapsulation looks very nice in the end result PMDA, just generally neat. Your C++-fu far outshines mine! :) I'm appreciating all the metric help text - it all looks sensible & the units and semantics used appear to be spot on. Just good stuff all round - again, well done! Not sure if you came across dbpmda(1), but this option... options.add_options() ("no-pmda", bool_switch(), "run as a non-PMDA for development"); ... made me wonder. I use either/or in testing (PMDA options and/or dbpmda), so having the option is still useful - just mentioning the tool in case you'd not come across it yet. Can be run as a regular user, so can be simpler (and more targeted) than using pmcd itself. > > Do you want a link > > or two on http://oss.sgi.com/projects/pcp/source.html for those trees? > > Yes, I would really like that :) > Done. cheers. -- Nathan From nscott@redhat.com Thu Feb 13 00:22:48 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 7E4D37F58 for ; Thu, 13 Feb 2014 00:22:48 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id EF724AC006 for ; Wed, 12 Feb 2014 22:22:44 -0800 (PST) X-ASG-Debug-ID: 1392272562-04cb6c6de1334450001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id FNOqtBlDyGOpmYd1 for ; Wed, 12 Feb 2014 22:22:43 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1D6MgbE007594; Thu, 13 Feb 2014 01:22:42 -0500 Date: Thu, 13 Feb 2014 01:22:42 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: PCP Message-ID: <1095368295.6085212.1392272562364.JavaMail.zimbra@redhat.com> In-Reply-To: <633105491.21839148.1391757935531.JavaMail.root@redhat.com> References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1583484726.15908616.1391037005341.JavaMail.root@redhat.com> <20140130181134.GA7584@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> <20140206133220.GC5017@redhat.com> <633105491.21839148.1391757935531.JavaMail.root@redhat.com> Subject: Re: [pcp] pmmgr pmlogger default behaviour MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmmgr pmlogger default behaviour Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmmgr pmlogger default behaviour Thread-Index: 4zUJYw7lY83fKCtq6pmffEzheIDKomPcg36O X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392272563 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145072 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi Frank, ----- Original Message ----- > > ... > I'll stew on this over the weekend, and attempt to come up with some > possible directions forward for us here, seeking compromise. It feels > a bit like we're going in circles by email here now, and we need a new > tack as we're stale-mated on each others needs/concerns. As discussed on IRC earlier this week, I'm uncomfortable continuing to release this as-is, as part of a default install. I'm also not going to (would never) simply jump in and start taking a big red pen to the configuration/code in an area you're passionate about like this. So, I think the best way forward will be to create a new pcp-manager sub-package within PCP, optionally installed, with the defaults as you like 'em for now. This'll give us more time to continue to assess and evolve, hopefully toward the safer, more efficient and environmentally friendly solution that I prefer. ;) After a few more releases, if the three of us still cannot find common ground, we have an option then of making a separate project out of the pcp-manager code and having two source trees respectfully go on their separate ways. Maybe not holding hands, walking into the sunset - but at least they might still be pen-pals. This also provides scope to flag this package as containing a much more aggressive schedule for enabling new/experimental features (different to the cast-in-stone must-be-100%-backward-compatible mantra we attempt to carry off for the rest of PCP). Appreciate the doc updates in the fche/dev branch too - naturally, they don't quite give the punter as much warning as I feel they should, but its a good start - thanks! cheers. -- Nathan From nscott@redhat.com Thu Feb 13 01:47:43 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 049FF7F58 for ; Thu, 13 Feb 2014 01:47:43 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 6F57FAC005 for ; Wed, 12 Feb 2014 23:47:39 -0800 (PST) X-ASG-Debug-ID: 1392277652-04cb6c6de13378e0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id 1ly1JZlMS1vh8IU3 for ; Wed, 12 Feb 2014 23:47:33 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1D7lWm1007150 for ; Thu, 13 Feb 2014 02:47:32 -0500 Date: Thu, 13 Feb 2014 02:47:32 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: PCP Message-ID: <1116704166.6120773.1392277652694.JavaMail.zimbra@redhat.com> In-Reply-To: <964461579.6117843.1392277555477.JavaMail.zimbra@redhat.com> Subject: pcp updates: pmdalinux vs valgrind vs s390x, packaging split MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: pmdalinux vs valgrind vs s390x, packaging split Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: pmdalinux vs valgrind vs s390x, packaging split Thread-Index: STU4TTfSUMUHzTpkDSR2FpE4VZlxBQ== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392277652 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145074 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev build/rpm/fedora.spec | 115 +++++++++++++++++++++++++++++------- build/rpm/pcp.spec.in | 130 +++++++++++++++++++++++++++++++++-------- debian/GNUmakefile | 31 ++++++++- debian/control | 26 ++++++++ debian/libpcp3-dev.install | 1 debian/pcp-manager.dirs | 2 debian/pcp-manager.install | 11 +++ debian/pcp-manager.postinst | 14 ++++ debian/pcp-manager.postrm | 6 + debian/pcp-manager.prerm | 8 ++ debian/pcp-webapi.dirs | 2 debian/pcp-webapi.install | 5 + debian/pcp-webapi.postinst | 14 ++++ debian/pcp-webapi.postrm | 6 + debian/pcp-webapi.prerm | 8 ++ debian/pcp.postinst.tail | 11 --- debian/pcp.postrm.tail | 3 debian/pcp.preinst.tail | 2 debian/pcp.prerm | 2 debian/rules | 13 ++++ src/pmdas/linux/proc_cpuinfo.c | 5 + src/pmdas/linux/proc_stat.c | 64 +++++++++++--------- 22 files changed, 385 insertions(+), 94 deletions(-) commit 1d7cbdeb246410ffba4d48570fce21d0b2168484 Author: Nathan Scott Date: Thu Feb 13 14:46:27 2014 +1100 Packaging changes to support pcp-manager and pcp-webapi split Migrate pmmgr(1) and pmwebd(1) daemons into their own packages. This allows for independent development on pmmgr and potentially aggressive enablement of new features there, as well as removing the (non-default install) libmicrohttpd dependency from the core PCP packages. Now's a good time - we're splitting packages for multilib in the next release anyway, so do these packaging changes all at once. commit f5eaeea7900390ae007f5ed3375cadc6ca86497e Author: Nathan Scott Date: Thu Feb 13 14:20:52 2014 +1100 Fix s390x platform issues in /proc/cpuinfo parser The format of /proc/cpuinfo on s390x is nothing like any other platform. We cannot attempt to push it through the same code path, it simply has nothing in common. If we try (as we used to) things fall apart when we use the (negative) cpu number local variable to index into the cpuinfo array. Resolved by adding in some defensive code to short-circuit the decoding logic when an unexpected file format is seen. commit 5ebdf2fe3f1aca661ed1a13a6aa45e3c27d228c2 Author: Nathan Scott Date: Thu Feb 13 14:12:49 2014 +1100 Fix valgrind errors in pmdalinux /proc/stat refresh This one has bugged me for a long time, and I finally needed to spend some time hunting an obscure memory corruption in pmdalinux - so got to revisit this properly. There were a few small problems in refresh_proc_stat causing valgrind to report "invalid read of zero size". Most problematic was the code reading the stat buffer initially, which slightly confuses the offset and size combo in passing a buffer pointer to read(2). The realloc call here also happened to allocate 8x the (small) memory it wanted, accidently multiplying the size by sizeof(char). The nbufindex calculation also ended up with one more line than was in the buffer, which was OK because it always created an empty line at the end of it (which doesn't actually exist in /proc/stat). Finally, added some small improvements to the handling of ENOMEM for these global stat buffers, and removed a double-memset on the initial call (which callocs a zeroed buffer). From fche@redhat.com Thu Feb 13 06:58:18 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id F36457F58 for ; Thu, 13 Feb 2014 06:58:17 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 8A372AC002 for ; Thu, 13 Feb 2014 04:58:17 -0800 (PST) X-ASG-Debug-ID: 1392296293-04bdf0122036b5e0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id sQpU1MyUTOhIOXRo for ; Thu, 13 Feb 2014 04:58:13 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1DCwDXc023339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 13 Feb 2014 07:58:13 -0500 Received: from fche.csb (vpn-235-28.phx2.redhat.com [10.3.235.28]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1DCwCsZ012579; Thu, 13 Feb 2014 07:58:12 -0500 Received: by fche.csb (Postfix, from userid 2569) id 86F19580F6; Thu, 13 Feb 2014 07:58:11 -0500 (EST) Date: Thu, 13 Feb 2014 07:58:11 -0500 From: "Frank Ch. Eigler" To: Nathan Scott Cc: pcp developers Subject: Re: Possible pmmgr issue? Message-ID: <20140213125811.GG11820@redhat.com> X-ASG-Orig-Subj: Re: Possible pmmgr issue? References: <1952377955.6159460.1392281163287.JavaMail.zimbra@redhat.com> <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392296293 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - > [...] > Note the size of the 2 merge archives. I need to clean this up, > as my rootfs is out of space once more. Any suggestions on what > to look for before I do that? Thanks. >From what I see, it looks like you just happened to catch the machine mid-merge, just after the pmcd was lost & restarted, so pmmgr stopped & restarted the pmlogger. > -rw-r--r-- 1 pcp pcp 546M Feb 13 14:34 merged-archive-20140213.033222.0 > -rw-r--r-- 1 pcp pcp 85K Feb 13 14:34 merged-archive-20140213.033222.index > -rw-r--r-- 1 pcp pcp 144K Feb 13 14:34 merged-archive-20140213.033222.meta > -rw-r--r-- 1 pcp pcp 335M Feb 13 19:43 merged-archive-20140213.084228.0 > -rw-r--r-- 1 pcp pcp 53K Feb 13 19:43 merged-archive-20140213.084228.index > -rw-r--r-- 1 pcp pcp 120K Feb 13 19:43 merged-archive-20140213.084228.meta > [iow, this is a small host configuration - yet those logs seem big?] I don't know. pmmgr does not create archives: it's pmlogger and pmlogextract, with the documented/saved configurations. For comparison, tofan.yyz's two-week merged logs are about that size, storing right about 40 MB/day of pmlogger traffic, whereas on a smaller workstation at home it's about a third of that. (It used to be way more, back before my first pmlogger optimization; I didn't study the aftereffects of yours.) > nathans@verge:/source/git/nathans-pcp$ ps -ef | grep pmmgr > pcp 8022 1 0 Feb10 ? 00:00:01 /usr/bin/pmie [...] > pcp 10670 1 0 Feb11 ? 00:00:01 /usr/bin/pmie [...] > pcp 19218 19214 0 19:42 pts/0 00:00:00 /usr/bin/pmie [...] > pcp 20518 1 0 Feb12 ? 00:00:00 /usr/bin/pmie [...] (Those pmie processes must have been left from older runs; I believe I fixed their killing.) > nathans@verge:/source/git/nathans-pcp$ cat /var/log/pcp/pmmgr/pmmgr.log > [Thu Feb 13 19:42:18] pmmgr(19195/19195): Log started > [Thu Feb 13 19:42:18] pmmgr(19195/19195): /etc/pcp/pmmgr: new hostid verge at local: > nathans@verge:/source/git/nathans-pcp$ > nathans@verge:/source/git/nathans-pcp$ cat /var/log/pcp/pmmgr/pmmgr.log.prev > [Wed Feb 12 14:29:39] pmmgr(20467/20467): Log started > [Wed Feb 12 14:29:39] pmmgr(20467/20467): /etc/pcp/pmmgr: new hostid verge at local: > [Thu Feb 13 19:41:08] pmmgr(20467/20467): /etc/pcp/pmmgr: dead hostid verge > [Thu Feb 13 19:41:27] pmmgr(20467/20467): Log finished ... so your pmcd went down twice in 80 seconds, which pmmgr detected and responded to as designed. > Typical daily log size from pmlogger_daily here is ~6MB... > -rw-r--r-- 1 pcp pcp 6469616 Feb 13 00:10 20140212.0 > -rw-r--r-- 1 pcp pcp 1512 Feb 13 00:10 20140212.index > -rw-r--r-- 1 pcp pcp 12982 Feb 13 00:10 20140212.meta That must be from a different pmlogger configuration (diff the /etc and /var/log/pcp/pmmgr/$host configurations), or else there must be a serious bug in pmlogextract or somesuch. I don't see how pmmgr per se could be responsible for such an order-of-magnitude difference. > nathans@verge:/source/git/nathans-pcp$ ls -l /var/log/pcp/pmmgr/verge/ > total 559904 > -rw-r--r-- 1 pcp pcp 571969000 Feb 13 19:44 merged-archive-20140213.084228.0 > -rw-r--r-- 1 pcp pcp 86872 Feb 13 19:44 merged-archive-20140213.084228.index > -rw-r--r-- 1 pcp pcp 155489 Feb 13 19:44 merged-archive-20140213.084228.meta > [...] > All looks fine, hmmm. Nothing untoward in the pmlogger config AFAICS. > I'll dig some more tomorrow - can put the archive someplace if you want > to take a peek too? Sure: both the /etc/pcp primary-pmlogger data and the /usr/log/pcp/pmmgr/$host ones. - FChE From kenj@internode.on.net Thu Feb 13 15:15:03 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 69C9B7F55 for ; Thu, 13 Feb 2014 15:15:03 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 04E8FAC00B for ; Thu, 13 Feb 2014 13:14:58 -0800 (PST) X-ASG-Debug-ID: 1392326092-04bdf0121f38ffc0001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id I2qAA3GYvSRqsTWC for ; Thu, 13 Feb 2014 13:14:53 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuseALg0/VJ20YajPGdsb2JhbAANTIM+iBG5RAMBAQEBOINZMA0WGAMCAQIBMScGAgEBrSCjDxePFoQiBK4Q Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail06.adl6.internode.on.net with ESMTP; 14 Feb 2014 07:38:45 +1030 Message-ID: <52FD346F.8050603@internode.on.net> Date: Fri, 14 Feb 2014 08:09:03 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pcp updates - pmlogextract and pmdumplog (both minor) Content-Type: text/plain; charset=ISO-8859-1 X-ASG-Orig-Subj: pcp updates - pmlogextract and pmdumplog (both minor) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1392326093 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145088 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Changes committed to git://oss.sgi.com/kenj/pcp.git dev man/man1/pmdumplog.1 | 7 qa/962 | 30 qa/962.out | 2837 ++++++++++++++++++++++++++++++++++++++++ qa/group | 1 qa/src/GNUlocaldefs | 2 qa/src/count-mark.0 |binary qa/src/count-mark.index |binary qa/src/count-mark.meta |binary src/pmdumplog/pmdumplog.c | 23 src/pmlogextract/pmlogextract.c | 7 10 files changed, 2902 insertions(+), 5 deletions(-) commit 65f958cfa26239e65829100dab7c0c21efc5d127 Author: Ken McDonell Date: Fri Feb 14 08:06:51 2014 +1100 qa/962 [new] - further checking of interp mode with records commit 5dedc0ca3ba52add72cab7ebb3c4174839ecbb11 Author: Ken McDonell Date: Wed Feb 12 09:10:57 2014 +1100 pmlogextract - record handling fix Previously, if pmlogextract was selecting a subset of the metrics from the input archive, then records from the input archive were not copied to the output archive. This could have lead to incorrect value interpolation in the temporal region where the record should have been. Most uses of pmlogextract do _not_ use metric selection, so this bug is not as serious as it may seem at first ... debugging interp.c and QA are the two places where we were exposed! commit 32b65a4cfedfd618b468bc2b15147c08dde8388c Author: Ken McDonell Date: Wed Jan 29 09:27:54 2014 +1100 pmdumplog - add -x option -x for extended timestamp reporting, e.g Thu May 7 10:42:23.933 1998 instead of 10:42:23.933 From kenj@internode.on.net Thu Feb 13 15:27:21 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 4BD417F55 for ; Thu, 13 Feb 2014 15:27:21 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id C8F80AC00C for ; Thu, 13 Feb 2014 13:27:20 -0800 (PST) X-ASG-Debug-ID: 1392326838-04bdf0734c1dcd70001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id gcq8Pk9T40FHStRN for ; Thu, 13 Feb 2014 13:27:19 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvUeAFw4/VJ20YajPGdsb2JhbAANTItPtQ6DBoEwAwEBAQE4gloBAQEEOEARCxgJFg8JAwIBAgExFBMIAQGtK6MPF44XEQFXFoQiAQOuEIFd Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail06.adl6.internode.on.net with ESMTP; 14 Feb 2014 07:57:18 +1030 Message-ID: <52FD38C9.3050601@internode.on.net> Date: Fri, 14 Feb 2014 08:27:37 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Re: [pcp] Possible pmmgr issue? References: <1952377955.6159460.1392281163287.JavaMail.zimbra@redhat.com> <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> <20140213125811.GG11820@redhat.com> X-ASG-Orig-Subj: Re: [pcp] Possible pmmgr issue? In-Reply-To: <20140213125811.GG11820@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1392326838 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145088 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- I don't seem to have a copy of the original email, so I'm only guessing at the context ... On 13/02/14 23:58, Frank Ch. Eigler wrote: > Hi - > > >> [...] >> Note the size of the 2 merge archives. I need to clean this up, >> as my rootfs is out of space once more. Any suggestions on what >> to look for before I do that? Thanks. > > From what I see, it looks like you just happened to catch the machine > mid-merge, just after the pmcd was lost & restarted, so pmmgr stopped > & restarted the pmlogger. > > >> -rw-r--r-- 1 pcp pcp 546M Feb 13 14:34 merged-archive-20140213.033222.0 >> -rw-r--r-- 1 pcp pcp 85K Feb 13 14:34 merged-archive-20140213.033222.index >> -rw-r--r-- 1 pcp pcp 144K Feb 13 14:34 merged-archive-20140213.033222.meta >> -rw-r--r-- 1 pcp pcp 335M Feb 13 19:43 merged-archive-20140213.084228.0 >> -rw-r--r-- 1 pcp pcp 53K Feb 13 19:43 merged-archive-20140213.084228.index >> -rw-r--r-- 1 pcp pcp 120K Feb 13 19:43 merged-archive-20140213.084228.meta > >> [iow, this is a small host configuration - yet those logs seem big?] > > I don't know. pmmgr does not create archives: it's pmlogger and > pmlogextract, with the documented/saved configurations. Assuming the pmlogger control file matches the current shipping version, then pmlogger is launched with -r which means the expected size for each logged metric over the course of 24hrs of logging is reported in pmlogger.log (check below /var/log/pcp/pmlogger/) ... pmlogextract cannot make up logger records, so the size of the output archive will always be no larger the sum of the input archives. From kenj@internode.on.net Thu Feb 13 15:29:23 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id A481F7F55 for ; Thu, 13 Feb 2014 15:29:23 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 87B45304048 for ; Thu, 13 Feb 2014 13:29:20 -0800 (PST) X-ASG-Debug-ID: 1392326958-04cbb00c2b36ea60001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id W0UUK8dVG9wjAJDW for ; Thu, 13 Feb 2014 13:29:18 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvceAFw4/VJ20YajPGdsb2JhbAANTItPtQ6DBoEwAwEBAQE4gloBAQEEODAQDQQLGAkWDwkDAgECATEUEwgBAa0row8XjhcRAVcWhCIBA64QgV0 Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail06.adl6.internode.on.net with ESMTP; 14 Feb 2014 07:59:17 +1030 Message-ID: <52FD3940.5010304@internode.on.net> Date: Fri, 14 Feb 2014 08:29:36 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Re: [pcp] pmmgr pmlogger default behaviour References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1583484726.15908616.1391037005341.JavaMail.root@redhat.com> <20140130181134.GA7584@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> <20140206133220.GC5017@redhat.com> <633105491.21839148.1391757935531.JavaMail.root@redhat.com> <1095368295.6085212.1392272562364.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pmmgr pmlogger default behaviour In-Reply-To: <1095368295.6085212.1392272562364.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1392326958 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145088 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 13/02/14 17:22, Nathan Scott wrote: > Hi Frank, > > ----- Original Message ----- >>> ... >> I'll stew on this over the weekend, and attempt to come up with some >> possible directions forward for us here, seeking compromise. It feels >> a bit like we're going in circles by email here now, and we need a new >> tack as we're stale-mated on each others needs/concerns. Is this the trigger for a PCP developer's conference call/meeting? We haven't had one in quite a while. From kenj@internode.on.net Thu Feb 13 15:53:16 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 748E67F55 for ; Thu, 13 Feb 2014 15:53:16 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 254BF8F8039 for ; Thu, 13 Feb 2014 13:53:16 -0800 (PST) X-ASG-Debug-ID: 1392328393-04bdf0734c1debb0001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id VDGr6M8U8NhUTJrl for ; Thu, 13 Feb 2014 13:53:14 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYeABo+/VJ20YajPGdsb2JhbAANTItPuUQDAQEBATiDWT0WGAMCAQIBMQ4MDQgBAa03ow0XkzgElEQFmUc Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail06.adl6.internode.on.net with ESMTP; 14 Feb 2014 08:23:13 +1030 Message-ID: <52FD3EDB.5030503@internode.on.net> Date: Fri, 14 Feb 2014 08:53:31 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: PCP Mailing List Subject: debian package installation failure Content-Type: text/plain; charset=ISO-8859-1 X-ASG-Orig-Subj: debian package installation failure Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1392328393 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145090 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- After the latest packaging changes ... This used to work just fine: kenj@bozo:~/src/pcp$ sudo dpkg -i build/deb/*.deb But now ... [ok stuff deleted] Unpacking replacement pcp ... dpkg: warning: unable to delete old directory '/etc/pcp/pmwebd': Directory not empty dpkg: warning: unable to delete old directory '/var/log/pcp/pmwebd': Directory not empty Which is not good. For reference: kenj@bozo:~/src/pcp$ ls -l /etc/pcp/pmwebd total 8 -rw-r--r-- 1 root root 865 Nov 14 08:00 pmwebd.options -rw-r--r-- 1 root root 865 Feb 14 08:14 pmwebd.options.dpkg-new kenj@bozo:~/src/pcp$ ls -l /var/log/pcp/pmwebd total 8 -rw-r--r-- 1 root root 325 Feb 14 08:23 pmwebd.log -rw-r--r-- 1 root root 325 Feb 7 13:39 pmwebd.log.prev [continuing on with dpkg output ... more OK stuff deleted] Setting up pcp (3.9.0) ... Installing new version of config file /etc/init.d/pmproxy ... Installing new version of config file /etc/init.d/pmie ... update-rc.d: /etc/init.d/pmmgr: file does not exist dpkg: error processing pcp (--install): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of pcp-manager: pcp-manager depends on pcp (= 3.9.0); however: Package pcp is not configured yet. And then I get a whole slew of what look like consequential errors because pcp 3.9.0 did not get configured ... dpkg: error processing pcp-manager (--install): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of pcp-testsuite: pcp-testsuite depends on pcp (= 3.9.0); however: Package pcp is not configured yet. dpkg: error processing pcp-testsuite (--install): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of pcp-webapi: pcp-webapi depends on pcp (= 3.9.0); however: Package pcp is not configured yet. dpkg: error processing pcp-webapi (--install): dependency problems - leaving unconfigured dpkg: dependency problems prevent configuration of libpcp-logsummary-perl: libpcp-logsummary-perl depends on pcp (= 3.9.0); however: Package pcp is not configured yet. dpkg: error processing libpcp-logsummary-perl (--install): dependency problems - leaving unconfigured Processing triggers for man-db ... Processing triggers for ureadahead ... Processing triggers for libc-bin ... Errors were encountered while processing: pcp pcp-manager pcp-testsuite pcp-webapi libpcp-logsummary-perl From nscott@redhat.com Thu Feb 13 16:04:32 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id B5D837F55 for ; Thu, 13 Feb 2014 16:04:32 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 53199AC00B for ; Thu, 13 Feb 2014 14:04:29 -0800 (PST) X-ASG-Debug-ID: 1392329063-04cb6c6de03716a0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id I0cjbZi91wnQdrW3 for ; Thu, 13 Feb 2014 14:04:24 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1DM4K2F028635; Thu, 13 Feb 2014 17:04:20 -0500 Date: Thu, 13 Feb 2014 17:04:20 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: pcp@oss.sgi.com Message-ID: <697698977.6789455.1392329060808.JavaMail.zimbra@redhat.com> In-Reply-To: <52FD3940.5010304@internode.on.net> References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> <20140206133220.GC5017@redhat.com> <633105491.21839148.1391757935531.JavaMail.root@redhat.com> <1095368295.6085212.1392272562364.JavaMail.zimbra@redhat.com> <52FD3940.5010304@internode.on.net> Subject: Re: [pcp] pmmgr pmlogger default behaviour MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmmgr pmlogger default behaviour Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmmgr pmlogger default behaviour Thread-Index: J48kPAKJ5LsjKnQAzRuAqTXI7Mognw== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392329064 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145090 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > On 13/02/14 17:22, Nathan Scott wrote: > > Hi Frank, > > > > ----- Original Message ----- > >>> ... > >> I'll stew on this over the weekend, and attempt to come up with some > >> possible directions forward for us here, seeking compromise. It feels > >> a bit like we're going in circles by email here now, and we need a new > >> tack as we're stale-mated on each others needs/concerns. > > Is this the trigger for a PCP developer's conference call/meeting? We > haven't had one in quite a while. Yeah, well overdue - I was hoping Mark would be back on deck before teeing up the next one, as he had a keen interest in unifying contexts also. But we may have to go ahead without him for now, and I'll fill him in later. If everyone interested can send preferred days of the week, it'll be early morning in .au EST +11, mid-arvo Toronto time and pot luck everywhere else based on past experiences of what works best. cheers. -- Nathan From nscott@redhat.com Thu Feb 13 16:16:54 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 63BBA7F55 for ; Thu, 13 Feb 2014 16:16:54 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 3E06B304043 for ; Thu, 13 Feb 2014 14:16:53 -0800 (PST) X-ASG-Debug-ID: 1392329812-04cb6c06cf5d5e0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id c3kBS6Rbe1ghbeMC for ; Thu, 13 Feb 2014 14:16:52 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1DMGoX5031563; Thu, 13 Feb 2014 17:16:50 -0500 Date: Thu, 13 Feb 2014 17:16:50 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: PCP Mailing List Message-ID: <996386881.6793329.1392329810221.JavaMail.zimbra@redhat.com> In-Reply-To: <52FD3EDB.5030503@internode.on.net> References: <52FD3EDB.5030503@internode.on.net> Subject: Re: [pcp] debian package installation failure MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] debian package installation failure Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: debian package installation failure Thread-Index: v0E0CED51SS1NhmlwqDEMQ2hJcsu/Q== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392329812 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145090 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > After the latest packaging changes ... > > This used to work just fine: > > kenj@bozo:~/src/pcp$ sudo dpkg -i build/deb/*.deb > > But now ... > [ok stuff deleted] > Unpacking replacement pcp ... > dpkg: warning: unable to delete old directory '/etc/pcp/pmwebd': Directory > not empty > dpkg: warning: unable to delete old directory '/var/log/pcp/pmwebd': > Directory not empty > > Which is not good. Its the best that can be done AFAICT, no configs or logs are lost & the new package then assumes responsibility for these paths, as it should. > Setting up pcp (3.9.0) ... > Installing new version of config file /etc/init.d/pmproxy ... > Installing new version of config file /etc/init.d/pmie ... > update-rc.d: /etc/init.d/pmmgr: file does not exist This is the root cause. Its a leftover reference in the pcp postinst script, and its exit code causes abortion of the entire install. Just a bit odd that this didn't fail for me - anyway, its fixed in git now. > And then I get a whole slew of what look like consequential errors because > pcp 3.9.0 did not get configured ... Yep, everything else flows from that. For me it installs cleanly - it may be I'm upgrading from 3.9.0 -> 3.9.0 though, and so missed this in the process of rearranging the furniture. cheers. -- Nathan From nscott@redhat.com Thu Feb 13 17:21:39 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 1F1477F5D for ; Thu, 13 Feb 2014 17:21:39 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id E9335304039 for ; Thu, 13 Feb 2014 15:21:35 -0800 (PST) X-ASG-Debug-ID: 1392333690-04cbb00c28376900001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id JRRGwAA6dB8NSoum for ; Thu, 13 Feb 2014 15:21:31 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1DNLQpl023786; Thu, 13 Feb 2014 18:21:26 -0500 Date: Thu, 13 Feb 2014 18:21:26 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" , Ken McDonell Cc: pcp developers Message-ID: <1040057732.6827059.1392333686610.JavaMail.zimbra@redhat.com> In-Reply-To: <20140213125811.GG11820@redhat.com> References: <1952377955.6159460.1392281163287.JavaMail.zimbra@redhat.com> <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> <20140213125811.GG11820@redhat.com> Subject: Re: Possible pmmgr issue? MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Possible pmmgr issue? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Possible pmmgr issue? Thread-Index: HOpbPc/o4bhv/5nU+trHjJVGBcwing== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392333690 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145091 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > > [...] > > Note the size of the 2 merge archives. I need to clean this up, > > as my rootfs is out of space once more. Any suggestions on what > > to look for before I do that? Thanks. > > From what I see, it looks like you just happened to catch the machine > mid-merge, just after the pmcd was lost & restarted, so pmmgr stopped > & restarted the pmlogger. This would've been right after a package upgrade - so the stop/start there was from the packaging scripts. Which is another interesting observation in itself (uber-log merging happens not just once a day, but also on this sort of event? that doesn't seem ideal on the face of it, is it necessary or can that be delayed till the wee hours?) > > -rw-r--r-- 1 pcp pcp 546M Feb 13 14:34 merged-archive-20140213.033222.0 > > -rw-r--r-- 1 pcp pcp 85K Feb 13 14:34 merged-archive-20140213.033222.index > > -rw-r--r-- 1 pcp pcp 144K Feb 13 14:34 merged-archive-20140213.033222.meta > > -rw-r--r-- 1 pcp pcp 335M Feb 13 19:43 merged-archive-20140213.084228.0 > > -rw-r--r-- 1 pcp pcp 53K Feb 13 19:43 merged-archive-20140213.084228.index > > -rw-r--r-- 1 pcp pcp 120K Feb 13 19:43 merged-archive-20140213.084228.meta > > > [iow, this is a small host configuration - yet those logs seem big?] > > I don't know. pmmgr does not create archives: it's pmlogger and > pmlogextract, with the documented/saved configurations. I wonder if we're somehow doing multiple merges of the same data, somehow? (not sure how, but can't explain it any other way). Does pmlogextract do exact duplicate result elimination Ken? I'd imagine it does not (would be quite difficult & expensive to detect). > For comparison, tofan.yyz's two-week merged logs are about that size, > storing right about 40 MB/day of pmlogger traffic, whereas on a > smaller workstation at home it's about a third of that. (It used to > be way more, back before my first pmlogger optimization; I didn't > study the aftereffects of yours.) (should be very similar - those later changes were more about pmFetch optimisation, which would have a less profound effect than the earlier metric de-dup work done -- except for some corner cases like metrics with instances specified, but that wont be the case here I imagine). > > > nathans@verge:/source/git/nathans-pcp$ ps -ef | grep pmmgr > > pcp 8022 1 0 Feb10 ? 00:00:01 /usr/bin/pmie [...] > > pcp 10670 1 0 Feb11 ? 00:00:01 /usr/bin/pmie [...] > > pcp 19218 19214 0 19:42 pts/0 00:00:00 /usr/bin/pmie [...] > > pcp 20518 1 0 Feb12 ? 00:00:00 /usr/bin/pmie [...] > > (Those pmie processes must have been left from older runs; I believe I > fixed their killing.) Oh, I overlooked those entirely - thanks. > > > Typical daily log size from pmlogger_daily here is ~6MB... > > -rw-r--r-- 1 pcp pcp 6469616 Feb 13 00:10 20140212.0 > > -rw-r--r-- 1 pcp pcp 1512 Feb 13 00:10 20140212.index > > -rw-r--r-- 1 pcp pcp 12982 Feb 13 00:10 20140212.meta > > That must be from a different pmlogger configuration (diff the /etc > and /var/log/pcp/pmmgr/$host configurations), or else there must be a > serious bug in pmlogextract or somesuch. I don't see how pmmgr per se > could be responsible for such an order-of-magnitude difference. Only way I can imagine we'd reach these dizzying sizes is somehow the same data is being merged multiple times. No idea how that could be, it seems a far-fetched theory but its the best I've got so far. > > Sure: both the /etc/pcp primary-pmlogger data and the > /usr/log/pcp/pmmgr/$host ones. > I'm uploading all the logs and configuration to somewhere public on oss.sgi.com where everyone can grab it. I'll send a followup note once its finished - ETA another 20mins. Thanks for the help guys! Ken, I'd be interested in your thoughts on a few observations from the pmlogger_daily scripts on this host (all defaults are in place, for everything - both pmlogger_daily & pmmgr): - there seems to be some older data that is not being culled? - there's a couple of logs that haven't merged, possibly cos one has a zero sized file or two? - from inspection of the pmlogger_daily script, we appear to always do a logmerge, even if there is only one log - could this not simply be handled via a mv(1) of the files? (avoiding the read/write I/O there entirely, for the simple case of one archive for the previous day - i.e. no pmcd/pmlogger restarts). cheers. -- Nathan From nscott@redhat.com Thu Feb 13 17:43:17 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 445487F5D for ; Thu, 13 Feb 2014 17:43:17 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id A47EBAC005 for ; Thu, 13 Feb 2014 15:43:16 -0800 (PST) X-ASG-Debug-ID: 1392334994-04cb6c6de23786e0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id 7uMKfyo16MfIyl1M for ; Thu, 13 Feb 2014 15:43:14 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1DNh8RO013206; Thu, 13 Feb 2014 18:43:08 -0500 Date: Thu, 13 Feb 2014 18:43:08 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" , Ken McDonell Cc: pcp developers Message-ID: <2147120813.6837227.1392334988862.JavaMail.zimbra@redhat.com> In-Reply-To: <1040057732.6827059.1392333686610.JavaMail.zimbra@redhat.com> References: <1952377955.6159460.1392281163287.JavaMail.zimbra@redhat.com> <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> <20140213125811.GG11820@redhat.com> <1040057732.6827059.1392333686610.JavaMail.zimbra@redhat.com> Subject: Re: Possible pmmgr issue? MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Possible pmmgr issue? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Possible pmmgr issue? Thread-Index: HOpbPc/o4bhv/5nU+trHjJVGBcwinvsaYR8H X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392334994 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145091 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > ... > I'm uploading all the logs and configuration to somewhere public on > oss.sgi.com where everyone can grab it. I'll send a followup note > once its finished - ETA another 20mins. Thanks for the help guys! ftp://oss.sgi.com/projects/pcp/download/dumps/ File:etc-pcp-pmlogger.tgz 8 KB File:etc-pcp-pmmgr.tgz 1 KB File:var-log-pcp-pmlogger.tgz 7501 KB File:var-log-pcp-pmmgr.tgz 115240 KB cheers. -- Nathan From nscott@redhat.com Thu Feb 13 18:22:09 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 25EBB7F62 for ; Thu, 13 Feb 2014 18:22:09 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 10F37304048 for ; Thu, 13 Feb 2014 16:22:08 -0800 (PST) X-ASG-Debug-ID: 1392337323-04cb6c6de037af50001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id wH3xpwg1CWKCrXw4 for ; Thu, 13 Feb 2014 16:22:04 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1E0Lv2P019489; Thu, 13 Feb 2014 19:21:57 -0500 Date: Thu, 13 Feb 2014 19:21:57 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: pcp developers Message-ID: <1006725141.6846584.1392337317261.JavaMail.zimbra@redhat.com> In-Reply-To: <1603650868.6845934.1392337086261.JavaMail.zimbra@redhat.com> Subject: pmdasample source vs binary & QA testing MIME-Version: 1.0 X-ASG-Orig-Subj: pmdasample source vs binary & QA testing Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmdasample source vs binary & QA testing Thread-Index: D/OjS7PfACixp+fMyCubVh2VDkzNfA== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392337324 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145092 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Ken, Just FYI - if doing any testing atm, as a result of the RPM "multilib" changes, we no longer ship a pre-built version of pmdasample. We ship source & makefile, like the other demo PMDAs now, which helps make the development packages architecture neutral of course. So may need an ./Install in pmdas/sample (that automatically does the build) before you next run QA. cheers. -- Nathan From fche@redhat.com Thu Feb 13 18:27:49 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 284C27F6F for ; Thu, 13 Feb 2014 18:27:49 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 13013304043 for ; Thu, 13 Feb 2014 16:27:48 -0800 (PST) X-ASG-Debug-ID: 1392337668-04cb6c6de137b4e0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id PBCTIh8RQngZC8iH for ; Thu, 13 Feb 2014 16:27:48 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1E0Rj2K015235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Feb 2014 19:27:45 -0500 Received: from fche.csb (vpn-235-28.phx2.redhat.com [10.3.235.28]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1E0Rifq017571; Thu, 13 Feb 2014 19:27:45 -0500 Received: by fche.csb (Postfix, from userid 2569) id 3F1765811C; Thu, 13 Feb 2014 19:27:44 -0500 (EST) Date: Thu, 13 Feb 2014 19:27:44 -0500 From: "Frank Ch. Eigler" To: Nathan Scott Cc: Ken McDonell , pcp developers Subject: Re: Possible pmmgr issue? Message-ID: <20140214002744.GI11820@redhat.com> X-ASG-Orig-Subj: Re: Possible pmmgr issue? References: <1952377955.6159460.1392281163287.JavaMail.zimbra@redhat.com> <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> <20140213125811.GG11820@redhat.com> <1040057732.6827059.1392333686610.JavaMail.zimbra@redhat.com> <2147120813.6837227.1392334988862.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2147120813.6837227.1392334988862.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392337668 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - > File:etc-pcp-pmlogger.tgz 8 KB > File:etc-pcp-pmmgr.tgz 1 KB > File:var-log-pcp-pmlogger.tgz 7501 KB > File:var-log-pcp-pmmgr.tgz 115240 KB The two pmlogger.log files identify the apples & oranges directly. pmmgr's pmlogconf: "Auto-generated by pmlogconf on: Friday 14 February 09:11:41 EST 2014" "254 metrics ... logged every 60 sec: 44340 bytes or 60.89 Mbytes/day" other pmlogconf: "Auto-generated by pmlogconf on: Mon Jul 22 12:48:51 EST 2013" "100 metrics ... logged every 60 sec: 4496 bytes or 6.17 Mbytes/day" - FChE From nscott@redhat.com Thu Feb 13 19:29:36 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E9AED7F6A for ; Thu, 13 Feb 2014 19:29:35 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 679B5AC005 for ; Thu, 13 Feb 2014 17:29:32 -0800 (PST) X-ASG-Debug-ID: 1392341369-04cb6c6de237ede0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 6H67VNjuZu6Q1A9u for ; Thu, 13 Feb 2014 17:29:30 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1E1TQan010902; Thu, 13 Feb 2014 20:29:26 -0500 Date: Thu, 13 Feb 2014 20:29:26 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" , Ken McDonell Cc: pcp developers Message-ID: <409921650.6871228.1392341366097.JavaMail.zimbra@redhat.com> In-Reply-To: <20140214002744.GI11820@redhat.com> References: <1952377955.6159460.1392281163287.JavaMail.zimbra@redhat.com> <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> <20140213125811.GG11820@redhat.com> <1040057732.6827059.1392333686610.JavaMail.zimbra@redhat.com> <2147120813.6837227.1392334988862.JavaMail.zimbra@redhat.com> <20140214002744.GI11820@redhat.com> Subject: Re: Possible pmmgr issue? MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Possible pmmgr issue? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Possible pmmgr issue? Thread-Index: XH9tRX8F2NWQYfXK4eQMMZiMHDh0zQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392341370 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145093 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > Hi - > > > File:etc-pcp-pmlogger.tgz 8 KB > > File:etc-pcp-pmmgr.tgz 1 KB > > File:var-log-pcp-pmlogger.tgz 7501 KB > > File:var-log-pcp-pmmgr.tgz 115240 KB > > The two pmlogger.log files identify the apples & oranges directly. > > pmmgr's pmlogconf: > "Auto-generated by pmlogconf on: Friday 14 February 09:11:41 EST 2014" > "254 metrics ... logged every 60 sec: 44340 bytes or 60.89 Mbytes/day" > > other pmlogconf: > "Auto-generated by pmlogconf on: Mon Jul 22 12:48:51 EST 2013" > "100 metrics ... logged every 60 sec: 4496 bytes or 6.17 Mbytes/day" > Yep very good point, interesting - those are not default log sizes I'd expected (for either!). Ohhh, its found and enabled postgres logging! And the other config is really out-dated. Re-creating the pmlogger log conf, and same config generated now. I should revisit the frequency with which pmlogger_daily auto-generates, not clear that's working as planned. OOC, any thoughts on the question of merging logs during the middle of the day? Restarting pmcd appears to be an expensive operation with a pmmgr in play without some strategy there? (I can restart pmcd/pmmgr a whole lot more quickly than those logs can be merged) And, yeah, wow - hmm, thats alot of logged data now, I wonder if we're going overboard with some of the logging configs. :| Yet another issue - the daily logs should be compressed after a few days. It seems the daily script has stopped some of its functions? Rotation is happening but cull &| compress appears to not be anymore. Oh here we go... running daily script by hand, verbose mode reveals: pmlogger_merge: Warning: archive "20140123.09.55" is empty and will be skipped Input archives to be merged: 20140123.00.10 20140123.16.25 pmlogextract: Error: __pmLogRead[log 20140123.00.10]: Corrupted record in a PCP archive log pmlogextract: Error occurred at byte offset 2690960 into a file of 2691072 bytes. The last record, and the remainder of this file will not be extracted. Archive "20140123" not created. pmlogger_merge: Directory: /var/log/pcp/pmlogger/verge pmlogger_merge: Failed: pmlogextract 20140123.00.10 20140123.16.25 20140123 pmlogger_merge: Trying to continue, although output archive may be corrupted. Output archive files: pmlogger_merge: Error: file "20140123.meta" not created pmlogger_merge: Error: file "20140123.index" not created pmlogger_merge: Error: file "20140123.0" not created Merged output archive 20140123 ... pmdumplog: Cannot open archive "20140123": No such file or directory Skip culling and compression ... Hmm, file corruption. Oh man, that never happens! ;) (/me ducks and runs). And an empty log file in the mix too. In terms of the cull/compress though, the last line is key ... it seems overly drastic - but appears to be working as planned, Ken? Self-correction would be good, once the problem archives have all scrolled past their use-by date? BTW, the option to compress is also missing in pmmgr, I realise now; another one for that list. Not easily implementable either, it would seem, with one merge log - probably need libpcp to be able to do this directly - bump log format, add code to do in-line compression...? Or "hack" it, and inflate/deflate around the merges...? That defeats the point of having the one continuous log handy though, I think, so it really would have to be in libpcp. (a good feature anyway, IMO) cheers. -- Nathan From fche@redhat.com Thu Feb 13 20:08:11 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id F16737F5D for ; Thu, 13 Feb 2014 20:08:10 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id DFE598F804B for ; Thu, 13 Feb 2014 18:08:07 -0800 (PST) X-ASG-Debug-ID: 1392343683-04cbb00c28380b50001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id wuomoHfVtlSvqXZL for ; Thu, 13 Feb 2014 18:08:04 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1E27xCC028890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Feb 2014 21:07:59 -0500 Received: from fche.csb (vpn-235-28.phx2.redhat.com [10.3.235.28]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1E27wI9009267; Thu, 13 Feb 2014 21:07:58 -0500 Received: by fche.csb (Postfix, from userid 2569) id 2B57A5811C; Thu, 13 Feb 2014 21:07:58 -0500 (EST) Date: Thu, 13 Feb 2014 21:07:58 -0500 From: "Frank Ch. Eigler" To: Nathan Scott Cc: Ken McDonell , pcp developers Subject: Re: Possible pmmgr issue? Message-ID: <20140214020758.GA18232@redhat.com> X-ASG-Orig-Subj: Re: Possible pmmgr issue? References: <1952377955.6159460.1392281163287.JavaMail.zimbra@redhat.com> <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> <20140213125811.GG11820@redhat.com> <1040057732.6827059.1392333686610.JavaMail.zimbra@redhat.com> <2147120813.6837227.1392334988862.JavaMail.zimbra@redhat.com> <20140214002744.GI11820@redhat.com> <409921650.6871228.1392341366097.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <409921650.6871228.1392341366097.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392343684 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - > [...] OOC, any thoughts on the question of merging logs during the > middle of the day? Restarting pmcd appears to be an expensive > operation with a pmmgr in play without some strategy there? [...] I'm working on some more control over the pmlogmerge inputs. While in the area, the code might be made willing to let some intra-interval (default: day) archives pile up unmerged, until the next interval. > [...] BTW, the option to compress is also missing in pmmgr, I > realise now; another one for that list. [...] It's already in the TODO. Another possibility would be translucent zlib support in libpcp and the archive generators. - FChE From nscott@redhat.com Thu Feb 13 21:20:47 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id DBC637F73 for ; Thu, 13 Feb 2014 21:20:47 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id BF6C38F8037 for ; Thu, 13 Feb 2014 19:20:47 -0800 (PST) X-ASG-Debug-ID: 1392348042-04cb6c6de1384f40001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id ofhoMGJPYWOKugvN for ; Thu, 13 Feb 2014 19:20:43 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1E3KdHw027455; Thu, 13 Feb 2014 22:20:39 -0500 Date: Thu, 13 Feb 2014 22:20:39 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: Ken McDonell , pcp developers Message-ID: <1710868449.6907004.1392348039147.JavaMail.zimbra@redhat.com> In-Reply-To: <20140214020758.GA18232@redhat.com> References: <1952377955.6159460.1392281163287.JavaMail.zimbra@redhat.com> <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> <20140213125811.GG11820@redhat.com> <1040057732.6827059.1392333686610.JavaMail.zimbra@redhat.com> <2147120813.6837227.1392334988862.JavaMail.zimbra@redhat.com> <20140214002744.GI11820@redhat.com> <409921650.6871228.1392341366097.JavaMail.zimbra@redhat.com> <20140214020758.GA18232@redhat.com> Subject: Re: Possible pmmgr issue? MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Possible pmmgr issue? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Possible pmmgr issue? Thread-Index: XqZQklW3tVALYh/pg7o0kQf06f5Ckw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392348043 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145095 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > Hi - > > > [...] OOC, any thoughts on the question of merging logs during the > > middle of the day? Restarting pmcd appears to be an expensive > > operation with a pmmgr in play without some strategy there? [...] > > I'm working on some more control over the pmlogmerge inputs. While in > the area, the code might be made willing to let some intra-interval > (default: day) archives pile up unmerged, until the next interval. > Good stuff. > > > [...] BTW, the option to compress is also missing in pmmgr, I > > realise now; another one for that list. [...] > > It's already in the TODO. Another possibility would be translucent > zlib support in libpcp and the archive generators. > +1 to the later (& enabled-by-default in pmmgr). cheers. -- Nathan From nscott@redhat.com Thu Feb 13 23:47:19 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C239B7F75 for ; Thu, 13 Feb 2014 23:47:19 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 96D528F8033 for ; Thu, 13 Feb 2014 21:47:16 -0800 (PST) X-ASG-Debug-ID: 1392356831-04bdf0516539cb0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id z7YPqEJOIXfzAj1g for ; Thu, 13 Feb 2014 21:47:11 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1E5lBqx015108 for ; Fri, 14 Feb 2014 00:47:11 -0500 Date: Fri, 14 Feb 2014 00:47:11 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp developers Message-ID: <630636087.6944753.1392356831108.JavaMail.zimbra@redhat.com> In-Reply-To: <624347800.6943406.1392356743720.JavaMail.zimbra@redhat.com> Subject: pcp updates: fche & kenj merges, deb tweaks MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: fche & kenj merges, deb tweaks Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: fche & kenj merges, deb tweaks Thread-Index: Ztntg4G/S8XscNtJatP1LAWgtXG0XQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392356831 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145097 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev debian/libpcp3-dev.install | 3 debian/pcp.postinst.tail | 1 man/man1/pmdumplog.1 | 7 man/man1/pmmgr.1 | 48 qa/962 | 30 qa/962.out | 2837 ++++++++++++++++++++++++++++++++++++++++ qa/group | 1 qa/src/GNUlocaldefs | 2 qa/src/count-mark.0 |binary qa/src/count-mark.index |binary qa/src/count-mark.meta |binary src/pmdumplog/pmdumplog.c | 25 src/pmlogextract/pmlogextract.c | 7 src/pmmgr/TODO | 4 src/pmmgr/config/GNUmakefile | 4 src/pmmgr/pmmgr.cxx | 40 16 files changed, 2985 insertions(+), 24 deletions(-) commit 562892df88ab47463e675e23489855fd3cf663a2 Author: Frank Ch. Eigler Date: Tue Feb 11 14:54:46 2014 -0500 pmmgr: pmlogrewrite support This is via a new optional config/pmlogmerge-rewrite control file. commit 9a1f4bd8bf17db20654dc5a5ca92ed125e4b2558 Author: Frank Ch. Eigler Date: Tue Feb 11 14:25:40 2014 -0500 pmmgr: add latency-based tie-break for multiple-url target pmcds commit 401a24b3eb89901d594309fbb22f9d5e6a53141f Author: Frank Ch. Eigler Date: Tue Feb 11 13:23:47 2014 -0500 pmmgr.1 man page: outline tradeoffs with log archive management options commit 2587a6801ab2e9055ab4a042eabb58c4bf5cf048 Author: Frank Ch. Eigler Date: Tue Feb 11 11:26:18 2014 -0500 pmmgr TODO +1 commit 46813e49455c76a50d72d56c8f68fb98c7174db0 Author: Nathan Scott Date: Fri Feb 14 10:30:05 2014 +1100 Fix a typo in recent pmdumplog usage message addition commit 9325feca6223098470b010dbe6400fbc272cbc9f Merge: 3b595d7 0649c82 Author: Nathan Scott Date: Fri Feb 14 10:27:10 2014 +1100 Merge branch 'dev' of git://oss.sgi.com/kenj/pcp into dev commit 3b595d7a465f1df6a49fba65080dc5a09f1acf52 Author: Nathan Scott Date: Fri Feb 14 08:57:01 2014 +1100 Remove leftover reference to pmmgr from Debian pcp package postinst commit 0649c82253a5515b4ddf65bf9d20f0f1505bc5ac Merge: 65f958c dd402ad Author: Ken McDonell Date: Fri Feb 14 08:09:46 2014 +1100 Merge branch 'dev' of git://oss.sgi.com/pcp/pcp into dev commit 65f958cfa26239e65829100dab7c0c21efc5d127 Author: Ken McDonell Date: Fri Feb 14 08:06:51 2014 +1100 qa/962 [new] - further checking of interp mode with records commit dd402adfb67ca26dfc9bbbe27d786f5f6ac88ecb Author: Nathan Scott Date: Thu Feb 13 19:37:45 2014 +1100 Fix debian builds, fallout from the earlier RPM multilib changes commit 5dedc0ca3ba52add72cab7ebb3c4174839ecbb11 Author: Ken McDonell Date: Wed Feb 12 09:10:57 2014 +1100 pmlogextract - record handling fix Previously, if pmlogextract was selecting a subset of the metrics from the input archive, then records from the input archive were not copied to the output archive. This could have lead to incorrect value interpolation in the temporal region where the record should have been. Most uses of pmlogextract do _not_ use metric selection, so this bug is not as serious as it may seem at first ... debugging interp.c and QA are the two places where we were exposed! commit 32b65a4cfedfd618b468bc2b15147c08dde8388c Author: Ken McDonell Date: Wed Jan 29 09:27:54 2014 +1100 pmdumplog - add -x option -x for extended timestamp reporting, e.g Thu May 7 10:42:23.933 1998 instead of 10:42:23.933 From nscott@redhat.com Thu Feb 13 23:48:59 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 606107F77 for ; Thu, 13 Feb 2014 23:48:59 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 4433B304043 for ; Thu, 13 Feb 2014 21:48:59 -0800 (PST) X-ASG-Debug-ID: 1392356934-04cb6c6de138c6f0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id Kd6uPAMa7JVWhT7y for ; Thu, 13 Feb 2014 21:48:55 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1E5msRc001313 for ; Fri, 14 Feb 2014 00:48:54 -0500 Date: Fri, 14 Feb 2014 00:48:54 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp developers Message-ID: <667250473.6946179.1392356934590.JavaMail.zimbra@redhat.com> In-Reply-To: <1422358137.6945660.1392356903354.JavaMail.zimbra@redhat.com> Subject: pcp-doc updates: scox merge MIME-Version: 1.0 X-ASG-Orig-Subj: pcp-doc updates: scox merge Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp-doc updates: scox merge Thread-Index: EFxagT809ALB9yavUacoKxV4ExBWeA== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392356934 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145098 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp-gui.git dev books/PCP_PG/pcp-programmers-guide.pdf |binary books/PCP_PG/pcp-programmers-guide.xml | 552 ++++++++++++++++++++++++++------- 2 files changed, 442 insertions(+), 110 deletions(-) commit dd78451d0c521c9f8a0c9696378bf51ecdb4d16d Author: Stan Cox Date: Fri Feb 14 16:43:20 2014 +1100 Updates to the Programmers Guide to cover the Python modules In addition to augmenting the C API discussion with a number of aspects of the Python interfaces, some higher level text about modules, exceptions and so on is added. Further, the C pmclient example is used more thoroughly and complementary python examples are added alongside the C code. From kenj@internode.on.net Thu Feb 13 23:59:18 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A6C827F57 for ; Thu, 13 Feb 2014 23:59:18 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 21DDBAC00C for ; Thu, 13 Feb 2014 21:59:17 -0800 (PST) X-ASG-Debug-ID: 1392357555-04cb6c06cf780a0001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id PyPwJnCUWERUZbLh for ; Thu, 13 Feb 2014 21:59:16 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgGAD2w/VJ5LEjd/2dsb2JhbABZgwaEEahIlBCBFBd0giUBAQUIAhkFLiMMAQMCBgMRAQMBAQMCIwMCAhkgDQMGCAIEEwsFh3SnDKF2F4EpjVAHBoJpgUkEjymbJoNBKA Received: from ppp121-44-72-221.lns20.syd6.internode.on.net (HELO bozohorize) ([121.44.72.221]) by ipmail06.adl6.internode.on.net with ESMTP; 14 Feb 2014 16:28:48 +1030 From: "Ken McDonell" To: "'Nathan Scott'" Cc: "'pcp developers'" References: <1603650868.6845934.1392337086261.JavaMail.zimbra@redhat.com> <1006725141.6846584.1392337317261.JavaMail.zimbra@redhat.com> In-Reply-To: <1006725141.6846584.1392337317261.JavaMail.zimbra@redhat.com> Subject: RE: pmdasample source vs binary & QA testing Date: Fri, 14 Feb 2014 16:58:37 +1100 X-ASG-Orig-Subj: RE: pmdasample source vs binary & QA testing Message-ID: <00a801cf2949$d30a9030$791fb090$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQLFeMao2uqzwL862E/DIAPk6zI7LpjHoJDw Content-Language: en-au X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1392357555 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145098 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Thanks for the heads up Nathan. We're already ahead of the game ... for about a decade the qa check = script requires the sample and sampledso PMDAs to be working, and if = not, makes it so. After an upgrade to 3.9.0, the sample and sampledso PMDAs were installed = but not working (as expected). qa/check 0 fixed it all up. > -----Original Message----- > From: Nathan Scott [mailto:nathans@redhat.com] > Sent: Friday, 14 February 2014 11:22 AM > To: Ken McDonell > Cc: pcp developers > Subject: pmdasample source vs binary & QA testing >=20 > Hi Ken, >=20 > Just FYI - if doing any testing atm, as a result of the RPM "multilib" = changes, > we no longer ship a pre-built version of pmdasample. We ship source & > makefile, like the other demo PMDAs now, which helps make the > development packages architecture neutral of course. So may need an > ./Install in pmdas/sample (that automatically does the build) before = you next > run QA. >=20 > cheers. >=20 > -- > Nathan From nscott@redhat.com Fri Feb 14 00:04:46 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 383A07F57 for ; Fri, 14 Feb 2014 00:04:46 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id CDD35AC00C for ; Thu, 13 Feb 2014 22:04:42 -0800 (PST) X-ASG-Debug-ID: 1392357880-04bdf01d0b88530001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id xARcstFBHKyiH40L for ; Thu, 13 Feb 2014 22:04:40 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1E64cWB017002; Fri, 14 Feb 2014 01:04:38 -0500 Date: Fri, 14 Feb 2014 01:04:38 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: pcp developers Message-ID: <1137677123.6956816.1392357878691.JavaMail.zimbra@redhat.com> In-Reply-To: References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> <20140206133220.GC5017@redhat.com> <633105491.21839148.1391757935531.JavaMail.root@redhat.com> <2133757769.21973706.1391772553504.JavaMail.root@redhat.com> Subject: Re: Logged data integrity improvement ideas MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Logged data integrity improvement ideas Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Logged data integrity improvement ideas Thread-Index: V+q4k6zsLvA3OnD8S2tw2RLJA2qmng== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392357880 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145098 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi, Sorry its taken awhile to get back to this one, but I wanted to (attempt to) do it justice in terms of discussing I/O and some filesystem internals. ----- Original Message ----- > > ["logging durability: add fsync(2) when closing log archives"] > > > > Can you describe the testing done for this change or planned? > > The pcpqa suite, plus strace examination that the fsync(2)'s are going > out at the right time. There are still some known problems. OK - excellent. We have coverage on any regression (e.g., if we passed a dodgey fd & started to error out, something like that), and we know the call is being made. What we don't know is if the data is safe from a users POV. We of course must assume sanity from below the fsync(2) call: in glibc, the kernel and the hardware (sometimes a big assumption it turns out, heh), so no need to test that. But the missing test is log verification post-failure, when we *know* logs should be ondisk. When I've done this in the past (not PCP related), I've used a specialised crash test harness (as in, specially written for the task) - performing data generation (and metadata, also important to us here) using known patterns; fsync; crash *immediately* (cut power); then verify on reboot. In our case, its "do a daily log rotation (high level operation), then immediate restart, verify". Repeat, alot - its all as racey as can be - to build confidence - so the harness needs to help with that aspect. This seems silly (or might seem like we're testing the kernel) for our case at first glance, but we need to be particularly wary of the cases where we do things like writing to temporary files, then rename 'em over the old files (-i option to pmlogrewrite, for example), or where we generally replace one archive file with another - because then its not enough to fsync and the user will see corruption. For other reasons (below), the only places I'd encourage the use of fsync for us are during daily log rotation, and explicitly driven from individual tools (so, not initiated from libpcp on log close, though likely the syncing will need to be done via an internal double-underscore libpcp API). Ideally, we'd also be using rename (tricky with 3 archive files but it might be possible) and issuing fsync on the directory housing the final archive names - only at that point would we be as safe as we can be. > ... > This one's tricky to measure well. fsync does not increase I/O > amount, only compresses it along the time axis. *nod* but it turns out that latter statement is not always true; consider 2 cases that thwart this: - if the archive we're fsync'ing (eg on close) was used for some intermediate computation, before a final write pass, then we can double, triple, etc (depending on #passes) the runtime of the tool by fsyncing at some inappropriate (too early) point - we're not doing double passes in any of *our* tools, AFAIK (Ken?), but the PMAPI can have been used by anyone in any way, or might yet be used in the future in a multi-pass kind of way. Only the tools (as in, the PMAPI client tools & not necessarily part of our shipped toolkit) know when the right time to fsync is (e.g. when finished all passes over the data), if at all! Consider further - those files generated on an intermediate pass may then be unlinked before the following pass, and may never actually need to be written out. If we fsync'ed them... well, thats a case where we would increase the I/O amount via fsync! - most modern filesystems perform delayed allocation. If we make an assumption about when an appropriate time to flush is, we force the filesystems to allocate space early, and this can result in less optimal allocation patterns (causing seeks), increases to the amount of metadata for those files (so, same amount of data but a greater block/extent count) and another case where we'd have increased the amount of I/O results. But wait, there's more (and a free set of steak knives!). In Valerie's article she hints at this - when fsync is issued, due to the many complications of journalling and other wierd and wonderful filesystem internals, its not simply the data and the affected inode that will be getting flushed. Usually copious amounts of unrelated dirty metadata will be caught up in it too, as the journal must be flushed for everything that changed up to the point of completing the final data write in the file. So, the metadata for that file (which may require new space to be allocated, which touches free space trees, which may cause btree splits, all of which is yet more dirty metadata - all preceding operations will be logged on fsync). In modern XFS for example, even the transactions that would go into the journal are delayed (not just delayed allocation for data, IOW, but metadata operations as well), to allow it to detect and drop any that are not required, and reduce the amount of log I/O that is needed. So, the writeout has to to happen at *some* point - that can only be delayed so long. Any fsync activity that we start to engage in, however, is going to begin to circumvent these filesystem optimisations, and causes impact to the system in unrelated ways to our little toolkit. When the application doing the fsync's is an ACID compliant database for which the system is dedicated, this is fine. But when the program issuing the fsyncs is just a performance tool trying to make no impact on the system, we'll need to start taking care (it may be the filesystem that we are attempting to analyse with our tools!). Obviously, as stated in earlier mail, the more data we end up writing and flushing (big logs vs little logs), the more noticeable the impact. > > > There's also other subtleties discussed on the fsync(1) man page, > > its well worth a careful read too - the directory paragraph is > > relevant to our needs. > > Yup. We're a long way from the sort of robustness guarantees we might > like to have. This was just "low-hanging fruit" as they say, and > should mostly solve one particular problem you had encountered. The patches take the "insert fsync at salient-looking points in libpcp, esp log close" approach, so I'm not a fan of that for the above reasons - I think the tools are the right place to make these changes, and possibly even only via new command line options, for use by the daily log rotation regimes. Another random note about the initial fsync-on-close approach, I have seen some take the approack of fork(2)ing, the issuing the fsync from the child (I don't think we should do this). This technique can be used to hide the synchronous writing latency (which is enormous on a clunky old laptop with an 800 megabyte PCP archive!) that fsync introduces, if all we need to do is initiate the I/O "earlier". But, we should not do that, I mention it only as an aside. Hah, although having said that - we may want to add in a new pmlc/pmlogger fsync command to complement the flush command; that technique may well suit there (we do not want to delay the pmlogger pmFetch'ing and write'ing, if at all possible). cheers. -- Nathan From tsetserkotsekhmist@gmail.com Fri Feb 14 06:40:06 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 12AD97F55 for ; Fri, 14 Feb 2014 06:40:06 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id E754D304053 for ; Fri, 14 Feb 2014 04:40:05 -0800 (PST) X-ASG-Debug-ID: 1392381598-04bdf05165540f0001-S8gJnT Received: from sub.omsk.ru (sub.omsk.ru [94.137.22.18]) by cuda.sgi.com with ESMTP id 2vGv5b4L8n2Supsw (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 14 Feb 2014 04:40:00 -0800 (PST) X-Barracuda-Envelope-From: tsetserkotsekhmist@gmail.com X-Barracuda-Apparent-Source-IP: 94.137.22.18 Received: from cikzplr ([10.250.108.2]) by sub.omsk.ru (Kerio Connect 7.1.4); Thu, 13 Feb 2014 17:18:08 +0700 Message-ID: <600A950EA4554503A863818F4A3BA712@cikzplr> From: "tsetserkotsekhmist@gmail.com" To: "tsetserkotsekhmist@gmail.com" Subject: =?windows-1251?B?wuDxIOjt8uXwZfHz/vIg6uvo5e3y8Wvo5SDh?= =?windows-1251?B?4Of7IOTg7e379T8gz/Do+Ovo8uUgwmH4IPLl?= =?windows-1251?B?6+X0b+0g7PsgwmHsIO/lcOXn4u7t6Owg6CBw?= =?windows-1251?B?4PHx6uDm5ewg7+7kcG/h7WXl?= Date: Thu, 13 Feb 2014 17:17:47 +0700 X-ASG-Orig-Subj: =?windows-1251?B?wuDxIOjt8uXwZfHz/vIg6uvo5e3y8Wvo5SDh?= =?windows-1251?B?4Of7IOTg7e379T8gz/Do+Ovo8uUgwmH4IPLl?= =?windows-1251?B?6+X0b+0g7PsgwmHsIO/lcOXn4u7t6Owg6CBw?= =?windows-1251?B?4PHx6uDm5ewg7+7kcG/h7WXl?= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1236_01CF28DF.83CAFC90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 X-Barracuda-Connect: sub.omsk.ru[94.137.22.18] X-Barracuda-Start-Time: 1392381600 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 1.50 X-Barracuda-Spam-Status: No, SCORE=1.50 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_ADDR_MATCH, BSF_SC0_TG035a, BSF_SC3_MV0165, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145106 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.00 BSF_SC3_MV0165 Custom rule MV0165 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SC0_TG035a Message contains invalid style definition 0.50 BSF_SC0_SA_TO_FROM_ADDR_MATCH Sender Address Matches Recipient Address This is a multi-part message in MIME format. ------=_NextPart_000_1236_01CF28DF.83CAFC90 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Ba=F1 =E8=ED=F2=E5=F0=E5=F1=F3=FE=F2 =EA=EB=E8=E5=ED=F2c=EA=E8e =E1=E0=E7= =FB =E4=E0=ED=ED=FBx? =CFp=E8=F8=EB=E8=F2=E5 B=E0=F8 =F2e=EBe=F4o=ED =EC=FB= B=E0=EC =EF=E5=F0=E5=E7=E2=EE=ED=E8=EC =E8 =F0=E0=F1c=EA=E0=E6=E5=EC =EF= o=E4=F0=EE=E1=EDee ------=_NextPart_000_1236_01CF28DF.83CAFC90 Content-Type: text/html; charset="windows-1251" Content-Transfer-Encoding: quoted-printable
Ba=F1 =E8=ED=F2=E5=F0=E5=F1=F3=FE=F2 =EA=EB=E8=E5=ED=F2c=EA=E8= e =E1=E0=E7=FB =E4=E0=ED=ED=FBx? =CFp=E8=F8=EB=E8=F2=E5 B=E0=F8 =F2e=EBe=F4= o=ED =EC=FB B=E0=EC =EF=E5=F0=E5=E7=E2=EE=ED=E8=EC =E8 =F0=E0=F1c=EA=E0=E6= =E5=EC =EFo=E4=F0=EE=E1=EDee
------=_NextPart_000_1236_01CF28DF.83CAFC90-- From fche@redhat.com Fri Feb 14 09:47:08 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 4F1C57F55 for ; Fri, 14 Feb 2014 09:47:08 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 2D248304048 for ; Fri, 14 Feb 2014 07:47:04 -0800 (PST) X-ASG-Debug-ID: 1392392820-04cb6c6de03b4c20001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id zFAmiOEr16GH3KNs for ; Fri, 14 Feb 2014 07:47:01 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1EFkxIE020365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 14 Feb 2014 10:46:59 -0500 Received: from fche.csb (vpn-235-28.phx2.redhat.com [10.3.235.28]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1EFkxOv002210; Fri, 14 Feb 2014 10:46:59 -0500 Received: by fche.csb (Postfix, from userid 2569) id 5F556584E8; Fri, 14 Feb 2014 10:46:58 -0500 (EST) Date: Fri, 14 Feb 2014 10:46:57 -0500 From: "Frank Ch. Eigler" To: Nathan Scott Cc: pcp developers Subject: Re: Logged data integrity improvement ideas Message-ID: <20140214154657.GB18232@redhat.com> X-ASG-Orig-Subj: Re: Logged data integrity improvement ideas References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1178788786.16735370.1391119719356.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> <20140206133220.GC5017@redhat.com> <633105491.21839148.1391757935531.JavaMail.root@redhat.com> <2133757769.21973706.1391772553504.JavaMail.root@redhat.com> <1137677123.6956816.1392357878691.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1137677123.6956816.1392357878691.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392392820 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - > [...] But the missing test is log verification post-failure, when we > *know* logs should be ondisk. [...] We already know that the situation with the current code base, even with the fsync patches added, is not sufficient. There are few I/O error checks, and generally none at exit. The fsync stuff only claims to handle one particular problem. It's interesting to contemplate the sudden-power-off sort of testing, but it's premature. > Ideally, we'd also be using rename (tricky with 3 archive files > but it might be possible) and issuing fsync on the directory > housing the final archive names - only at that point would we be > as safe as we can be. Those may well be worthwhile further improvements. (Note that fsync'ing directories is uncommon amongst other tools, despite what the fsync(2) man page says.) > > This one's tricky to measure well. fsync does not increase I/O > > amount, only compresses it along the time axis. > > *nod* but it turns out that latter statement is not always true; > consider 2 cases that thwart this: > > - if the archive we're fsync'ing (eg on close) was used for some > intermediate computation, before a final write pass, then we can > double, triple, etc (depending on #passes) the runtime of the > tool by fsyncing at some inappropriate (too early) point [...] The new code only fsyncs at archive file close time. That in turns only affects files that were written-to (because fsync of a read-only file is a noop). AFAIK, none of our tools append to existing archives, so I'm not sure what kind of multi-write-pass processing you are referring to. > Consider further - those files generated on an intermediate pass may > then be unlinked before the following pass, and may never actually > need to be written out. If we fsync'ed them... well, thats a case > where we would increase the I/O amount via fsync! Yes, in this scenario, if one knows that the intermediate files are disposable, and one can't be bothered to place them into a tmpfs ram-disky volume, the fsyncs can cause more I/O than there might have been. (Even then, fsync does not invent I/O: the kernel could well have written out the data before the unlink, which is likelier with greater volume of data.) I hope that our other thread about future streamable archive files would make this scenario moot, by using pipes instead of files for such intermediate values. > - most modern filesystems perform delayed allocation. If we > make an assumption about when an appropriate time to flush is, > we force the filesystems to allocate space early, and this can > result in less optimal allocation patterns (causing seeks) [...] I don't see how this applies. We only fsync at file close, after which there will be no further allocation. > [...] Usually copious amounts of unrelated dirty metadata will be > caught up in it too, as the journal must be flushed for everything > that changed up to the point of completing the final data write in > the file. [...] This applies to some extent, especially on ext3. On other file systems, it's not as "copious". > [...] When the application doing the fsync's is an ACID compliant > database for which the system is dedicated, this is fine. But when > the program issuing the fsyncs is just a performance tool [...] I don't see how we can have it both ways. One can't on the one hand complain "system crash with no data flush - tail of the file corruption, etc., The last one is the most common ...", and then argue that a pinpoint fix for that problem is not worth some cost after all. > > Yup. We're a long way from the sort of robustness guarantees we might > > like to have. This was just "low-hanging fruit" as they say, and > > should mostly solve one particular problem you had encountered. > > The patches take the "insert fsync at salient-looking points > in libpcp, esp log close" approach, (Again, "salient-looking points" == "log file close".) > [...] I think the tools are the right place to make these changes, > and possibly even only via new command line options, for use by the > daily log rotation regimes. Knobs to override it are justifiable (like for that non-tmpfs intermediate file case), but I suggest defaulting to greater data-safety rather than less. This is the same default used for modern text editors, git, and of course databases of all kinds: they all fsync on close by default. As to "for daily log rotation", are you suggesting that pmlogger's own fresh/original output (which has the lowest write volume/rate, thus the lowest cost for fsync's) should not be considered at least as precious as the log-merging postprocessors'? > This [fork/fsync] technique can be used to hide the synchronous > writing latency (which is enormous on a clunky old laptop with an > 800 megabyte PCP archive!) that fsync introduces, if all we need to > do is initiate the I/O "earlier". Yes, 800MB I/O on a laptop, fsync or not, are a problem. - FChE From brolley@redhat.com Fri Feb 14 11:20:15 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 803927F51 for ; Fri, 14 Feb 2014 11:20:15 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 165EAAC005 for ; Fri, 14 Feb 2014 09:20:12 -0800 (PST) X-ASG-Debug-ID: 1392398401-04cbb00c2a3bb5c0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id sig7zQxHlHTyUBsH for ; Fri, 14 Feb 2014 09:20:06 -0800 (PST) X-Barracuda-Envelope-From: brolley@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1EHK1X4029220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 14 Feb 2014 12:20:01 -0500 Received: from [10.10.63.143] (vpn-63-143.rdu2.redhat.com [10.10.63.143]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1EHK0Wi016327 for ; Fri, 14 Feb 2014 12:20:00 -0500 Message-ID: <52FE5058.4030702@redhat.com> Date: Fri, 14 Feb 2014 12:20:24 -0500 From: Dave Brolley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ASG-Orig-Subj: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392398402 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 The commits below fix some of the qa fallout from these changes. There is still one outstanding problem which is affecting quite a few tests (039 046 053 085 161 178 234 242 248 304 352 354 466 524 593 650). The problem occurs when pmlogger is running as a normal user. In that case, pmlogger is unable to bind to (i.e. create) the unix domain socket in /var/run/pcp because that directory is not writable by normal users (drwxrwxr-x. 2 pcp pcp). Perhaps another location in that case? Dave ----------------------------------------------- commit 14098f8b0f89f6364fdadcad2523a381069db3d4 Author: Dave Brolley Date: Fri Feb 14 11:43:34 2014 -0500 Fix qa fallout from ipv6/unix socket implementation for pmlogger/pmlc. Address output differences caused by the default host now being local: Addresses regressions in qa tests 098 100 101 103 104 105 106 172 183 368 497 commit 71b527021a9c9b366a802bf54777b9063fcc12a3 Author: Dave Brolley Date: Fri Feb 14 11:41:12 2014 -0500 Tighten up lexical definition of a host url. Addresses qa fallout for test 645 from the ipv6/unix: socket implementation for pmlogger and pmlc. commit 83d4c2df654aab4caa2f808c143ace8268e45f45 Author: Dave Brolley Date: Fri Feb 14 11:39:00 2014 -0500 Return actual status code from connectLogger. Was returning -1 on error. Addresses qa fallout for qa test 439 from ipv6/unix socket implementation for pmlogger. From chandana@desilva.id.au Fri Feb 14 14:10:56 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 9C55F7F53 for ; Fri, 14 Feb 2014 14:10:56 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 2C506AC004 for ; Fri, 14 Feb 2014 12:10:52 -0800 (PST) X-ASG-Debug-ID: 1392408647-04cbb00c2b3c8260001-S8gJnT Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by cuda.sgi.com with ESMTP id yIRugb5aMkH26c8i (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 14 Feb 2014 12:10:48 -0800 (PST) X-Barracuda-Envelope-From: chandana@desilva.id.au X-Barracuda-Apparent-Source-IP: 204.13.248.66 Received: from ec2-54-252-74-219.ap-southeast-2.compute.amazonaws.com ([54.252.74.219] helo=mail.desilva.id.au) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1WEP5z-000N0Q-Ck for pcp@oss.sgi.com; Fri, 14 Feb 2014 20:10:47 +0000 Received: from [192.168.1.135] (d211-31-205-134.sun802.vic.optusnet.com.au [211.31.205.134]) by mail.desilva.id.au (Postfix) with ESMTPSA id A93C6207A8 for ; Fri, 14 Feb 2014 20:10:45 +0000 (UTC) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 54.252.74.219 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+6MfcoKK1SBP+TPWNt++sbnQJac7nObkw= Message-ID: <52FE7845.5020008@desilva.id.au> Date: Sat, 15 Feb 2014 07:10:45 +1100 From: Chandana De Silva Reply-To: chandana@desilva.id.au User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pmie - privileged use Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ASG-Orig-Subj: pmie - privileged use Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mho-03-ewr.mailhop.org[204.13.248.66] X-Barracuda-Start-Time: 1392408648 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145118 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- All, The newer versions pcp run as the non privileged user 'pcp' which is obviously good from a security perspective. My problem is with pmie. How would I get pmie to take some drastic proactive action, such as killing a rogue process ? One possibility is to give pcp sudo privileges on pmie. Is there another way ? From kenj@internode.on.net Fri Feb 14 16:20:49 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 828817F51 for ; Fri, 14 Feb 2014 16:20:49 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 0F510AC001 for ; Fri, 14 Feb 2014 14:20:45 -0800 (PST) X-ASG-Debug-ID: 1392416443-04cb6c6de23d0950001-S8gJnT Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id jtTsUWF9YrVKFPmh for ; Fri, 14 Feb 2014 14:20:43 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIGAKyV/lJ5LEjd/2dsb2JhbABZgwaDP1KoHZQQgRcXdIIlAQEFCAIZMyMMAQMCBgMRBAEBAwIjAwICGSANCQgCBAESCwWHdKcRoVoXgSmMfwEBTwcGgmmBSQSPKZsmg0EogTU Received: from ppp121-44-72-221.lns20.syd6.internode.on.net (HELO bozohorize) ([121.44.72.221]) by ipmail05.adl6.internode.on.net with ESMTP; 15 Feb 2014 08:50:41 +1030 From: "Ken McDonell" To: "'Nathan Scott'" , "'Frank Ch. Eigler'" Cc: "'pcp developers'" References: <1952377955.6159460.1392281163287.JavaMail.zimbra@redhat.com> <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> <20140213125811.GG11820@redhat.com> <1040057732.6827059.1392333686610.JavaMail.zimbra@redhat.com> In-Reply-To: <1040057732.6827059.1392333686610.JavaMail.zimbra@redhat.com> Subject: RE: Possible pmmgr issue? Date: Sat, 15 Feb 2014 09:20:32 +1100 X-ASG-Orig-Subj: RE: Possible pmmgr issue? Message-ID: <024301cf29d2$fc60d870$f5228950$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIIJXTr6HzUKtjwSm/+GIWI066zTAH+t6t0ApeCtHMCIP3IXJoNoAZQ Content-Language: en-au X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1392416443 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145121 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header > -----Original Message----- > From: Nathan Scott [mailto:nathans@redhat.com] > Sent: Friday, 14 February 2014 10:21 AM > To: Frank Ch. Eigler; Ken McDonell > Cc: pcp developers > Subject: Re: Possible pmmgr issue? > ... > Ken, I'd be interested in your thoughts on a few observations from the > pmlogger_daily scripts on this host (all defaults are in place, for = everything - > both pmlogger_daily & pmmgr): > - there seems to be some older data that is not being culled? See previous mail ... if merge finds a problem, culling and compressing = is skipped > - there's a couple of logs that haven't merged, possibly cos one has a = zero > sized file or two? I think the zero sized files are OK (expected, warnings issued but = proceed), the problem is the truncated archive (again, refer to earlier = mail for possible remediation options). > - from inspection of the pmlogger_daily script, we appear to always do = a > logmerge, even if there is only one log - could this not simply be = handled via a > mv(1) of the files? (avoiding the read/write I/O there entirely, for = the simple > case of one archive for the previous day - i.e. no pmcd/pmlogger = restarts). Yep, that's an optimization that could be done. Probably safer to do a 2 pass operation 1. hard link each of the index, meta, 0, 1, ... files 2. rm the original ones This way you always have at least one complete archive, even if the = system crashes or the script is interrupted/terminated. From kenj@internode.on.net Fri Feb 14 16:30:00 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B309D7F51 for ; Fri, 14 Feb 2014 16:30:00 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 9E84C8F8074 for ; Fri, 14 Feb 2014 14:30:00 -0800 (PST) X-ASG-Debug-ID: 1392416994-04cbb00c2a3d0520001-S8gJnT Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id eKv6C6xIAAODoaeL for ; Fri, 14 Feb 2014 14:29:55 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQMAAWY/lJ5LEjd/2dsb2JhbABZgwY4gwe8fQMCgRcXdIIlAQEBBAEBAQUCHRMcGBcBAwIGAxEEAQEoBxkOEg0JCAIEARILBQuHaQ7Icox4gggGhDIEjymFGpYMgT+CAig Received: from ppp121-44-72-221.lns20.syd6.internode.on.net (HELO bozohorize) ([121.44.72.221]) by ipmail05.adl6.internode.on.net with ESMTP; 15 Feb 2014 08:59:53 +1030 From: "Ken McDonell" To: , References: <52FE7845.5020008@desilva.id.au> In-Reply-To: <52FE7845.5020008@desilva.id.au> Subject: RE: [pcp] pmie - privileged use Date: Sat, 15 Feb 2014 09:29:44 +1100 X-ASG-Orig-Subj: RE: [pcp] pmie - privileged use Message-ID: <025c01cf29d4$45abdb50$d10391f0$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHaVliQsLyx+hv4Ts8xR1s6bUNvoJqe+yyA Content-Language: en-au X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1392416994 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145121 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== Chandana, I think you have already suggested the "best" solution for a "behind the firewall" environment ... sudo glue, as in (in sort of reverse order of how you'd set it up) sudo -u pcp pmie -c /tmp/xxx uid=0(root) gid=0(root) groups=0(root) uid=0(root) gid=0(root) groups=0(root) $ cat /tmp/xxx hinv.ncpu > 0 -> shell "sudo id"; $ grep sudo /etc/group sudo:x:27:kenj,pcpqa,pcp $ sudo grep \%sudo /etc/sudoers %sudo ALL=(ALL:ALL) NOPASSWD: ALL > -----Original Message----- > From: pcp-bounces@oss.sgi.com [mailto:pcp-bounces@oss.sgi.com] On > Behalf Of Chandana De Silva > Sent: Saturday, 15 February 2014 7:11 AM > To: pcp@oss.sgi.com > Subject: [pcp] pmie - privileged use > > All, > > The newer versions pcp run as the non privileged user 'pcp' which is > obviously good from a security perspective. > > My problem is with pmie. How would I get pmie to take some drastic > proactive action, such as killing a rogue process ? > > One possibility is to give pcp sudo privileges on pmie. > > Is there another way ? > > _______________________________________________ > pcp mailing list > pcp@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/pcp From pcolby@gmail.com Fri Feb 14 17:20:06 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,T_DKIM_INVALID autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 365AE7F51 for ; Fri, 14 Feb 2014 17:20:06 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id BB0C7AC003 for ; Fri, 14 Feb 2014 15:20:02 -0800 (PST) X-ASG-Debug-ID: 1392420000-04cbb00c283d33f0001-S8gJnT Received: from mail-yk0-f177.google.com (mail-yk0-f177.google.com [209.85.160.177]) by cuda.sgi.com with ESMTP id t2Fd47mPtkSBkCNP (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 14 Feb 2014 15:20:01 -0800 (PST) X-Barracuda-Envelope-From: pcolby@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.160.177 X-Barracuda-IPDD: Level1 [gmail.com/209.85.160.177] Received: by mail-yk0-f177.google.com with SMTP id q200so24918311ykb.8 for ; Fri, 14 Feb 2014 15:20:00 -0800 (PST) X-Barracuda-IPDD: Level1 [gmail.com/209.85.160.177] X-Barracuda-IPDD: Level1 [gmail.com/209.85.160.177] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=G0f7HUIuqT4FrWlIB7tJj8VvWoqmy4WEMQSPMpyZz6k=; b=ofwjueP9IOWnDSp1P1UaTi8BlgPnRiBwKXDIfL7ccUfzwqd6kNAibxxkhvmbCrWQkK mTO7nQxxhX74j5+pL+m2VZBf8bhkoGeSQTUT1CbPy8LhYruZ83rP1knGlzgaKdGvGkgJ 5Df0XbcY4CHioNjWqEy+oJFdNQuS+TdGy//mB93rrCnE1mwY+z1wfyHP21OGHrcIQjBR arX4xJgyUq8XYo2jAEs1jmo8aAD0MdVwNz4GecqS9bWH9tEthhCmTtAaguoD4lNzQRKw UawP0Sgi6V4JitjXokTnoZ5gPD69ENKqUmrN9guoaQvWpavlGhCOSBGPmRrdBPP+QQnh G0ZA== MIME-Version: 1.0 X-Received: by 10.236.85.112 with SMTP id t76mr251604yhe.74.1392420000642; Fri, 14 Feb 2014 15:20:00 -0800 (PST) Sender: pcolby@gmail.com Received: by 10.170.159.196 with HTTP; Fri, 14 Feb 2014 15:20:00 -0800 (PST) In-Reply-To: <2141282812.6069067.1392268437554.JavaMail.zimbra@redhat.com> References: <480923908.1506080.1392028044682.JavaMail.zimbra@redhat.com> <2141282812.6069067.1392268437554.JavaMail.zimbra@redhat.com> Date: Sat, 15 Feb 2014 10:20:00 +1100 X-Google-Sender-Auth: Aao0iNAE_UPmyZ3jKQeumP8X7go Message-ID: Subject: Re: [pcp] Fwd: Official domain number for my Qpid PMDA project? From: Paul Colby X-ASG-Orig-Subj: Re: [pcp] Fwd: Official domain number for my Qpid PMDA project? To: Nathan Scott Cc: pcp@oss.sgi.com Content-Type: text/plain; charset=ISO-8859-1 X-Barracuda-Connect: mail-yk0-f177.google.com[209.85.160.177] X-Barracuda-Start-Time: 1392420001 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145123 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature On Thu, Feb 13, 2014 at 4:13 PM, Nathan Scott wrote: > > Wow, that is some neat code - I bet you have no loose papers on your > desk ;) Haha. I don't consider myself a neat freak... but now that I think about it, my desk is pretty neat :) > - all tested, valgrind used, the class encapsulation looks > very nice in the end result PMDA, just generally neat. Great. Was hoping for some feedback on that. I did put in a lot of work just trying to make the resulting API, and easy to maintain for implementers (such as Qpid PMDA) without incurring too much performance overhead. So far, I'm very happy with the result, but what's neat and readable to me, does not always ring true for others. > I'm appreciating all the metric help text - it all looks sensible & > the units and semantics used appear to be spot on. Just good stuff > all round - again, well done! Thanks. I can't take too much credit though, the metrics names, descriptions etc were all exported verbatim (with only very minor tweaks) from Qpid - ie Qpid's QMFv1 interface exports those metrics, including descriptions, I just mapped them to PCP types :) > > Not sure if you came across dbpmda(1), but this option... > > options.add_options() > ("no-pmda", bool_switch(), "run as a non-PMDA for development"); > > ... made me wonder. I use either/or in testing (PMDA options and/or > dbpmda), so having the option is still useful - just mentioning the > tool in case you'd not come across it yet. Can be run as a regular > user, so can be simpler (and more targeted) than using pmcd itself. Excellent. No, I hadn't looked into dbpmda, but it looks quite useful. The no-pmda option cuts straight to the Qpid code so I can debug / diagnose the Qpid interface. It looks like dbpmda would make it easier to debug the PMDA interface on top of that. Will have a closer look sometime. >> > Do you want a link >> > or two on http://oss.sgi.com/projects/pcp/source.html for those trees? >> > Done. Thank you very much! :) Cheers, pc. From nscott@redhat.com Fri Feb 14 19:41:08 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 7E8567F3F for ; Fri, 14 Feb 2014 19:41:08 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 32CFAAC008 for ; Fri, 14 Feb 2014 17:41:07 -0800 (PST) X-ASG-Debug-ID: 1392428463-04bdf05165913c0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id QOyj8Sv9FZJOIy0o for ; Fri, 14 Feb 2014 17:41:03 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1F1ewa8003981; Fri, 14 Feb 2014 20:40:58 -0500 Date: Fri, 14 Feb 2014 20:40:57 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell , chandana@desilva.id.au Cc: pcp@oss.sgi.com Message-ID: <29691188.7807293.1392428457919.JavaMail.zimbra@redhat.com> In-Reply-To: <025c01cf29d4$45abdb50$d10391f0$@internode.on.net> References: <52FE7845.5020008@desilva.id.au> <025c01cf29d4$45abdb50$d10391f0$@internode.on.net> Subject: Re: [pcp] pmie - privileged use MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmie - privileged use Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmie - privileged use Thread-Index: AQHaVliQsLyx+hv4Ts8xR1s6bUNvoJqe+yyA3+3o7H0= X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392428463 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145126 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > > One possibility is to give pcp sudo privileges on pmie. > > Is there another way ? > > I think you have already suggested the "best" solution for a "behind the > firewall" environment ... sudo glue, as in (in sort of reverse order of how > you'd set it up) > ... There is an alternative which doesn't involve sudo, if use of sudo is an issue. A PMDA can be written with a storable metric, and pmie can be told to pmstore(1) into that metric on detection of a process to kill. A PMDA starts out its life running as root, and (as many do) can choose to change to an arbitrary unprivileged user. They can also nowadays obtain the credentials of the user account requesting the pmstore(1). As such they provide several options for security models - e.g. the PMDA could change user to "apache" early on in its life, dropping root privileges - then, at pmstore time (even if the credentials checks were not being used) the PMDA would be limited in the damage it can do; e.g. only being able to terminate "apache" user processes. cheers. -- Nathan From chandana@desilva.id.au Fri Feb 14 19:45:55 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id B0CF87F50 for ; Fri, 14 Feb 2014 19:45:55 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 4110FAC005 for ; Fri, 14 Feb 2014 17:45:55 -0800 (PST) X-ASG-Debug-ID: 1392428752-04cbb00c2b3dd330001-S8gJnT Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by cuda.sgi.com with ESMTP id iDopqXk2NNER3wKN (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 14 Feb 2014 17:45:53 -0800 (PST) X-Barracuda-Envelope-From: chandana@desilva.id.au X-Barracuda-Apparent-Source-IP: 204.13.248.72 Received: from ec2-54-252-74-219.ap-southeast-2.compute.amazonaws.com ([54.252.74.219] helo=mail.desilva.id.au) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1WEUKG-000KlW-KY; Sat, 15 Feb 2014 01:45:52 +0000 Received: from [192.168.1.135] (d211-31-205-134.sun802.vic.optusnet.com.au [211.31.205.134]) by mail.desilva.id.au (Postfix) with ESMTPSA id 1B953207A8; Sat, 15 Feb 2014 01:45:50 +0000 (UTC) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 54.252.74.219 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19gmclw+z4wrUmL/OJcbn49kUnEKY64i6w= Message-ID: <52FEC6CD.7050202@desilva.id.au> Date: Sat, 15 Feb 2014 12:45:49 +1100 From: Chandana De Silva Reply-To: chandana@desilva.id.au User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Scott , Ken McDonell CC: pcp@oss.sgi.com Subject: Re: [pcp] pmie - privileged use References: <52FE7845.5020008@desilva.id.au> <025c01cf29d4$45abdb50$d10391f0$@internode.on.net> <29691188.7807293.1392428457919.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pmie - privileged use In-Reply-To: <29691188.7807293.1392428457919.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mho-02-ewr.mailhop.org[204.13.248.72] X-Barracuda-Start-Time: 1392428753 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145126 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Thanks for both suggestions, I think sudo glue is simpler from an admin perspective, and a bunch sysadmins not well versed in pcp lore. On 15/02/14 12:40, Nathan Scott wrote: > > ----- Original Message ----- >>> One possibility is to give pcp sudo privileges on pmie. >>> Is there another way ? >> I think you have already suggested the "best" solution for a "behind the >> firewall" environment ... sudo glue, as in (in sort of reverse order of how >> you'd set it up) >> ... > There is an alternative which doesn't involve sudo, if use of sudo is an > issue. A PMDA can be written with a storable metric, and pmie can be told > to pmstore(1) into that metric on detection of a process to kill. A PMDA > starts out its life running as root, and (as many do) can choose to change > to an arbitrary unprivileged user. > > They can also nowadays obtain the credentials of the user account requesting > the pmstore(1). As such they provide several options for security models - > e.g. the PMDA could change user to "apache" early on in its life, dropping > root privileges - then, at pmstore time (even if the credentials checks were > not being used) the PMDA would be limited in the damage it can do; e.g. only > being able to terminate "apache" user processes. > > cheers. > > -- > Nathan From kenj@internode.on.net Mon Feb 17 00:37:11 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 8481D7F84 for ; Mon, 17 Feb 2014 00:37:11 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 5B6778F8066 for ; Sun, 16 Feb 2014 22:37:08 -0800 (PST) X-ASG-Debug-ID: 1392619025-04cb6c6de14a7370001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id cQWsH8AECdllSOaD for ; Sun, 16 Feb 2014 22:37:06 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtAdAPCsAVN20YajPGdsb2JhbAANTItRt3IBgTYDAQEBATiEFjQCMhoNCAEBsQGiMReTQASuEA Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail04.adl6.internode.on.net with ESMTP; 17 Feb 2014 17:07:04 +1030 Message-ID: <5301AE27.10007@internode.on.net> Date: Mon, 17 Feb 2014 17:37:27 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: PCP Mailing List Subject: PCP 3.9.0 install problems Content-Type: text/plain; charset=ISO-8859-1 X-ASG-Orig-Subj: PCP 3.9.0 install problems Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1392619026 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145199 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Trying to upgrade an old (!) 3.8.5 PCP installation to PCP 3.9.0 with packages made from latest source. System is LinuxMint 15. Seeing several errors like this ... Unpacking libpcp-mmv-perl (from .../libpcp-mmv-perl_3.9.0_i386.deb) ... dpkg: error processing build/deb/libpcp-mmv-perl_3.9.0_i386.deb (--install): trying to overwrite '/usr/lib/perl/5.14/perllocal.pod', which is also in package libpcp-import-perl 3.9.0 Anyone else seeing this? Anyone know how to fix it? From kenj@internode.on.net Mon Feb 17 00:38:37 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 80D207F84 for ; Mon, 17 Feb 2014 00:38:37 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 553A18F8050 for ; Sun, 16 Feb 2014 22:38:37 -0800 (PST) X-ASG-Debug-ID: 1392619114-04cbb00c284a3570001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id WBpe6CvKpfI2aKj5 for ; Sun, 16 Feb 2014 22:38:34 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIRAPCsAVN20YajPGdsb2JhbAANTIM+wTwDAQEBATiDCFEwDRYYAwIBAgExJwYCAQGxAaJIk0AEmV6UMg Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail04.adl6.internode.on.net with ESMTP; 17 Feb 2014 17:08:33 +1030 Message-ID: <5301AE80.6060703@internode.on.net> Date: Mon, 17 Feb 2014 17:38:56 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pcp updates - mostly pmie Content-Type: text/plain; charset=ISO-8859-1 X-ASG-Orig-Subj: pcp updates - mostly pmie Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1392619114 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145199 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- A couple of curly bug fixes for pmie in here, plus QA fallout. Changes committed to git://oss.sgi.com/kenj/pcp.git dev qa/.gitignore | 2 qa/115 | 4 qa/115.out | 1 qa/228 | 16 qa/321 | 1 qa/514 | 7 qa/514.out.3 | 2438 +++++++++++++++++++++++++++++++++++++++++++++++++ qa/520 | 7 qa/520.out.3 | 597 +++++++++++ qa/523 | 17 qa/523.out | 14 qa/523.out.1 | 497 +++++++++ qa/523.out.2 | 499 ++++++++++ qa/733 | 17 qa/733.out | 1 qa/733.out.1 | 239 ++++ qa/733.out.2 | 240 ++++ qa/815 | 32 qa/815.out | 12 qa/common.filter | 1 qa/group | 1 src/pmie/src/fetch.sk | 9 src/pmie/src/meta | 4 src/pmie/src/pmie.c | 2 src/pmmgr/rc_pmmgr | 2 src/pmwebapi/rc_pmwebd | 2 26 files changed, 4632 insertions(+), 30 deletions(-) commit c8c1a0ce13dcf307314a5bfeb7bb9471154a3fda Author: Ken McDonell Date: Mon Feb 17 16:18:33 2014 +1100 pmie - another day one bug, this time in count_* operators The operand of the count_inst, count_host and count_sample operators is a logical expression. If the expression is set values (multiple instances for count_inst, multiple hosts for count_host, etc), then the code did not check for the tri-state value of UNKNOWN (or DUNNO internally), rather it added the values assuming 0 for FALSE and 1 for TRUE ... DUNNO is 2 which explains why the result was TWICE the size of the instance domain if the expressions was undefined over and instance domain. Part 2 of the bug Chandana de Silva discovered with this simple pmie rule: count_inst( match_inst "httpd" proc.psinfo.pid > 0) > 0 -> print "count %v"; that reported 6 most of the time, and sometimes reported 1400+ qa/815 now exercises something similar. commit 82ab0b5504648e8cfd5fa42958af5cbbbf38875d Author: Ken McDonell Date: Mon Feb 17 16:12:35 2014 +1100 qa/733 - updated output after pmie bug fix Seeing some more results with defined values after the first fetch. commit ea2c1769470715e182e53c1dee5f09ac21dd39b4 Author: Ken McDonell Date: Mon Feb 17 16:03:59 2014 +1100 qa/523 - updated output after pmie bug fix Seeing some more results with defined values after the first fetch. commit 7d41f28d952fe4f8a3cc8c4fc8afe11e12d15ba8 Author: Ken McDonell Date: Mon Feb 17 16:02:11 2014 +1100 qa/520 - updated output after pmie bug fix Seeing some more results with defined values after the first fetch. commit 10c792f36296a10ddcd2c13bbbb43af0df4bf8b1 Author: Ken McDonell Date: Mon Feb 17 15:55:19 2014 +1100 qa/514 - updated output after pmie bug fix Seeing some more results with defined values after the first fetch. commit d1dfe14b083f9730f5cbd973a6764dabcb953d65 Author: Ken McDonell Date: Mon Feb 17 15:46:17 2014 +1100 pmie - day one bug in fetch logic On the first fetch and the fetch after a dynamic instance domain has changed membership, the values may have been incorrectly marked as "not valid", preventing rules being evaluated correctly. Part 1 of the bug Chandana de Silva discovered with this simple pmie rule: count_inst( match_inst "httpd" proc.psinfo.pid > 0) > 0 -> print "count %v"; that reported 6 most of the time, and sometimes reported 1400+ commit 1b883a0ca8bb91fe675973a2ed21760f7cb7b72a Author: Ken McDonell Date: Mon Feb 17 14:57:32 2014 +1100 qa/321 - dodge permission issue "... warning cannot create stats file dir ..." message still appearing after pmie change to quieten this because we're using pmie -v here. Filter these lines out. commit 6717436693b165a1a5401d3577e078a2a5aa0cc8 Author: Ken McDonell Date: Mon Feb 17 14:47:24 2014 +1100 pmie - quieten warning after tmp dir perms change After recent changes to the mode and ownership of the $PCP_VAR_DIR/tmp directory, the message "... warning cannot create stats file dir ..." may be emitted each time pmie is run as a user other than "pcp". This happens a LOT in QA. Since the message is only a warning, and the only side-effect is that the pmie process is not visible in the instance domain of the pmcd.pmie metrics (it is likely that no one but kenj cares!), I've suppressed the message unless one of the pmie verbose flags is set (-v, -V or -W). commit 292d0374f4702db6225223b96bfb74fc9850e250 Author: Ken McDonell Date: Mon Feb 17 14:45:29 2014 +1100 qa/228 - dodge permission issue "... warning cannot create stats file dir ..." message still appearing after pmie change to quieten this because we're using pmie -v here. Filter these lines out. commit 017ec17ff3563047bb92806d69b0a9a1cfc38fbd Author: Ken McDonell Date: Mon Feb 17 14:41:22 2014 +1100 qa/115 - non-determinism in pmie stop init script The message "...: PMIE not running" may or may not be there ... add filter and strip from expected output commit 0f0ba77214193f6a415365e9ee2db2a53a6e8a6d Author: Ken McDonell Date: Mon Feb 17 14:39:11 2014 +1100 qa/815 [new] - tickle pmie bug pmie bug in count_ method when boolean expression is UNKNOWN ... thanks to Chandana de Silva for pointing out the example that showed this. commit 421b195fc4197eda0c5a93488f9e6c1681186cb4 Author: Ken McDonell Date: Mon Feb 17 14:35:49 2014 +1100 qa/common.filter - strip blank lines from pmie init script output Recent changes to the pmie init scripts seem to have introduced the possibility of blank lines being output ... make 'em go away so we don't get unwanted QA failures. Example blank line output ... <---- HERE /etc/init.d/pmie: Warning: Performance Co-Pilot Inference Engine (pmie) is disabled. To enable pmie, run the following as root: update-rc.d -f pmie remove update-rc.d pmie defaults 94 06 commit 4e3bc79318def74c5a2433461942465c6e6b94c5 Author: Ken McDonell Date: Sun Feb 16 16:33:19 2014 +1100 pmwebd and pmmgr ... terser start up messages To be consistent with other PCP bits-n-bobs, we've been using terser messages from the init scripts, so this commit changes Performance Co-Pilot starting pmwebd (logfile is /var/log/pcp/pmwebd/pmwebd.log) ... and Performance Co-Pilot starting pmmgr (logfile is /var/log/pcp/pmmgr/pmmgr.log) ... to become Starting pmwebd ... and Starting pmmgr ... From nscott@redhat.com Mon Feb 17 02:21:09 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id B9F317F85 for ; Mon, 17 Feb 2014 02:21:09 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id A2873304032 for ; Mon, 17 Feb 2014 00:21:09 -0800 (PST) X-ASG-Debug-ID: 1392625264-04cb6c6de14ac8b0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id HnAUH3Fn1z1lpOHi for ; Mon, 17 Feb 2014 00:21:04 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1H8L06X004951; Mon, 17 Feb 2014 03:21:00 -0500 Date: Mon, 17 Feb 2014 03:21:00 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: PCP Mailing List Message-ID: <1027442162.8195023.1392625260273.JavaMail.zimbra@redhat.com> In-Reply-To: <5301AE27.10007@internode.on.net> References: <5301AE27.10007@internode.on.net> Subject: Re: [pcp] PCP 3.9.0 install problems MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] PCP 3.9.0 install problems Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: PCP 3.9.0 install problems Thread-Index: /AOaEacaWkLElez43jlz+T3ZVgVC+Q== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392625264 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145201 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > Trying to upgrade an old (!) 3.8.5 PCP installation to PCP 3.9.0 with > packages made from latest source. > > System is LinuxMint 15. > > Seeing several errors like this ... > > Unpacking libpcp-mmv-perl (from .../libpcp-mmv-perl_3.9.0_i386.deb) ... > dpkg: error processing build/deb/libpcp-mmv-perl_3.9.0_i386.deb (--install): > trying to overwrite '/usr/lib/perl/5.14/perllocal.pod', which is also in > package libpcp-import-perl 3.9.0 > > Anyone else seeing this? Not here, all is quiet on the "Debian unstable" build front. > Anyone know how to fix it? Something seems to have gone wrong in the packaging - it looks like all of the perl packages have acquired this "perllocal.pod" file for some strange reason, and so they conflict with each other? That file should not exist, at least not installed from any pcp package. "pod" probably stands for "plain old documentation" in this context, FWIW. $ dpkg --listfiles libpcp-import-perl /. /usr /usr/lib /usr/lib/perl5 /usr/lib/perl5/PCP /usr/lib/perl5/PCP/LogImport.pm /usr/lib/perl5/auto /usr/lib/perl5/auto/PCP /usr/lib/perl5/auto/PCP/LogImport /usr/lib/perl5/auto/PCP/LogImport/LogImport.so /usr/lib/perl5/auto/PCP/LogImport/LogImport.bs /usr/share /usr/share/man /usr/share/man/man3 /usr/share/man/man3/PCP::LogImport.3pm.gz /usr/share/doc /usr/share/doc/libpcp-import-perl /usr/share/doc/libpcp-import-perl/copyright /usr/share/doc/libpcp-import-perl/changelog.gz The list of files in the perl deb packages is generated via the debian/rules file, via "make -C src/perl/LogImport install_perl" followed by "dh_perl -p libpcp-import-perl" ... so one of those two stages will be introducing this quirk (both are largely out of our control though). cheers. -- Nathan From nscott@redhat.com Mon Feb 17 02:43:25 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 3DCD07F85 for ; Mon, 17 Feb 2014 02:43:25 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id CA3E9AC002 for ; Mon, 17 Feb 2014 00:43:21 -0800 (PST) X-ASG-Debug-ID: 1392626596-04bdf00fc378a30001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id Jkd3aoGuVD7t70Fo for ; Mon, 17 Feb 2014 00:43:16 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1H8hCg9023344; Mon, 17 Feb 2014 03:43:12 -0500 Date: Mon, 17 Feb 2014 03:43:12 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: pcp developers Message-ID: <7032409.8207692.1392626592398.JavaMail.zimbra@redhat.com> In-Reply-To: <024301cf29d2$fc60d870$f5228950$@internode.on.net> References: <1952377955.6159460.1392281163287.JavaMail.zimbra@redhat.com> <1444843200.6174759.1392282098405.JavaMail.zimbra@redhat.com> <20140213125811.GG11820@redhat.com> <1040057732.6827059.1392333686610.JavaMail.zimbra@redhat.com> <024301cf29d2$fc60d870$f5228950$@internode.on.net> Subject: Re: Possible pmmgr issue? MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Possible pmmgr issue? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Possible pmmgr issue? Thread-Index: AQIIJXTr6HzUKtjwSm/+GIWI066zTAH+t6t0ApeCtHMCIP3IXJoNoAZQKNotKTU= X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392626596 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145201 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Ken, ----- Original Message ----- > > -----Original Message----- > > pmlogger_merge: Warning: archive "20140123.09.55" is empty and will be > > skipped Input archives to be merged: > > 20140123.00.10 > > 20140123.16.25 > > pmlogextract: Error: __pmLogRead[log 20140123.00.10]: Corrupted record in > > a PCP archive log > > pmlogextract: Error occurred at byte offset 2690960 into a file of 2691072 > > bytes. > > Note, this is a place where we could be a whole lot smarter. The archive is > not corrupted, it is simply truncated, and our library and tools could > handle this in a more elegant manner (warn not error for example). I don' > think this would be a big piece of work, we'd just need a different error > (not PM_ERR_LOGREC) returned from __pmLogRead() and then an audit of the > callers to __pmLogRead() ... pmlogextract would be a good place to start ... > 8^)> > > I'd be willing to do this if it was considered a good idea. Makes sense to me. > I am not sure that pmlogger has been fixed to offer a mode that sacrifices > additional write(2) calls as a trade-off for reducing the chance of log > truncation ... this would reduce this case to being only seen when the > system crashes (or fills up a filesystem), rather than including the > pmlogger is killed by SIGKILL case). Those write(2) calls are not atomic either of course. There's always going to be tradeoffs, not clear there's anything terribly wrong with the status quo for small values of archive size. > [...] > The empty log file was created by pmlogger just before it suffered infant > mortality ... this is expected and does not break the merge and log rotate > script. Ah, interesting point! Thanks for the tip. > > In terms of the cull/compress though, the last line is key ... it seems > > overly > > drastic - but appears to be working as planned, Ken? > > The current logic is if you cannot merge for some reason, do no delete the > input archives ... but since the delete is done in a later pass, the only > safe thing to do is to abandon the delete ... and this takes out the > compress handling as well. > > The truncated archive fix proposed above would band-aid over this. But we > probably need to add communication between the merge and cull/compress > passes to allow the merge to indicate some archives are problematic and > should not be culled or compressed ... this would not be too hard to > implement. Question is - is the right thing to do to attempt to keep these old, broken archives, or cull them along with the old not broken ones? Thats not clear, to me anyway, in this case I'd been happily accepting all data would be gone after the cull time. > > Self-correction would be good, once the problem archives have all scrolled > > past their use-by date? > > So the second suggestion above would do this, I think. If it can be done without being overly complex, thats fine, but otherwise I think the (presumably simpler) alternative of culling all older files would be fine too. > > - from inspection of the pmlogger_daily script, we appear to always do a > > logmerge, even if there is only one log - could this not simply be handled > > via a > > mv(1) of the files? (avoiding the read/write I/O there entirely, for the > > simple > > case of one archive for the previous day - i.e. no pmcd/pmlogger restarts). > > Yep, that's an optimization that could be done. Fabulous! > Probably safer to do a 2 pass operation > 1. hard link each of the index, meta, 0, 1, ... files > 2. rm the original ones > > This way you always have at least one complete archive, even if the system > crashes or the script is interrupted/terminated. Yep, sounds good. cheers. -- Nathan From kenj@internode.on.net Mon Feb 17 03:12:18 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 7B7427F85 for ; Mon, 17 Feb 2014 03:12:18 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 239FDAC004 for ; Mon, 17 Feb 2014 01:12:14 -0800 (PST) X-ASG-Debug-ID: 1392628332-04bdf00fca7aa70001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id WamPDje3qJSrhFNW for ; Mon, 17 Feb 2014 01:12:12 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AulZALfRAVN20YajPGdsb2JhbABZgwaEEYQ6o2SUE4EZFwMBAQEBODWCJQEBBQgCGQUuGAsMAQMCBgMRBAEBAwIjAwICGSAKAwkIAgQTCwWHdKoLoUYXgSmNWAcGgmmBSQSPKZ5nKA Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO bozohorize) ([118.209.134.163]) by ipmail04.adl6.internode.on.net with ESMTP; 17 Feb 2014 19:42:11 +1030 From: "Ken McDonell" To: "'Nathan Scott'" Cc: "'PCP Mailing List'" References: <5301AE27.10007@internode.on.net> <1027442162.8195023.1392625260273.JavaMail.zimbra@redhat.com> In-Reply-To: <1027442162.8195023.1392625260273.JavaMail.zimbra@redhat.com> Subject: RE: [pcp] PCP 3.9.0 install problems Date: Mon, 17 Feb 2014 20:12:04 +1100 X-ASG-Orig-Subj: RE: [pcp] PCP 3.9.0 install problems Message-ID: <003e01cf2bc0$5430c030$fc924090$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQFbJRHcE92FHiIyUzvJ3odww4uEgwKrp+Erm4vXqrA= Content-Language: en-au X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1392628332 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145201 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header > -----Original Message----- > From: Nathan Scott [mailto:nathans@redhat.com] > Sent: Monday, 17 February 2014 7:21 PM > To: Ken McDonell > Cc: PCP Mailing List > Subject: Re: [pcp] PCP 3.9.0 install problems >=20 > Not here, all is quiet on the "Debian unstable" build front. >=20 > > Anyone know how to fix it? >=20 > Something seems to have gone wrong in the packaging - it looks like = all of the > perl packages have acquired this "perllocal.pod" file for some strange = reason, > and so they conflict with each other? That file should not exist, at = least not > installed from any pcp package I cleaned out build/deb/pcp-3.* Then Makepkgs Then ... kenj@bozo-laptop:~/src/pcp$ !find find . -name perllocal.pod ./build/deb/pcp-3.9.0/debian/libpcp-mmv-perl/usr/lib/perl/5.14/perllocal.= pod ./build/deb/pcp-3.9.0/debian/libpcp-import-perl/usr/lib/perl/5.14/perlloc= al.pod ./build/deb/pcp-3.9.0/debian/libpcp-logsummary-perl/usr/lib/perl/5.14/per= llocal.pod ./build/deb/pcp-3.9.0/debian/libpcp-pmda-perl/usr/lib/perl/5.14/perllocal= .pod So something in the Perl packaging has come unglued, ... again. Sigh. And there are multiple references to perllocal.pod in the code base ... kenj@bozo-laptop:~/src/pcp$ grep -r perllocal . [./build ones deleted] ./Logs/pcp:Appending installation info to = /home/kenj/src/pcp/build/deb/pcp-3.9.0/debian/libpcp-mmv-perl/usr/lib/per= l/5.14/perllocal.pod ./Logs/pcp:Appending installation info to = /home/kenj/src/pcp/build/deb/pcp-3.9.0/debian/libpcp-pmda-perl/usr/lib/pe= rl/5.14/perllocal.pod ./Logs/pcp:Appending installation info to = /home/kenj/src/pcp/build/deb/pcp-3.9.0/debian/libpcp-import-perl/usr/lib/= perl/5.14/perllocal.pod ./Logs/pcp:Appending installation info to = /home/kenj/src/pcp/build/deb/pcp-3.9.0/debian/libpcp-logsummary-perl/usr/= lib/perl/5.14/perllocal.pod ./src/include/builddefs: find $$DIST_ROOT/$(PERL_INSTALL_BASE) -name = perllocal.pod -exec rm -f '{}' ';' ; \ ./src/include/builddefs: find $$DIST_ROOT/$(PERL_INSTALL_BASE) -name = perllocal.pod -exec rm -f '{}' ';' ; \ ./src/include/builddefs.in: find $$DIST_ROOT/$(PERL_INSTALL_BASE) -name = perllocal.pod -exec rm -f '{}' ';' ; \ ./src/include/builddefs.in: find $$DIST_ROOT/$(PERL_INSTALL_BASE) -name = perllocal.pod -exec rm -f '{}' ';' ; \ From nscott@redhat.com Mon Feb 17 03:59:17 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 151557F85 for ; Mon, 17 Feb 2014 03:59:17 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id EBAC2304062 for ; Mon, 17 Feb 2014 01:59:16 -0800 (PST) X-ASG-Debug-ID: 1392631154-04cb6c6de14b3470001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id tRW5HRmAwrrXfaPf for ; Mon, 17 Feb 2014 01:59:15 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1H9xEci005739; Mon, 17 Feb 2014 04:59:14 -0500 Date: Mon, 17 Feb 2014 04:59:14 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: pcp developers Message-ID: <16810357.8275081.1392631154760.JavaMail.zimbra@redhat.com> In-Reply-To: <20140214154657.GB18232@redhat.com> References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> <20140206133220.GC5017@redhat.com> <633105491.21839148.1391757935531.JavaMail.root@redhat.com> <2133757769.21973706.1391772553504.JavaMail.root@redhat.com> <1137677123.6956816.1392357878691.JavaMail.zimbra@redhat.com> <20140214154657.GB18232@redhat.com> Subject: Re: Logged data integrity improvement ideas MIME-Version: 1.0 X-ASG-Orig-Subj: Re: Logged data integrity improvement ideas Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Logged data integrity improvement ideas Thread-Index: JNHgy1K3n0GnVV2GpDOzXQpMBcEeAw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392631155 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145203 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > The new code only fsyncs at archive file close time. That in turns > only affects files that were written-to (because fsync of a read-only > file is a noop). AFAIK, none of our tools append to existing > archives, so I'm not sure what kind of multi-write-pass processing you > are referring to. Yes, none of the tools do this - twas a general API comment, that we should not assume these things have never been done (from some other API user) or will never be done (by either others or ourselves). > > - most modern filesystems perform delayed allocation. If we > > make an assumption about when an appropriate time to flush is, > > we force the filesystems to allocate space early, and this can > > result in less optimal allocation patterns (causing seeks) [...] > > I don't see how this applies. We only fsync at file close, after > which there will be no further allocation. There's no guarantee of that though, and an API should not force it to be that way. Client tools are free to open & close multiple times if it suits them to do so, and it's preferable to offer the option of sync'ing once (or not at all - this is not a one-size-fits-all situation). > > [...] I think the tools are the right place to make these changes, > > and possibly even only via new command line options, for use by the > > daily log rotation regimes. > > Knobs to override it are justifiable (like for that non-tmpfs > intermediate file case), but I suggest defaulting to greater > data-safety rather than less. This is the same default used for > modern text editors, git, and of course databases of all kinds: > they all fsync on close by default. These are not performance analysis tools, which one might be using to study the effects of fsync (or disk access patterns in general, that could be disrupted by increased sync activity). > As to "for daily log rotation", are you suggesting that pmlogger's own > fresh/original output (which has the lowest write volume/rate, thus > the lowest cost for fsync's) ("thus the lowest cost" - this is a bit of an oversimplification FWIW, and is not necessarily an accurate assertion - see below). > should not be considered at least as > precious as the log-merging postprocessors'? Not saying one is more precious than the other, no, but there are tradeoffs to be made and places where we simple cannot practically insert fsync calls ... pmlogger may be sampling multiple times per second, and it may well be doing so during critical points of an analysis. Whereas the daily rotation happens in the middle of the night - ie very infrequently and the time of day favours use of a more widely impacting event. So - we definitely cannot afford to fsync after every single log write. This would make high frequency log writing impossible and/ or inaccurate, and it thwarts those filesystem optimisations I was discussing (delayed allocation for optimal placement, etc). cheers. -- Nathan From nscott@redhat.com Mon Feb 17 04:11:51 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id A559B7F85 for ; Mon, 17 Feb 2014 04:11:51 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 81CA9304059 for ; Mon, 17 Feb 2014 02:11:48 -0800 (PST) X-ASG-Debug-ID: 1392631905-04cb6c6de04b3f80001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id 2kgf6Iork2cTMdMS for ; Mon, 17 Feb 2014 02:11:46 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1HABge1026307; Mon, 17 Feb 2014 05:11:42 -0500 Date: Mon, 17 Feb 2014 05:11:42 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: PCP Mailing List Message-ID: <2061782363.8279608.1392631902639.JavaMail.zimbra@redhat.com> In-Reply-To: <003e01cf2bc0$5430c030$fc924090$@internode.on.net> References: <5301AE27.10007@internode.on.net> <1027442162.8195023.1392625260273.JavaMail.zimbra@redhat.com> <003e01cf2bc0$5430c030$fc924090$@internode.on.net> Subject: Re: [pcp] PCP 3.9.0 install problems MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] PCP 3.9.0 install problems Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: PCP 3.9.0 install problems Thread-Index: AQFbJRHcE92FHiIyUzvJ3odww4uEgwKrp+Erm4vXqrAFoihwGA== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392631906 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145203 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > ... > I cleaned out build/deb/pcp-3.* > > Then Makepkgs > > Then ... > > kenj@bozo-laptop:~/src/pcp$ !find > find . -name perllocal.pod > ./build/deb/pcp-3.9.0/debian/libpcp-mmv-perl/usr/lib/perl/5.14/perllocal.pod > ./build/deb/pcp-3.9.0/debian/libpcp-import-perl/usr/lib/perl/5.14/perllocal.pod > ./build/deb/pcp-3.9.0/debian/libpcp-logsummary-perl/usr/lib/perl/5.14/perllocal.pod > ./build/deb/pcp-3.9.0/debian/libpcp-pmda-perl/usr/lib/perl/5.14/perllocal.pod > > So something in the Perl packaging has come unglued, ... again. Sigh. > > And there are multiple references to perllocal.pod in the code base ... Hmm, I don't remember any of these things ... not sure who hacked on this, may have been Max - he might know more details. > kenj@bozo-laptop:~/src/pcp$ grep -r perllocal . > [./build ones deleted] > ./Logs/pcp:Appending installation info to > /home/kenj/src/pcp/build/deb/pcp-3.9.0/debian/libpcp-mmv-perl/usr/lib/perl/5.14/perllocal.pod > ./Logs/pcp:Appending installation info to > /home/kenj/src/pcp/build/deb/pcp-3.9.0/debian/libpcp-pmda-perl/usr/lib/perl/5.14/perllocal.pod > ./Logs/pcp:Appending installation info to > /home/kenj/src/pcp/build/deb/pcp-3.9.0/debian/libpcp-import-perl/usr/lib/perl/5.14/perllocal.pod > ./Logs/pcp:Appending installation info to > /home/kenj/src/pcp/build/deb/pcp-3.9.0/debian/libpcp-logsummary-perl/usr/lib/perl/5.14/perllocal.pod > ./src/include/builddefs: find $$DIST_ROOT/$(PERL_INSTALL_BASE) -name > perllocal.pod -exec rm -f '{}' ';' ; \ > ./src/include/builddefs: find $$DIST_ROOT/$(PERL_INSTALL_BASE) -name > perllocal.pod -exec rm -f '{}' ';' ; \ > ./src/include/builddefs.in: find $$DIST_ROOT/$(PERL_INSTALL_BASE) -name > perllocal.pod -exec rm -f '{}' ';' ; \ > ./src/include/builddefs.in: find $$DIST_ROOT/$(PERL_INSTALL_BASE) -name > perllocal.pod -exec rm -f '{}' ';' ; \ > These last few are quite interesting - they'd seem to be proving ineffective in your case. No idea where they came from, I don't remember adding 'em in with the original perl packaging work (but, twas back years now). I guess "usr/lib/perl/5.14" != $(PERL_INSTALL_BASE) above. It seems to be coming from the MakeMaker perl module, and this little reference: http://www.perlmonks.org/index.pl?node=ExtUtils%3A%3AMakeMaker has the clue "This feature can be bypassed by calling make pure_install" - that might be worth a shot, e.g. ... diff --git a/src/perl/LogImport/GNUmakefile b/src/perl/LogImport/GNUmakefile index 24b3657..d7b4dec 100644 --- a/src/perl/LogImport/GNUmakefile +++ b/src/perl/LogImport/GNUmakefile @@ -63,7 +63,7 @@ ifneq "$(PACKAGE_DISTRIBUTION)" "debian" endif install_perl: - $(PERLMAKE) -f Makefile install $(INSTALLER_OPTIONS) + $(PERLMAKE) -f Makefile pure_install $(INSTALLER_OPTIONS) default_pcp: default cheers. -- Nathan From fche@redhat.com Mon Feb 17 09:12:41 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C38D37F8C for ; Mon, 17 Feb 2014 09:12:41 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 61F0AAC00A for ; Mon, 17 Feb 2014 07:12:41 -0800 (PST) X-ASG-Debug-ID: 1392649957-04bdf00fc398440001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id nBZ5CIKQSumdFfhO for ; Mon, 17 Feb 2014 07:12:37 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1HFCTN2001020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Feb 2014 10:12:29 -0500 Received: from fche.csb (vpn-235-28.phx2.redhat.com [10.3.235.28]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1HFCTv0024311; Mon, 17 Feb 2014 10:12:29 -0500 Received: by fche.csb (Postfix, from userid 2569) id 6CEA858110; Mon, 17 Feb 2014 10:12:28 -0500 (EST) To: Ken McDonell Cc: pcp@oss.sgi.com Subject: Re: pcp updates - mostly pmie References: <5301AE80.6060703@internode.on.net> X-ASG-Orig-Subj: Re: pcp updates - mostly pmie From: fche@redhat.com (Frank Ch. Eigler) Date: Mon, 17 Feb 2014 10:12:28 -0500 In-Reply-To: <5301AE80.6060703@internode.on.net> (Ken McDonell's message of "Mon, 17 Feb 2014 17:38:56 +1100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392649957 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Ken McDonell writes: > [...] > pmwebd and pmmgr ... terser start up messages > > To be consistent with other PCP bits-n-bobs, we've been using terser > messages from the init scripts, so this commit changes > > Performance Co-Pilot starting pmwebd (logfile is /var/log/pcp/pmwebd/pmwebd.log) ... > and > Performance Co-Pilot starting pmmgr (logfile is /var/log/pcp/pmmgr/pmmgr.log) ... > > to become > Starting pmwebd ... > and > Starting pmmgr ... I find the logfile names useful in that context; perhaps the other programs can be made consistent with that instead? - FChE From fche@redhat.com Mon Feb 17 10:05:36 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 1A5A07F5F for ; Mon, 17 Feb 2014 10:05:36 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 85023AC007 for ; Mon, 17 Feb 2014 08:05:32 -0800 (PST) X-ASG-Debug-ID: 1392653131-04cbb00c2b4ce010001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 5OUkY4E6sAwsRff9 for ; Mon, 17 Feb 2014 08:05:31 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1HG5UN5029423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Feb 2014 11:05:30 -0500 Received: from fche.csb (vpn-235-28.phx2.redhat.com [10.3.235.28]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1HG5Uc2013887; Mon, 17 Feb 2014 11:05:30 -0500 Received: by fche.csb (Postfix, from userid 2569) id 9316D5811A; Mon, 17 Feb 2014 11:05:29 -0500 (EST) Date: Mon, 17 Feb 2014 11:05:29 -0500 From: "Frank Ch. Eigler" To: Nathan Scott Cc: pcp developers Subject: Re: Logged data integrity improvement ideas Message-ID: <20140217160529.GE18232@redhat.com> X-ASG-Orig-Subj: Re: Logged data integrity improvement ideas References: <2108905700.15892281.1391033827018.JavaMail.root@redhat.com> <1557539857.20737008.1391680756568.JavaMail.root@redhat.com> <20140206133220.GC5017@redhat.com> <633105491.21839148.1391757935531.JavaMail.root@redhat.com> <2133757769.21973706.1391772553504.JavaMail.root@redhat.com> <1137677123.6956816.1392357878691.JavaMail.zimbra@redhat.com> <20140214154657.GB18232@redhat.com> <16810357.8275081.1392631154760.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16810357.8275081.1392631154760.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392653131 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - > > [...] AFAIK, none of our tools append to existing archives, so > > I'm not sure what kind of multi-write-pass processing you are > > referring to. > Yes, none of the tools do this - twas a general API comment, that we > should not assume these things have never been done (from some other > API user) or will never be done (by either others or ourselves). > [...] > There's no guarantee of that though, and an API should not force it > to be that way. Client tools are free to open & close multiple > times [...] The API does not support opening an existing archive for writing/appending. None of our tools do it. We haven't heard of tools that do it, never mind hearing that they would be unacceptably affected by fsync-on-close. Let's not worry about it. The day the API is extended and/or suchly-troubled tools appear, we can fit in flushing-control parameters. Or even then, the PCP_NO_FSYNC environment variable (coming soon to fche/dev) may satisfy them. > > [...] I suggest defaulting to greater data-safety rather than > > less. This is the same default used for modern text editors, git, > > and of course databases of all kinds: they all fsync on close by > > default. > > These are not performance analysis tools, which one might be using > to study the effects of fsync (or disk access patterns in general, > that could be disrupted by increased sync activity). If a system is hypersensitive to I/O, it should not be running a pmlogger at all, and should be remotely logged instead. If a sysadmin is trying to analyze pmlogger's own impact, then including any data-safety measures in that impact is entirely appropriate. > > As to "for daily log rotation", are you suggesting that pmlogger's own > > fresh/original output (which has the lowest write volume/rate, thus > > the lowest cost for fsync's) > > ("thus the lowest cost" - this is a bit of an oversimplification > FWIW, and is not necessarily an accurate assertion - see below). I didn't see any contradiction. If you're referring to a pmlogger many-samples-per-second scenario, it would have to be something that: a) runs pmlogger at a high data rate (contrast with the normal default of some 8000 bytes once a minute, something even a floppy disk can hack) b) stores pmlogger data locally (or else disk i/o issues are irrelevant), but any background disk flushing traffic is not a problem during this critical performance period c) considers the CPU/network load imposed by the high-data-rate polling of local pmcd as not a problem either during this critical performance period d) causes a large quantity of pmlogger output to be buffered by the kernel (or else fsyncing it wouldn't be a problem), but this memory consumption is not a problem either during this performance critical period e) must quit pmlogger during the critical performance period, so as to trigger the controversial fsync-on-close. (Note again that no one here has advocated having pmlogger issue an fsync for every log record write.) I don't see how all of a..e can hold in a sensible situation. - FChE From fche@redhat.com Mon Feb 17 10:41:26 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 279BA7F8C for ; Mon, 17 Feb 2014 10:41:26 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0FA3E8F8039 for ; Mon, 17 Feb 2014 08:41:22 -0800 (PST) X-ASG-Debug-ID: 1392655281-04cb6c06cf1c1af0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id TeonRIdFTRLAuqtt for ; Mon, 17 Feb 2014 08:41:22 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1HGfJYi032614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Feb 2014 11:41:20 -0500 Received: from fche.csb (vpn-235-28.phx2.redhat.com [10.3.235.28]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1HGfHul012622; Mon, 17 Feb 2014 11:41:19 -0500 Received: by fche.csb (Postfix, from userid 2569) id 978FA58664; Mon, 17 Feb 2014 11:41:16 -0500 (EST) To: Nathan Scott Cc: PCP Subject: Re: pcp updates: pmdalinux vs valgrind vs s390x, packaging split References: <964461579.6117843.1392277555477.JavaMail.zimbra@redhat.com> <1116704166.6120773.1392277652694.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: pcp updates: pmdalinux vs valgrind vs s390x, packaging split From: fche@redhat.com (Frank Ch. Eigler) Date: Mon, 17 Feb 2014 11:41:16 -0500 In-Reply-To: <1116704166.6120773.1392277652694.JavaMail.zimbra@redhat.com> (Nathan Scott's message of "Thu, 13 Feb 2014 02:47:32 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392655281 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - > [...] > commit 1d7cbdeb246410ffba4d48570fce21d0b2168484 > Author: Nathan Scott > Date: Thu Feb 13 14:46:27 2014 +1100 > > Packaging changes to support pcp-manager and pcp-webapi split > > Migrate pmmgr(1) and pmwebd(1) daemons into their own packages. > This allows for independent development on pmmgr and potentially > aggressive enablement of new features there, This is unfortunate. > as well as removing the (non-default install) libmicrohttpd > dependency from the core PCP packages. Surely disk space concerns don't arise from a 95 kilobyte shared library (libmicrohttpd), and a 41 kilobyte binary (pmwebd); surely security concerns don't arise as pmwebd should not be started by default; so what is the problem? - FChE From brolley@redhat.com Mon Feb 17 10:47:55 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 632AB7F8C for ; Mon, 17 Feb 2014 10:47:55 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 3C17E304039 for ; Mon, 17 Feb 2014 08:47:52 -0800 (PST) X-ASG-Debug-ID: 1392655670-04bdf00fc3a2cf0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id JOLC895fKVGSs8S9 for ; Mon, 17 Feb 2014 08:47:51 -0800 (PST) X-Barracuda-Envelope-From: brolley@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1HGln2G005950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 17 Feb 2014 11:47:49 -0500 Received: from [10.10.54.119] (vpn-54-119.rdu2.redhat.com [10.10.54.119]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1HGllaw006391 for ; Mon, 17 Feb 2014 11:47:47 -0500 Message-ID: <53023D4E.1060504@redhat.com> Date: Mon, 17 Feb 2014 11:48:14 -0500 From: Dave Brolley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc References: <52FE5058.4030702@redhat.com> X-ASG-Orig-Subj: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc In-Reply-To: <52FE5058.4030702@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392655671 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On 02/14/2014 12:20 PM, Dave Brolley wrote: > There is still one outstanding problem which is affecting quite a few > tests (039 046 053 085 161 178 234 242 248 304 352 354 466 524 593 > 650). The problem occurs when pmlogger is running as a normal user. In > that case, pmlogger is unable to bind to (i.e. create) the unix domain > socket in /var/run/pcp because that directory is not writable by > normal users (drwxrwxr-x. 2 pcp pcp). Perhaps another location in that > case? The commit below handles this ... (pcpfans brolley/dev) commit 3685cfa7480a900e6df591762cd79a06467204ac Author: Dave Brolley Date: Mon Feb 17 11:37:53 2014 -0500 Handle unix domain socket binding (creation) for pmlogger when run as a normal user. When running as a normal user, pmlogger is unable to bind to (i.e. create) a unix domain socket in /var/run/pcp (PCP_RUN_DIR), because that directory is not writable by normal users. This change handles the situation in a similar way to how the port map file in /var/lib/pcp/tmp/pmlogger (PCP_TMP_DIR)/pmlogger is handled, which is to continue on and to issue a message only if DESPARATE is defined at compile time. This solution is reasonable, since pmlogger will go on to create inet and ipv6 sockets for control connections. Only if all sockets fail to bind is this a critical error. This addresses the regression of qa tests 039 046 053 085 161 178 234 242 248 304 352 354 466 524 593 and 650. From kenj@internode.on.net Mon Feb 17 13:54:52 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 1FD6C7F9E for ; Mon, 17 Feb 2014 13:54:52 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id A692EAC004 for ; Mon, 17 Feb 2014 11:54:48 -0800 (PST) X-ASG-Debug-ID: 1392666884-04bdf00fc3b6eb0001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id Z9yglhx1Npa1VQPH for ; Mon, 17 Feb 2014 11:54:44 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYZADNoAlN20YajPGdsb2JhbAANTItRuAGBNwMBAQEBOIJaAQEBBDhAARALGAkWDwkDAgECATEUBg0BBQIBAa9xol0XjwEHhDgBA64Q Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail04.adl6.internode.on.net with ESMTP; 18 Feb 2014 06:24:44 +1030 Message-ID: <5302691A.9090100@internode.on.net> Date: Tue, 18 Feb 2014 06:55:06 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: pcp@oss.sgi.com Subject: Re: pcp updates - mostly pmie References: <5301AE80.6060703@internode.on.net> X-ASG-Orig-Subj: Re: pcp updates - mostly pmie In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1392666884 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header On 18/02/14 02:12, Frank Ch. Eigler wrote: > Ken McDonell writes: > >> [...] >> Performance Co-Pilot starting pmwebd (logfile is /var/log/pcp/pmwebd/pmwebd.log) ... >> and >> Performance Co-Pilot starting pmmgr (logfile is /var/log/pcp/pmmgr/pmmgr.log) ... >> >> to become >> Starting pmwebd ... >> and >> Starting pmmgr ... > > I find the logfile names useful in that context; perhaps the other > programs can be made consistent with that instead? I don't have a strong preference. I (weakly) favour the terse format on the basis that the vast majority of users don't care, and the few that do already know that pmwebd and pmmgr are part of Performance Co-Pilot and know where to find the log files. Let's decide (not sure how) and be consistent ... if the long format wins, we have to revert commits from the Jurassic period for some of the init scripts. From fche@redhat.com Mon Feb 17 14:05:11 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6F4647F9E for ; Mon, 17 Feb 2014 14:05:11 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 49DB48F804C for ; Mon, 17 Feb 2014 12:05:08 -0800 (PST) X-ASG-Debug-ID: 1392667507-04bdf00fcab7f80001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id SPfLdbeXSGwZ70am for ; Mon, 17 Feb 2014 12:05:07 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1HK4wFW006700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Feb 2014 15:04:58 -0500 Received: from fche.csb (vpn-235-28.phx2.redhat.com [10.3.235.28]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1HK4vpJ004913; Mon, 17 Feb 2014 15:04:57 -0500 Received: by fche.csb (Postfix, from userid 2569) id A74A658664; Mon, 17 Feb 2014 15:04:56 -0500 (EST) Date: Mon, 17 Feb 2014 15:04:56 -0500 From: "Frank Ch. Eigler" To: Ken McDonell Cc: pcp@oss.sgi.com Subject: Re: pcp updates - mostly pmie Message-ID: <20140217200456.GF18232@redhat.com> X-ASG-Orig-Subj: Re: pcp updates - mostly pmie References: <5301AE80.6060703@internode.on.net> <5302691A.9090100@internode.on.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5302691A.9090100@internode.on.net> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392667507 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi, Ken - > >I find the logfile names useful in that context; perhaps the other > >programs can be made consistent with that instead? > > I don't have a strong preference. Likewise. > I (weakly) favour the terse format on the basis that the vast > majority of users don't care, and the few that do already know that > pmwebd and pmmgr are part of Performance Co-Pilot (Yeah, the "Performance Co-Pilot" string could be elided or abbreviated.) > and know where to find the log files. Probably (though we're about to get an influx of new users). > Let's decide (not sure how) [...] Have a coin? I call tails. :-) - FChE From kenj@internode.on.net Mon Feb 17 14:08:28 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id E584B7F9E for ; Mon, 17 Feb 2014 14:08:28 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id CE5C58F804C for ; Mon, 17 Feb 2014 12:08:28 -0800 (PST) X-ASG-Debug-ID: 1392667703-04cb6c6de04ec7e0001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id EGeLjgnFBLeA8MQW for ; Mon, 17 Feb 2014 12:08:23 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssZAN9rAlN20YajPGdsb2JhbAANTItRtHiDCoE3AwEBAQE4gloBAQEDAThAARALGAkWDwkDAgECATEUBg0BBwEBh3mndaJfF48BB4Q4AQOuEA Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail04.adl6.internode.on.net with ESMTP; 18 Feb 2014 06:38:07 +1030 Message-ID: <53026C3E.3080800@internode.on.net> Date: Tue, 18 Feb 2014 07:08:30 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: pcp@oss.sgi.com Subject: Re: pcp updates - mostly pmie References: <5301AE80.6060703@internode.on.net> <5302691A.9090100@internode.on.net> <20140217200456.GF18232@redhat.com> X-ASG-Orig-Subj: Re: pcp updates - mostly pmie In-Reply-To: <20140217200456.GF18232@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1392667703 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145217 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header On 18/02/14 07:04, Frank Ch. Eigler wrote: > .. > Probably (though we're about to get an influx of new users). I'd bet most of 'em are will be in the "don't care" camp, at least for this level of detail. >> Let's decide (not sure how) [...] > > Have a coin? I call tails. :-) I call heads ... I think we need more than 2 voters ... 8^)> From nscott@redhat.com Mon Feb 17 14:55:53 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 6CD387FA3 for ; Mon, 17 Feb 2014 14:55:53 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 3432E304059 for ; Mon, 17 Feb 2014 12:55:53 -0800 (PST) X-ASG-Debug-ID: 1392670551-04bdf00fcabca80001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id P91At0RdAJquHyiH for ; Mon, 17 Feb 2014 12:55:51 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1HKtoAd031829; Mon, 17 Feb 2014 15:55:50 -0500 Date: Mon, 17 Feb 2014 15:55:50 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: PCP Message-ID: <1906681228.8849447.1392670550462.JavaMail.zimbra@redhat.com> In-Reply-To: References: <964461579.6117843.1392277555477.JavaMail.zimbra@redhat.com> <1116704166.6120773.1392277652694.JavaMail.zimbra@redhat.com> Subject: Re: pcp updates: pmdalinux vs valgrind vs s390x, packaging split MIME-Version: 1.0 X-ASG-Orig-Subj: Re: pcp updates: pmdalinux vs valgrind vs s390x, packaging split Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: pmdalinux vs valgrind vs s390x, packaging split Thread-Index: 7NrJO/Lc3L62h8qfHU0Ad3FfBrusWw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392670551 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > > Hi - > > > [...] > > commit 1d7cbdeb246410ffba4d48570fce21d0b2168484 > > Author: Nathan Scott > > Date: Thu Feb 13 14:46:27 2014 +1100 > > > > Packaging changes to support pcp-manager and pcp-webapi split > > > > Migrate pmmgr(1) and pmwebd(1) daemons into their own packages. > > This allows for independent development on pmmgr and potentially > > aggressive enablement of new features there, > > This is unfortunate. > Having made this change, I'm wishing we did it earlier - it's a good thing. (How many other packages have *7* init scripts and counting?) Other than helping resolve potential administrative conflicts, it has clear advantages like being tagged as a more experimental package. We *could* also choose to enable the daemon by default here at some point, which we can never do in the base RPM. And its makes good security sense - people should be able to install a minimal set of daemons, even if they are off by default - many sysadmins I've come across just don't want unused daemons there at all where possible. > > > as well as removing the (non-default install) libmicrohttpd > > dependency from the core PCP packages. > > Surely disk space concerns don't arise from a 95 kilobyte shared > library (libmicrohttpd), and a 41 kilobyte binary (pmwebd); surely > security concerns don't arise as pmwebd should not be started by > default; so what is the problem? There have been complaints about pulling in libmicrohttpd, which is a non-default package. Plus, the too-many-optional-daemons points. cheers. -- Nathan From nscott@redhat.com Mon Feb 17 15:05:39 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B73E87FA3 for ; Mon, 17 Feb 2014 15:05:39 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 9F15C8F8059 for ; Mon, 17 Feb 2014 13:05:36 -0800 (PST) X-ASG-Debug-ID: 1392671132-04cbb00c2a4ed4a0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id AdKS9C7vRQ0jmQmL for ; Mon, 17 Feb 2014 13:05:32 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1HL5OOw018418; Mon, 17 Feb 2014 16:05:24 -0500 Date: Mon, 17 Feb 2014 16:05:24 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell , "Frank Ch. Eigler" Cc: pcp@oss.sgi.com Message-ID: <1280806700.8858397.1392671124175.JavaMail.zimbra@redhat.com> In-Reply-To: <53026C3E.3080800@internode.on.net> References: <5301AE80.6060703@internode.on.net> <5302691A.9090100@internode.on.net> <20140217200456.GF18232@redhat.com> <53026C3E.3080800@internode.on.net> Subject: Re: [pcp] pcp updates - mostly pmie MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pcp updates - mostly pmie Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates - mostly pmie Thread-Index: QqUSLHp3L7kZeIvrIPYHIxeBpS2ypw== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392671132 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > On 18/02/14 07:04, Frank Ch. Eigler wrote: > > .. > > Probably (though we're about to get an influx of new users). > > I'd bet most of 'em are will be in the "don't care" camp, at least for > this level of detail. > > >> Let's decide (not sure how) [...] > > > > Have a coin? I call tails. :-) > > I call heads ... I think we need more than 2 voters ... 8^)> > I think explicitly listing the log file is useful to new punters. cheers. -- Nathan From kenj@internode.on.net Mon Feb 17 15:59:42 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 554C97F92 for ; Mon, 17 Feb 2014 15:59:42 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 269138F8052 for ; Mon, 17 Feb 2014 13:59:42 -0800 (PST) X-ASG-Debug-ID: 1392674379-04cbb00c284f13b0001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id AwGUANFslz0ZTgBL for ; Mon, 17 Feb 2014 13:59:40 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEZAOGFAlN20YajPGdsb2JhbAANTIcXhDq1BIMKgTgDAQEBATiCWgEBAQQjFUABEAsYAgIFFgsCAgkDAgECATEUBg0BBwEBr252oWkXgSmNWAeCb4FJAQOuEA Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail04.adl6.internode.on.net with ESMTP; 18 Feb 2014 08:29:39 +1030 Message-ID: <53028662.4090707@internode.on.net> Date: Tue, 18 Feb 2014 09:00:02 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Scott CC: PCP Mailing List Subject: Re: [pcp] PCP 3.9.0 install problems References: <5301AE27.10007@internode.on.net> <1027442162.8195023.1392625260273.JavaMail.zimbra@redhat.com> <003e01cf2bc0$5430c030$fc924090$@internode.on.net> <2061782363.8279608.1392631902639.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] PCP 3.9.0 install problems In-Reply-To: <2061782363.8279608.1392631902639.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1392674379 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145220 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 17/02/14 21:11, Nathan Scott wrote: > ... > These last few are quite interesting - they'd seem to be proving ineffective > in your case. No idea where they came from, I don't remember adding 'em in > with the original perl packaging work (but, twas back years now). Digging a little deeper it is the creation, not the removal that is a difference between an failing and OK debian packaging run. The lines like .. Appending installation info to /home/kenj/src/pcp/build/deb/pcp-3.9.0/debian/libpcp-mmv-perl/usr/lib/perl/5.14/perllocal.pod are not in the good build. These lines come from the generated Perl Makefiles in both cases ... but the Makefiles are not the same and "make -f Makefile install" produces different output in the two cases. I'll try pure_install instead of install later. From nscott@redhat.com Mon Feb 17 21:26:49 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 9EFC57FB1 for ; Mon, 17 Feb 2014 21:26:49 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7FE2E304062 for ; Mon, 17 Feb 2014 19:26:49 -0800 (PST) X-ASG-Debug-ID: 1392694003-04cb6c6de05093c0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id EWC8TfnZL9xe5CcI for ; Mon, 17 Feb 2014 19:26:43 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1I3QhbG008928 for ; Mon, 17 Feb 2014 22:26:43 -0500 Date: Mon, 17 Feb 2014 22:26:43 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp@oss.sgi.com Message-ID: <1559797799.8991971.1392694003092.JavaMail.zimbra@redhat.com> In-Reply-To: <1701855979.8991888.1392693922381.JavaMail.zimbra@redhat.com> Subject: pcp updates: fche, kenj, nathans merges - pmmgr, pmie, qa MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: fche, kenj, nathans merges - pmmgr, pmie, qa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: fche, kenj, nathans merges - pmmgr, pmie, qa Thread-Index: +k5JrhHFJWeUM3YW2ifYRYdgv5Q8Kg== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392694003 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145231 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev CHANGELOG | 30=20 build/rpm/fedora.spec | 11=20 build/rpm/pcp.spec.in | 9=20 debian/changelog | 2=20 man/man1/pmmgr.1 | 44=20 qa/.gitignore | 2=20 qa/115 | 4=20 qa/115.out | 1=20 qa/228 | 16=20 qa/321 | 1=20 qa/514 | 7=20 qa/514.out.3 | 2438 ++++++++++++++++++++++++++++++++++++++= +++++ qa/520 | 7=20 qa/520.out.3 | 597 ++++++++++ qa/523 | 17=20 qa/523.out | 14=20 qa/523.out.1 | 497 ++++++++ qa/523.out.2 | 499 ++++++++ qa/733 | 17=20 qa/733.out | 1=20 qa/733.out.1 | 239 ++++ qa/733.out.2 | 240 ++++ qa/815 | 32=20 qa/815.out | 12=20 qa/GNUmakefile | 2=20 qa/common.filter | 1=20 qa/group | 1=20 src/libpcp_pmda/src/tree.c | 55=20 src/pmie/src/fetch.sk | 9=20 src/pmie/src/meta | 4=20 src/pmie/src/pmie.c | 2=20 src/pmmgr/TODO | 12=20 src/pmmgr/config/GNUmakefile | 2=20 src/pmmgr/pmmgr.cxx | 412 ++++--- src/pmmgr/pmmgr.h | 1=20 src/pmmgr/rc_pmmgr | 2=20 src/pmwebapi/rc_pmwebd | 2=20 37 files changed, 5020 insertions(+), 222 deletions(-) commit c3cc4a5d8d27a66f5515b5e18b1d4a883429fbc6 Author: Nathan Scott Date: Tue Feb 18 14:22:36 2014 +1100 Updates to the changelog for upcoming release commit 9059d67d68ed31272f4bf76d8868481185b0670a Merge: fc724d8 c8c1a0c Author: Nathan Scott Date: Tue Feb 18 13:50:59 2014 +1100 Merge branch 'dev' of git://oss.sgi.com/kenj/pcp into dev commit fc724d844c845eb85f60627fd45f5e0161312d82 Author: Frank Ch. Eigler Date: Mon Feb 17 18:30:18 2014 -0500 pmmgr signal handling: don't need to propagate signals to process group= any more =20 The new wrap_system() does the job adequately. commit 4449933b4d2c45ce0a21e330bfa5bca758bc02db Author: Frank Ch. Eigler Date: Mon Feb 17 16:44:46 2014 -0500 pmmgr: improve responsivity to incoming signals =20 This is done by an open-coded wrapper that acts like system(3), except it cooperates with the main process' signal handling scheme. commit 70a59cacb6e572986d898b1838facfb1c6242b2d Author: Frank Ch. Eigler Date: Sun Feb 16 11:54:50 2014 -0500 pmmgr signal-response improvements, part 1: respond to quit!=3D0 quicke= r =20 Add checks between timetaking operations for an early return/exit in case of a pending interrupt (quit !=3D 0). commit 7cbb25fb1f406671f31d6e4990cf63d6cdff804a Author: Frank Ch. Eigler Date: Sat Feb 15 18:35:03 2014 -0500 pmmgr: tweak pmlogrewrite operations to occur just before merges, only = on their inputs commit bc8a0b6cfb115ab6141950c783cd7ab1fc00c231 Author: Frank Ch. Eigler Date: Sat Feb 15 16:23:03 2014 -0500 pmmgr TODO: add some commit 7bde35210d8f1e6b9d847f99e42176d506032387 Author: Frank Ch. Eigler Date: Fri Feb 14 15:37:26 2014 -0500 pmmgr.1: note that -v generates stdout traffic, not stderr commit 7135019376a30d82323e9612611df0ba4cd9e845 Author: Frank Ch. Eigler Date: Fri Feb 14 14:38:27 2014 -0500 pmmgr: add pmlogmerge-granular mode =20 This mode tweaks log management to optionally operate on a granular basis, that is to merge only archives belonging to a recent past time grain. Archives belonging to the current time grain are left alone (for merging once, at the next one), and archives belonging to long-previous time grains are left alone. =20 The overall effect can approximate the pmlogger_daily type of log rotation, but time grains of any other size may be chosen via the pmlogmerge control file's contents. =20 This mode is made default for new installations by the presence of a pmlogmerge-granular control file. =20 Garbage collection is enhanced to catch even corrupt old archives, based upon the pmlogmerge-retain control file. commit 3d64385188560aa3a26cdcf99e1d61fb34f3d845 Author: Nathan Scott Date: Tue Feb 18 13:13:18 2014 +1100 More work bullet-proofing the libpcp_pmda dynamic tree code =20 Deal with NULL calls coming into the API in several more places, add recoverable error handling on hash rebuild calloc failure. commit b66986f2b037803002fc470be12d05b41075a332 Author: Nathan Scott Date: Tue Feb 18 11:19:48 2014 +1100 More testing of cases from Milo=C5=A1 and a final take on pcpqa user se= tup =20 Further combinations of existing system state (in terms of which dirs already exist and which do not) uncovered further pcpqa account setup issues. We now take the -M approach of not having useradd create our homedir, just as we do for the pcp account, knowing installation will be creating it for us (take that responsibility away from useradd). =20 Resolves Red Hat bug #1025688. commit c8c1a0ce13dcf307314a5bfeb7bb9471154a3fda Author: Ken McDonell Date: Mon Feb 17 16:18:33 2014 +1100 pmie - another day one bug, this time in count_* operators =20 The operand of the count_inst, count_host and count_sample operators is a logical expression. =20 If the expression is set values (multiple instances for count_inst, multiple hosts for count_host, etc), then the code did not check for the tri-state value of UNKNOWN (or DUNNO internally), rather it added the values assuming 0 for FALSE and 1 for TRUE ... DUNNO is 2 which explains why the result was TWICE the size of the instance domain if the expressions was undefined over and instance domain. =20 Part 2 of the bug Chandana de Silva discovered with this simple pmie rule: count_inst( match_inst "httpd" proc.psinfo.pid > 0) > 0 =09-> print "count %v"; that reported 6 most of the time, and sometimes reported 1400+ =20 qa/815 now exercises something similar. commit 82ab0b5504648e8cfd5fa42958af5cbbbf38875d Author: Ken McDonell Date: Mon Feb 17 16:12:35 2014 +1100 qa/733 - updated output after pmie bug fix =20 Seeing some more results with defined values after the first fetch. commit ea2c1769470715e182e53c1dee5f09ac21dd39b4 Author: Ken McDonell Date: Mon Feb 17 16:03:59 2014 +1100 qa/523 - updated output after pmie bug fix =20 Seeing some more results with defined values after the first fetch. commit 7d41f28d952fe4f8a3cc8c4fc8afe11e12d15ba8 Author: Ken McDonell Date: Mon Feb 17 16:02:11 2014 +1100 qa/520 - updated output after pmie bug fix =20 Seeing some more results with defined values after the first fetch. commit 10c792f36296a10ddcd2c13bbbb43af0df4bf8b1 Author: Ken McDonell Date: Mon Feb 17 15:55:19 2014 +1100 qa/514 - updated output after pmie bug fix =20 Seeing some more results with defined values after the first fetch. commit d1dfe14b083f9730f5cbd973a6764dabcb953d65 Author: Ken McDonell Date: Mon Feb 17 15:46:17 2014 +1100 pmie - day one bug in fetch logic =20 On the first fetch and the fetch after a dynamic instance domain has changed membership, the values may have been incorrectly marked as "not valid", preventing rules being evaluated correctly. =20 Part 1 of the bug Chandana de Silva discovered with this simple pmie rule: count_inst( match_inst "httpd" proc.psinfo.pid > 0) > 0 =09-> print "count %v"; that reported 6 most of the time, and sometimes reported 1400+ commit 1b883a0ca8bb91fe675973a2ed21760f7cb7b72a Author: Ken McDonell Date: Mon Feb 17 14:57:32 2014 +1100 qa/321 - dodge permission issue =20 "... warning cannot create stats file dir ..." message still appearing after pmie change to quieten this because we're using pmie -v here. =20 Filter these lines out. commit 6717436693b165a1a5401d3577e078a2a5aa0cc8 Author: Ken McDonell Date: Mon Feb 17 14:47:24 2014 +1100 pmie - quieten warning after tmp dir perms change =20 After recent changes to the mode and ownership of the $PCP_VAR_DIR/tmp directory, the message "... warning cannot create stats file dir ..." may be emitted each time pmie is run as a user other than "pcp". =20 This happens a LOT in QA. =20 Since the message is only a warning, and the only side-effect is that the pmie process is not visible in the instance domain of the pmcd.pmie metrics (it is likely that no one but kenj cares!), I've suppressed the message unless one of the pmie verbose flags is set (-v, -V or -W). commit 292d0374f4702db6225223b96bfb74fc9850e250 Author: Ken McDonell Date: Mon Feb 17 14:45:29 2014 +1100 qa/228 - dodge permission issue =20 "... warning cannot create stats file dir ..." message still appearing after pmie change to quieten this because we're using pmie -v here. =20 Filter these lines out. commit 017ec17ff3563047bb92806d69b0a9a1cfc38fbd Author: Ken McDonell Date: Mon Feb 17 14:41:22 2014 +1100 qa/115 - non-determinism in pmie stop init script =20 The message "...: PMIE not running" may or may not be there ... add filter and strip from expected output commit 0f0ba77214193f6a415365e9ee2db2a53a6e8a6d Author: Ken McDonell Date: Mon Feb 17 14:39:11 2014 +1100 qa/815 [new] - tickle pmie bug =20 pmie bug in count_ method when boolean expression is UNKNOWN ... thanks to Chandana de Silva for pointing out the example that showed this. commit 421b195fc4197eda0c5a93488f9e6c1681186cb4 Author: Ken McDonell Date: Mon Feb 17 14:35:49 2014 +1100 qa/common.filter - strip blank lines from pmie init script output =20 Recent changes to the pmie init scripts seem to have introduced the possibility of blank lines being output ... make 'em go away so we don't get unwanted QA failures. =20 Example blank line output ... <---- HERE /etc/init.d/pmie: Warning: Performance Co-Pilot Inference Engine (pmie)= is disabled. To enable pmie, run the following as root: =09 update-rc.d -f pmie remove =09 update-rc.d pmie defaults 94 06 commit a3c1beeeca0280efb2a84303fce4603f7815771c Author: Nathan Scott Date: Mon Feb 17 13:54:57 2014 +1100 Do not include the generated qa_outfiles in the source tarball =20 This excluded qa_outfiles (generated list of QA test validated outputs) from the source tarball shipped for each release. The problem that its caused is that patching a tree with a new test results in the test .out file being exluded from pcp-testsuite, since its not included with the original list. =20 Resolves Red Hat bug #1064311. commit 80dced72bc37bf9d00337e01386795cc4845a981 Author: Nathan Scott Date: Mon Feb 17 11:04:05 2014 +1100 Let pcpqa user homedir be created by useradd in rpm packaging =20 There's some evidence to suggest that useradd has refused to create a homedir which the user cannot initially write to. Tackle this by allowing useradd to create the final (basename) component. =20 Tackles Red Hat bug #1025688. commit 4e3bc79318def74c5a2433461942465c6e6b94c5 Author: Ken McDonell Date: Sun Feb 16 16:33:19 2014 +1100 pmwebd and pmmgr ... terser start up messages =20 To be consistent with other PCP bits-n-bobs, we've been using terser messages from the init scripts, so this commit changes =20 Performance Co-Pilot starting pmwebd (logfile is /var/log/pcp/pmwebd/pm= webd.log) ... and Performance Co-Pilot starting pmmgr (logfile is /var/log/pcp/pmmgr/pmmg= r.log) ... =20 to become Starting pmwebd ... and Starting pmmgr ... commit 2e72eb8ea56067bfb8d82fa18cdd80cfdc636f70 Author: Nathan Scott Date: Fri Feb 14 17:46:40 2014 +1100 Update changelog, general release prep for next week From kenj@internode.on.net Mon Feb 17 23:13:09 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E91B17FB5 for ; Mon, 17 Feb 2014 23:13:08 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 916C8AC004 for ; Mon, 17 Feb 2014 21:13:08 -0800 (PST) X-ASG-Debug-ID: 1392700383-04bdf00fcad9bf0001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id vgyh0XNRH6hiWpdC for ; Mon, 17 Feb 2014 21:13:03 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIZAPnqAlN20YajPGdsb2JhbAANTIM+iBO4CIEzAwEBAQE4hAkNNAIyJwYCAQGwEaMTjx6EIgSuEA Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail04.adl6.internode.on.net with ESMTP; 18 Feb 2014 15:43:03 +1030 Message-ID: <5302EBF6.60409@internode.on.net> Date: Tue, 18 Feb 2014 16:13:26 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pcp updates - perl Debian packaging fix Content-Type: text/plain; charset=ISO-8859-1 X-ASG-Orig-Subj: pcp updates - perl Debian packaging fix Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1392700383 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145233 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Changes committed to git://oss.sgi.com/kenj/pcp.git dev src/perl/LogImport/GNUmakefile | 2 +- src/perl/LogSummary/GNUmakefile | 2 +- src/perl/MMV/GNUmakefile | 2 +- src/perl/PMDA/GNUmakefile | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) commit 8d8a3bfc37e8189b8d010027ef3f59fc5160bd7a Author: Ken McDonell Date: Tue Feb 18 16:11:00 2014 +1100 perl install changes - fix Debian packaging issue As per Nathan's suggestion, pure_install seems a safer target than install for the perl generated Makefiles. Tested on both Debian platforms where the old way was passing and failing. From nscott@redhat.com Mon Feb 17 23:45:54 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 630627FB5 for ; Mon, 17 Feb 2014 23:45:54 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 3A875304043 for ; Mon, 17 Feb 2014 21:45:51 -0800 (PST) X-ASG-Debug-ID: 1392702349-04bdf00fcadaff0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id pJ3wedSHJe78mo4r for ; Mon, 17 Feb 2014 21:45:50 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1I5jkmF030672; Tue, 18 Feb 2014 00:45:46 -0500 Date: Tue, 18 Feb 2014 00:45:46 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell , "Frank Ch. Eigler" Cc: pcp@oss.sgi.com Message-ID: <1785451800.9038097.1392702346021.JavaMail.zimbra@redhat.com> In-Reply-To: <1280806700.8858397.1392671124175.JavaMail.zimbra@redhat.com> References: <5301AE80.6060703@internode.on.net> <5302691A.9090100@internode.on.net> <20140217200456.GF18232@redhat.com> <53026C3E.3080800@internode.on.net> <1280806700.8858397.1392671124175.JavaMail.zimbra@redhat.com> Subject: Re: [pcp] pcp updates - mostly pmie MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pcp updates - mostly pmie Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates - mostly pmie Thread-Index: QqUSLHp3L7kZeIvrIPYHIxeBpS2ypwLmDEaU X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392702350 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145233 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > ----- Original Message ----- > > On 18/02/14 07:04, Frank Ch. Eigler wrote: > > > .. > > > Probably (though we're about to get an influx of new users). > > > > I'd bet most of 'em are will be in the "don't care" camp, at least for > > this level of detail. > > > > >> Let's decide (not sure how) [...] > > > > > > Have a coin? I call tails. :-) > > > > I call heads ... I think we need more than 2 voters ... 8^)> > > > > I think explicitly listing the log file is useful to new punters. Having played with the current code a bit, it sure looks neat to have all of our (dazzling array of) daemons starting up with some consistency now... so, bleurgh, I don't particularly care which way either, just make 'em all the same. Punters will learn, its documented *everywhere*, maybe not so much value at boot time too. cheers. -- Nathan From nscott@redhat.com Tue Feb 18 00:24:15 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 052997FB3 for ; Tue, 18 Feb 2014 00:24:15 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 8A918AC006 for ; Mon, 17 Feb 2014 22:24:11 -0800 (PST) X-ASG-Debug-ID: 1392704646-04cb6c06cf1fc5b0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id uTS2SsJJEiuJnjRJ for ; Mon, 17 Feb 2014 22:24:06 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1I6O5cI004556 for ; Tue, 18 Feb 2014 01:24:05 -0500 Date: Tue, 18 Feb 2014 01:24:05 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp@oss.sgi.com Message-ID: <647585882.9045672.1392704645908.JavaMail.zimbra@redhat.com> Subject: pcp updates: perl debs, qa MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: perl debs, qa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: perl debs, qa Thread-Index: lKYbYphUzwCzXeC9sUsC7SGHoDwaaA== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392704646 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145235 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev qa/.gitignore | 2 qa/523.out | 499 ---------------------------------------- qa/733.out | 240 ------------------- src/perl/LogImport/GNUmakefile | 2 src/perl/LogSummary/GNUmakefile | 2 src/perl/MMV/GNUmakefile | 2 src/perl/PMDA/GNUmakefile | 2 7 files changed, 4 insertions(+), 745 deletions(-) commit dec71559ccd1ddb3951fece4d41315b1f66f0965 Author: Nathan Scott Date: Tue Feb 18 17:20:15 2014 +1100 Purge new test outfiles from the tree, they are generated commit 8d8a3bfc37e8189b8d010027ef3f59fc5160bd7a Author: Ken McDonell Date: Tue Feb 18 16:11:00 2014 +1100 perl install changes - fix Debian packaging issue As per Nathan's suggestion, pure_install seems a safer target than install for the perl generated Makefiles. Tested on both Debian platforms where the old way was passing and failing. From fche@redhat.com Tue Feb 18 10:09:43 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 091D47FC0 for ; Tue, 18 Feb 2014 10:09:43 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id E3F44304043 for ; Tue, 18 Feb 2014 08:09:39 -0800 (PST) X-ASG-Debug-ID: 1392739775-04bdf00fc91093a0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id GOfmYJoQWs87BCYT for ; Tue, 18 Feb 2014 08:09:35 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1IG9Z0D028564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Feb 2014 11:09:35 -0500 Received: from fche.csb (vpn-235-28.phx2.redhat.com [10.3.235.28]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1IG9ZNl007903; Tue, 18 Feb 2014 11:09:35 -0500 Received: by fche.csb (Postfix, from userid 2569) id AB86758669; Tue, 18 Feb 2014 11:09:34 -0500 (EST) To: Dave Brolley Cc: pcp@oss.sgi.com Subject: Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> X-ASG-Orig-Subj: Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc From: fche@redhat.com (Frank Ch. Eigler) Date: Tue, 18 Feb 2014 11:09:34 -0500 In-Reply-To: <53023D4E.1060504@redhat.com> (Dave Brolley's message of "Mon, 17 Feb 2014 11:48:14 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392739775 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 brolley wrote: > Handle unix domain socket binding (creation) for pmlogger when run > as a normal user. When running as a normal user, pmlogger is unable > to bind to (i.e. create) a unix domain socket in /var/run/pcp > (PCP_RUN_DIR), because that directory is not writable by normal > users. [... so skip it ...] Another solution would be to bind the socket to another predictable path that is private to the user. It would be desirable let people have personal pmloggers that are just as immune to foul play as system pmloggers will be (once they switch onto authenticated-AF_UNIX-only pmlc). - FChE From edwinmorgan435@gmail.com Tue Feb 18 11:27:39 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,T_DKIM_INVALID autolearn=no version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 69EEF7F52 for ; Tue, 18 Feb 2014 11:27:39 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 09979AC005 for ; Tue, 18 Feb 2014 09:27:35 -0800 (PST) X-ASG-Debug-ID: 1392744453-04cbb00c2953fc20001-S8gJnT Received: from mail-oa0-f66.google.com (mail-oa0-f66.google.com [209.85.219.66]) by cuda.sgi.com with ESMTP id ZqCGROgUTs35qvK9 (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 18 Feb 2014 09:27:34 -0800 (PST) X-Barracuda-Envelope-From: edwinmorgan435@gmail.com X-Barracuda-Apparent-Source-IP: 209.85.219.66 X-Barracuda-IPDD: Level1 [gmail.com/209.85.219.66] Received: by mail-oa0-f66.google.com with SMTP id m1so6696311oag.1 for ; Tue, 18 Feb 2014 09:27:33 -0800 (PST) X-Barracuda-IPDD: Level1 [gmail.com/209.85.219.66] X-Barracuda-IPDD: Level1 [gmail.com/209.85.219.66] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=GPMZ/HIIaYRc8tXQ8Lrr2WQurmp5ue5x9IfQ29ew1tU=; b=h3hQxeNUkmeBhemKJT0YcUAFD77bE8rCutmR5Jp+UFwjngx+hcNFw8hehFhWfBx8fU nKdGMQW+uulWtZrmTtzPs+KSPQqxGWfuVh3br/NvjHSu7VvrbI/fTvdV90V2mMdQ5Xnf bViYsOITUbGcxIKyB6jgTgq3FubCknBmux5EPSSZCzY21inEz4iLb/w0S0fM5VSmMfZ/ JFFm3AsZx4Zw4H+R1I/iirMtJ5iUg90smXKvsUJ2jMgYqXceVFA0KI4CNgzkTjcHRy6k NRBnLQcnb3qyvTDYQ1UdqG6jCF4ES27kVpPcFp4sHNV0jAw935iQ7jrP0I5wNTaXYiAP UzzA== MIME-Version: 1.0 X-Received: by 10.182.33.73 with SMTP id p9mr26573714obi.37.1392742773030; Tue, 18 Feb 2014 08:59:33 -0800 (PST) Sender: edwinmorgan435@gmail.com Received: by 10.76.150.68 with HTTP; Tue, 18 Feb 2014 08:59:32 -0800 (PST) Date: Tue, 18 Feb 2014 18:59:32 +0200 X-Google-Sender-Auth: eZYKYE74hmEzFvnrEb-G2FDfnt4 Message-ID: Subject: reply From: edwin morgan X-ASG-Orig-Subj: reply To: undisclosed-recipients:; Content-Type: multipart/alternative; boundary=047d7b5d58b4403b8904f2b13298 X-Barracuda-Connect: mail-oa0-f66.google.com[209.85.219.66] X-Barracuda-Start-Time: 1392744454 X-Barracuda-Encrypted: RC4-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-BRTS-Evidence: 9a219f9c069180097bc2a20eaa9205f0-244-htm X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145249 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message --047d7b5d58b4403b8904f2b13298 Content-Type: text/plain; charset=ISO-8859-1 Compliments, My name is Mr.Edwin Morgan please I am looking for a profitable business where I can invest some money do reply back to me if you have any idea to share with me. Thanks. Mr.Edwin Morgan --047d7b5d58b4403b8904f2b13298 Content-Type: text/html; charset=ISO-8859-1
Compliments,

My name is Mr.Edwin Morgan please I am looking for a profitable business
where I can invest some money do reply back to me if you have any idea to
share with me.
Thanks.
Mr.Edwin Morgan
--047d7b5d58b4403b8904f2b13298-- From nscott@redhat.com Tue Feb 18 14:04:27 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 3BDF38001 for ; Tue, 18 Feb 2014 14:04:27 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 28418304077 for ; Tue, 18 Feb 2014 12:04:27 -0800 (PST) X-ASG-Debug-ID: 1392753862-04bdf00fc0120610001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id pDGZyI1EFEk088Pp for ; Tue, 18 Feb 2014 12:04:22 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1IK4MLb023127; Tue, 18 Feb 2014 15:04:22 -0500 Date: Tue, 18 Feb 2014 15:04:21 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" , Dave Brolley Cc: pcp@oss.sgi.com Message-ID: <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> In-Reply-To: References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> Subject: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Thread-Index: Cp9QjdpQdDKR7wKqIXT55+Hz0ct42g== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392753862 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145254 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > brolley wrote: > > Handle unix domain socket binding (creation) for pmlogger when run > > as a normal user. When running as a normal user, pmlogger is unable > > to bind to (i.e. create) a unix domain socket in /var/run/pcp > > (PCP_RUN_DIR), because that directory is not writable by normal > > users. [... so skip it ...] > > Another solution would be to bind the socket to another predictable > path that is private to the user. It would be desirable let people > have personal pmloggers that are just as immune to foul play as system > pmloggers will be (once they switch onto authenticated-AF_UNIX-only > pmlc). > A great idea! We could use ~/.pcp/pmlogger (which also houses the pmchart/pmcollectl/pm* personal recordings, so maybe not there) or ~/.pcp/tmp/pmlogger ala ($PCP_TMP_DIR/pmlogger) - somewhere below ~/.pcp anyway. cheers. -- Nathan From nscott@redhat.com Tue Feb 18 14:11:57 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 85C158001 for ; Tue, 18 Feb 2014 14:11:57 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 742C98F8037 for ; Tue, 18 Feb 2014 12:11:54 -0800 (PST) X-ASG-Debug-ID: 1392754312-04cbb00c2a54ec90001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id UjiDIYBuwwDkLTmB for ; Tue, 18 Feb 2014 12:11:53 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1IKBg7X025383; Tue, 18 Feb 2014 15:11:49 -0500 Date: Tue, 18 Feb 2014 15:11:42 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: PCP Message-ID: <1958567240.10287297.1392754302864.JavaMail.zimbra@redhat.com> In-Reply-To: <1391636602.10283414.1392754124235.JavaMail.zimbra@redhat.com> Subject: That pmie tmpdir QA fallout change MIME-Version: 1.0 X-ASG-Orig-Subj: That pmie tmpdir QA fallout change Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: That pmie tmpdir QA fallout change Thread-Index: c1msPIbCph08x8bgfLtoEcrV50mWlA== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392754312 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145254 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Ken, I'm puzzled by the need for the change below, as I've not been seeing this message (and hence, no QA fallout for me). What was the full error message string you saw here? (or errno?) Is it EPERM? EACCESS? The idea was that pmie would quietly continue on its way in these situations, without exporting the stats file - just want to make sure we are doing that right. (ie perhaps we need to check for errnos in addition to EEXIST, which appears to be doing the trick for me but not for you?). thanks! commit 6717436693b165a1a5401d3577e078a2a5aa0cc8 Author: Ken McDonell Date: Mon Feb 17 14:47:24 2014 +1100 pmie - quieten warning after tmp dir perms change After recent changes to the mode and ownership of the $PCP_VAR_DIR/tmp directory, the message "... warning cannot create stats file dir ..." may be emitted each time pmie is run as a user other than "pcp". This happens a LOT in QA. Since the message is only a warning, and the only side-effect is that the pmie process is not visible in the instance domain of the pmcd.pmie metrics (it is likely that no one but kenj cares!), I've suppressed the message unless one of the pmie verbose flags is set (-v, -V or -W). diff --git a/src/pmie/src/pmie.c b/src/pmie/src/pmie.c index 0ed8e5f..29198ed 100644 --- a/src/pmie/src/pmie.c +++ b/src/pmie/src/pmie.c @@ -331,7 +331,7 @@ startmonitor(void) snprintf(pmie_dir, sizeof(pmie_dir), "%s%c%s", pmGetConfig("PCP_TMP_DIR"), __pmPathSeparator(), PMIE_SUBDIR); if (mkdir2(pmie_dir, S_IRWXU | S_IRWXG | S_IRWXO) < 0) { - if (oserror() != EEXIST) { + if (oserror() != EEXIST && verbose) { fprintf(stderr, "%s: warning cannot create stats file dir %s: %s\n", pmProgname, pmie_dir, osstrerror()); } -- Nathan From kenj@internode.on.net Tue Feb 18 15:17:51 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id D67088005 for ; Tue, 18 Feb 2014 15:17:51 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id B503830407F for ; Tue, 18 Feb 2014 13:17:48 -0800 (PST) X-ASG-Debug-ID: 1392758265-04bdf00fc9126150001-S8gJnT Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [150.101.137.143]) by cuda.sgi.com with ESMTP id oMcN5kZi4GEHYfE7 for ; Tue, 18 Feb 2014 13:17:45 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.143 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkbACzNA1N20YajPGdsb2JhbAANTIcXhDq1eIMGgTYDAQEBATiCWgEBAQQjFUABEAsYAgIFFgsCAgkDAgECATEUBg0BBwEBsgt2oEkXgSmNOweCb4FJAQOuFQ Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail05.adl6.internode.on.net with ESMTP; 19 Feb 2014 07:47:44 +1030 Message-ID: <5303CE11.9000600@internode.on.net> Date: Wed, 19 Feb 2014 08:18:09 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Scott CC: PCP Subject: Re: That pmie tmpdir QA fallout change References: <1958567240.10287297.1392754302864.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: That pmie tmpdir QA fallout change In-Reply-To: <1958567240.10287297.1392754302864.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail05.adl6.internode.on.net[150.101.137.143] X-Barracuda-Start-Time: 1392758265 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145255 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 19/02/14 07:11, Nathan Scott wrote: > Hi Ken, > > I'm puzzled by the need for the change below, as I've not been > seeing this message (and hence, no QA fallout for me). What > was the full error message string you saw here? (or errno?) > Is it EPERM? EACCESS? The idea was that pmie would quietly > continue on its way in these situations, without exporting the > stats file - just want to make sure we are doing that right. > (ie perhaps we need to check for errnos in addition to EEXIST, > which appears to be doing the trick for me but not for you?). Thanks Nathan for spotting this. The code change may have been premature. I discovered the root cause later (thanks to qa/994 which we should try and clone with a small sequence number so it gets run early and late), namely /var/lib/pcp/tmp/pmie is removed and/or had its mode changed to 755 (not 775 as installed). This has been a lurking problem for me for sometime, and I cannot isolate the qa (or other!) malevolent pixie that is smacking the sometime after a package install. I've reverted commit a5aa0cc8 in my tree, and rerun the -g pmie qa group which passes up to qa/515, so this reversion will be in my next batch of pushed commits and I'll track down who's really smacking this directory in the qa environment. From nscott@redhat.com Tue Feb 18 17:59:20 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 031F27F76 for ; Tue, 18 Feb 2014 17:59:20 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id F33E68F8084 for ; Tue, 18 Feb 2014 15:59:16 -0800 (PST) X-ASG-Debug-ID: 1392767952-04cb6c6de15661d0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id wDlYI0J4ofbgrupo for ; Tue, 18 Feb 2014 15:59:12 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1INx83H026116; Tue, 18 Feb 2014 18:59:08 -0500 Date: Tue, 18 Feb 2014 18:59:08 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: PCP Message-ID: <1357168130.10403959.1392767948360.JavaMail.zimbra@redhat.com> In-Reply-To: <5303CE11.9000600@internode.on.net> References: <1958567240.10287297.1392754302864.JavaMail.zimbra@redhat.com> <5303CE11.9000600@internode.on.net> Subject: Re: That pmie tmpdir QA fallout change MIME-Version: 1.0 X-ASG-Orig-Subj: Re: That pmie tmpdir QA fallout change Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: That pmie tmpdir QA fallout change Thread-Index: A5IE6Egt7rjU8jbZ0sgm13t5s1KfCg== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392767952 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145260 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > [...] > I've reverted commit a5aa0cc8 in my tree, and rerun the -g pmie qa group > which passes up to qa/515, so this reversion will be in my next batch of > pushed commits and I'll track down who's really smacking this directory > in the qa environment. > OK - thanks. Franks latest pmmgr code is merged, I've still got a gluster PMDA fix pending, then I'll pick up whatever you have here, run a final QA pass, and we're done for 3.9.0. cheers. -- Nathan From nscott@redhat.com Tue Feb 18 18:33:32 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 192E28001 for ; Tue, 18 Feb 2014 18:33:32 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 83958AC004 for ; Tue, 18 Feb 2014 16:33:28 -0800 (PST) X-ASG-Debug-ID: 1392770006-04cb6c06cf2538c0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id jDO5DfWLSXGN6WdP for ; Tue, 18 Feb 2014 16:33:26 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1J0XQhI013865; Tue, 18 Feb 2014 19:33:26 -0500 Date: Tue, 18 Feb 2014 19:33:26 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" , Dave Brolley Cc: pcp@oss.sgi.com Message-ID: <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> In-Reply-To: <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> Subject: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Thread-Index: Cp9QjdpQdDKR7wKqIXT55+Hz0ct42thIOtMI X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392770006 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145261 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > [...] > A great idea! We could use ~/.pcp/pmlogger (which also houses the > pmchart/pmcollectl/pm* personal recordings, so maybe not there) or > ~/.pcp/tmp/pmlogger ala ($PCP_TMP_DIR/pmlogger) - somewhere below > ~/.pcp anyway. Just realised we'll probably want other tools doing similar things - the pmtime socket should be switched to af_unix too (having to seek for an available port is not ideal), so we'll need a home for those files too. Please choose a location with this in mind. cheers. -- Nathan From nscott@redhat.com Tue Feb 18 20:22:55 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 00F117FF9 for ; Tue, 18 Feb 2014 20:22:54 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id E921830408F for ; Tue, 18 Feb 2014 18:22:54 -0800 (PST) X-ASG-Debug-ID: 1392776572-04cb6c6de25700e0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id JoDc4n956emUCcjU for ; Tue, 18 Feb 2014 18:22:53 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1J2MqXI032242 for ; Tue, 18 Feb 2014 21:22:52 -0500 Date: Tue, 18 Feb 2014 21:22:52 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: PCP Message-ID: <793872724.10459141.1392776572690.JavaMail.zimbra@redhat.com> Subject: pcp updates: pmmgr, pmdagluster MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: pmmgr, pmdagluster Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: pmmgr, pmdagluster Thread-Index: K7jrcxTGI+WhVdqZA4Vmv0Jy/OHjKg== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392776573 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145265 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev CHANGELOG | 2 build/rpm/fedora.spec | 1 qa/gluster/info-raid1 | 81 qa/gluster/profile-raid1-info | 5666 +++++++++++++++++++++++++++++++++++ src/pmdas/gluster/pmdagluster.python | 41 src/pmmgr/pmmgr.cxx | 23 6 files changed, 5786 insertions(+), 28 deletions(-) commit ec0ab978a71c12d9ce14d2a1ad51eb944e3e0e7d Author: Nathan Scott Date: Wed Feb 19 13:22:02 2014 +1100 Improvements to the gluster filesystem PMDA Add a few missing filesystem operations to pmdagluster. Introduce exception handling such that if new operations appear unexpectedly, we handle this gracefully. Improve the handling of multiple profiled volumes also. Resolves Red Hat bug #1066544. commit 40aea82956816e6d12f8e4070ec6ce11d0bcf319 Author: Frank Ch. Eigler Date: Tue Feb 18 10:26:20 2014 -0500 pmmgr signal handling: the finaler solution Add a few more explicit process-group and targeted subprocess kills when quits are in progress, to make it more likely that no child is left alive when pmmgr itself dies. From kenj@internode.on.net Tue Feb 18 21:28:45 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 87AC97FEE for ; Tue, 18 Feb 2014 21:28:45 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7FC3930408F for ; Tue, 18 Feb 2014 19:28:42 -0800 (PST) X-ASG-Debug-ID: 1392780519-04cb6c6de2574560001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id IJ6PP19WaE8VtV8A for ; Tue, 18 Feb 2014 19:28:40 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4dAFokBFN20YajPGdsb2JhbAANTIM+iBO6QgMBAQEBOIMZQDANFhgDAgECATEnBgIBAbJIoloXkyMEon+LFg Received: from ppp118-209-134-163.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.134.163]) by ipmail04.adl6.internode.on.net with ESMTP; 19 Feb 2014 13:58:39 +1030 Message-ID: <53042501.5020203@internode.on.net> Date: Wed, 19 Feb 2014 14:29:05 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pcp updates - perl packaging, pmie tmp dir snafu fixup, qa, libpcp(_fault) Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ASG-Orig-Subj: pcp updates - perl packaging, pmie tmp dir snafu fixup, qa, libpcp(_fault) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1392780519 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145267 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- [Ctrl-Shift-W to unwrap lines] Changes committed to git://oss.sgi.com/kenj/pcp.git dev qa/353 | 4 ++++ qa/480 | 6 +++++- qa/504 | 1 + qa/common.config | 8 +++++++- src/libpcp/src/GNUmakefile | 5 ++--- src/libpcp/src/auxserver.c | 1 - src/libpcp_fault/src/GNUmakefile | 7 +++---- src/perl/LogImport/GNUmakefile | 2 +- src/perl/LogSummary/GNUmakefile | 2 +- src/perl/MMV/GNUmakefile | 2 +- src/perl/PMDA/GNUmakefile | 2 +- src/pmie/rc_pmie | 2 +- src/pmie/src/pmie.c | 2 +- 13 files changed, 28 insertions(+), 16 deletions(-) commit 60d19303b42029971262afd60eefbdd45d03a087 Author: Ken McDonell Date: Wed Feb 19 14:12:40 2014 +1100 rc_pmie - gotcha! don't remove $PCP_TMP_DIR/pmie Finally tracked down the root cause of bizarre pmie QA failures ... qa/504 was tripping a bug in the "stop" case for the pmie init script that removed $PCP_TMP_DIR/pmie rather than removing all the files in this directory. commit f48c60862dd033ff57894cb9c613ca92e573b8c1 Author: Ken McDonell Date: Wed Feb 19 14:10:54 2014 +1100 qa/common.config - tweaks for socks and cisco hosts Make sure values are always set, so we can test in the QA scripts for a value that means "not today Jose". commit c9223c1c33c244e44c110903226a1ae402b07f65 Author: Ken McDonell Date: Wed Feb 19 14:09:50 2014 +1100 qa/504 - tigher cleanup logic Don't do it all again if _cleanup called more than once. commit 6d04f6059949a34daa27d133a891e07454d2f825 Author: Ken McDonell Date: Wed Feb 19 07:59:14 2014 +1100 Revert "pmie - quieten warning after tmp dir perms change" This reverts commit 6717436693b165a1a5401d3577e078a2a5aa0cc8. Problem was really a directory permissions botch, so reenable the message unconditionally. commit 72f1ca7e0deadc1652c15d3a21a55720246ce3ca Author: Ken McDonell Date: Tue Feb 18 19:56:20 2014 +1100 qa/353 - make it notrun unless $PCPQA_SOCKS_SERVER is set up commit 0b7ff82e99c840cdd8caacf87a3d6df8deef289d Author: Ken McDonell Date: Tue Feb 18 19:42:06 2014 +1100 libpcp_fault/GNUmakefile - make it work again Sync up with recent avahi changes in libpcp. commit 644395401f5472e256a4b9d9cec21df7414d71e4 Author: Ken McDonell Date: Tue Feb 18 18:20:09 2014 +1100 libpcp/GNUmakeile - avahi tweaking discovery.c unconditionally includes avahi.h, so cannot hide this behind ifeq "$(ENABLE_SECURE)" "true" Promote avahi.h to $(HFILES). commit 8e28964d0ca318d394c4670b3031b254141b48bb Author: Ken McDonell Date: Tue Feb 18 18:18:51 2014 +1100 libpcp/auxserver.c - do not need #include "avahi.h" commit e02429a4ced6833bef12c58ef0cd5ad001205782 Author: Ken McDonell Date: Tue Feb 18 18:15:58 2014 +1100 qa/480 - rework for 3.9.0 The config.h include file has morphed into a forest of config*.h include files ... just deal with it. commit 8d8a3bfc37e8189b8d010027ef3f59fc5160bd7a Author: Ken McDonell Date: Tue Feb 18 16:11:00 2014 +1100 perl install changes - fix Debian packaging issue As per Nathan's suggestion, pure_install seems a safer target than install for the perl generated Makefiles. Tested on both Debian platforms where the old way was passing and failing. From scox@redhat.com Tue Feb 18 21:58:50 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6F63C8002 for ; Tue, 18 Feb 2014 21:58:50 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 65FEC8F8078 for ; Tue, 18 Feb 2014 19:58:47 -0800 (PST) X-ASG-Debug-ID: 1392782326-04cbb00c2b571180001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id XEBFyrDRKuD00XaE for ; Tue, 18 Feb 2014 19:58:46 -0800 (PST) X-Barracuda-Envelope-From: scox@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1J3wj8m014180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 18 Feb 2014 22:58:46 -0500 Received: from [10.13.129.29] (dhcp129-29.rdu.redhat.com [10.13.129.29]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1J3wjU5022803 for ; Tue, 18 Feb 2014 22:58:45 -0500 Message-ID: <53042BF5.5070704@redhat.com> Date: Tue, 18 Feb 2014 22:58:45 -0500 From: Stan Cox User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: PCP Subject: datetime enhancements Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ASG-Orig-Subj: datetime enhancements Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392782326 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 commit 7ef03c90217b adds support for the gnulib get_date module to pcplib/rtime.c::__pmParseTime. First it tries the existing mechanism. If that fails it tries gnulib get_date. Here is an example from the testcase which shows example datetimes and how the start/end times are adjusted. No doc changes yet but the date command uses the gnulib get_date support and documents it in info date 'date input' QA output created by 751 "start " 2014-02-17 10:08:50 "end " 2014-02-27 11:28:50 "Mon Feb 19 11:45:50 2014 " 2014-02-19 11:45:50 "+1minute" 2014-02-17 10:09:50 "-1minute" 2014-02-27 11:27:50 "2014-02-19" 2014-02-19 00:00:00 "02/19/14" 2014-02-19 00:00:00 "02/19/14 11:45:50 AM" 2014-02-19 11:45:50 "02/19/14 11:45" 2014-02-19 11:45:00 "02/19/14 11:45:50" 2014-02-19 11:45:50 "19 Feb 2014 11:45:50" 2014-02-19 11:45:50 "yesterday" 2014-02-26 11:28:50 "next day" 2014-02-18 10:08:50 "1 day ago" 2014-02-26 11:28:50 "1 week ago" 2014-02-20 11:28:50 "@2014-02-19" 2014-02-19 00:00:00 "@02/19/14" 2014-02-19 00:00:00 "@02/19/14 11:45:50 AM" 2014-02-19 11:45:50 "@02/19/14 11:45" 2014-02-19 11:45:00 "@02/19/14 11:45:50" 2014-02-19 11:45:50 "@19 Feb 2014 11:45:50" 2014-02-19 11:45:50 "@yesterday" 2014-02-26 11:28:50 "@next day" 2014-02-18 10:08:50 "@1 day ago" 2014-02-26 11:28:50 "1 day" 2014-02-18 10:08:50 "5 minutes 5 seconds" 2014-02-17 10:13:55 From chandana@desilva.id.au Tue Feb 18 22:49:22 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 8C71A800B for ; Tue, 18 Feb 2014 22:49:22 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 228F7AC004 for ; Tue, 18 Feb 2014 20:49:18 -0800 (PST) X-ASG-Debug-ID: 1392785353-04bdf0083a29050001-S8gJnT Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by cuda.sgi.com with ESMTP id nzlKpKaRqMUFT5HV (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 18 Feb 2014 20:49:14 -0800 (PST) X-Barracuda-Envelope-From: chandana@desilva.id.au X-Barracuda-Apparent-Source-IP: 204.13.248.66 Received: from ec2-54-252-74-219.ap-southeast-2.compute.amazonaws.com ([54.252.74.219] helo=mail.desilva.id.au) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1WFz5t-000P3U-FJ for pcp@oss.sgi.com; Wed, 19 Feb 2014 04:49:13 +0000 Received: from [192.168.19.159] (mail.messagemedia.com.au [175.45.83.34]) by mail.desilva.id.au (Postfix) with ESMTPSA id 710FF203BD for ; Wed, 19 Feb 2014 04:49:11 +0000 (UTC) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 54.252.74.219 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/iCLADLcl1hSTvCo7kzzRWFT4xTPDoe1M= Message-ID: <530437C7.4040900@desilva.id.au> Date: Wed, 19 Feb 2014 15:49:11 +1100 From: Chandana De Silva Reply-To: chandana@desilva.id.au User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Detecting of a host is being logged by pmlogger Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ASG-Orig-Subj: Detecting of a host is being logged by pmlogger Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mho-03-ewr.mailhop.org[204.13.248.66] X-Barracuda-Start-Time: 1392785354 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145268 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Does any one know of a way to detect if a remote pmlogger is connected to a host. I looked at the output from netstat (netstat -np | grep CONNECTED) and did not see anything. Chandana From nscott@redhat.com Tue Feb 18 22:55:42 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 189DC800B for ; Tue, 18 Feb 2014 22:55:42 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id DB2E08F8078 for ; Tue, 18 Feb 2014 20:55:41 -0800 (PST) X-ASG-Debug-ID: 1392785740-04bdf0083a29600001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id la1aKLof6oelJHRS for ; Tue, 18 Feb 2014 20:55:40 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1J4tct6010029; Tue, 18 Feb 2014 23:55:38 -0500 Date: Tue, 18 Feb 2014 23:55:38 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: chandana@desilva.id.au Cc: pcp@oss.sgi.com Message-ID: <255091837.10539721.1392785738351.JavaMail.zimbra@redhat.com> In-Reply-To: <530437C7.4040900@desilva.id.au> References: <530437C7.4040900@desilva.id.au> Subject: Re: [pcp] Detecting of a host is being logged by pmlogger MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] Detecting of a host is being logged by pmlogger Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Detecting of a host is being logged by pmlogger Thread-Index: NJJfotLx+FC2x0vJcV5Hht1LuH7PcA== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392785740 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145269 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header ----- Original Message ----- > Does any one know of a way to detect if a remote pmlogger is connected > to a host. > > I looked at the output from netstat (netstat -np | grep CONNECTED) and > did not see anything. > pminfo -ft pmcd.client.whoami cheers. -- Nathan From nscott@redhat.com Wed Feb 19 01:01:14 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 2FBB729DF8 for ; Wed, 19 Feb 2014 01:01:14 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 1F5828F8037 for ; Tue, 18 Feb 2014 23:01:10 -0800 (PST) X-ASG-Debug-ID: 1392793265-04cb6c06cf26c090001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id F01jNqP9tXUXJVVX for ; Tue, 18 Feb 2014 23:01:06 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1J715uq011522 for ; Wed, 19 Feb 2014 02:01:05 -0500 Date: Wed, 19 Feb 2014 02:01:05 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp@oss.sgi.com Message-ID: <300483810.10658246.1392793265261.JavaMail.zimbra@redhat.com> In-Reply-To: <1407159945.10657095.1392793183244.JavaMail.zimbra@redhat.com> Subject: pcp-gui updates: pmchart fonts, wildcards MIME-Version: 1.0 X-ASG-Orig-Subj: pcp-gui updates: pmchart fonts, wildcards Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp-gui updates: pmchart fonts, wildcards Thread-Index: QgJwz8iBqtz3UP2kQJzY5tygfO+TAQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392793265 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145271 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp-gui.git dev build/rpm/fedora.spec | 10 + debian/changelog | 4 doc/CHANGES | 21 ++- man/man1/pmchart.1 | 39 +++++- src/chart/aboutdialog.ui | 2 src/chart/chart.cpp | 290 +++++++++++++++++++++++++++++++-------------- src/chart/chart.h | 36 +++-- src/chart/main.cpp | 34 ++++- src/chart/namespace.cpp | 5 src/chart/namespace.h | 6 src/chart/pmchart.h | 1 src/chart/sampling.cpp | 4 src/chart/sampling.h | 4 src/chart/seealsodialog.ui | 2 src/chart/tracing.cpp | 4 src/chart/tracing.h | 4 src/chart/view.cpp | 30 ---- 17 files changed, 340 insertions(+), 156 deletions(-) commit 4daa63fc78c256db9e6c930cf613331a93bae148 Author: Nathan Scott Date: Wed Feb 19 17:56:25 2014 +1100 Chart legend updates, particularly allowing for additional wildcards Adds several new wildcards into the chart plot titles specification which was previously limited to just %i (instance name). This now adds in short and long forms of host, metric and instance name. The full list is documented via updates to the pmchart(1) man page. Also, fix two bug found in the process. Firstly, File -> Save View menu option was not preserving wildcards, instead it was saving the expanded title. Second, modifications via the (interactive) Plot title line edit on the New and Edit Chart dialogs was not correctly updating the chart on pressing OK or Apply. Resolves Red Hat bug #1066174. commit fce9f75a3f52d0b3b4ba2a82de5e944ce662ccd6 Author: Nathan Scott Date: Tue Feb 18 16:19:06 2014 +1100 Update release and changelog details for next pcp-gui update commit e6e351bc7bdf8463ea8313547d342f3bba4f2a80 Author: Nathan Scott Date: Tue Feb 18 16:15:31 2014 +1100 Add support for non-shortened hostname title replacement via %H commit e617725ef12e7a6f05d25c3c8711c9022a0139d8 Author: Nathan Scott Date: Tue Feb 18 16:11:28 2014 +1100 Reinstate accidentally removed option for hosts, and missed (C) update commit 7131a290b4eaab4af3f3c1bdfda78f457503bcb7 Author: Nathan Scott Date: Tue Feb 18 14:59:36 2014 +1100 Add pmchart options to set font size and family Introduce -f and -F to pmchart for allowing the user more control over the default chart font size used for things like Y-Axis labels, the title and the legend. Other excellent suggestions for improving this include an interactive Preferences dialog addition, and browser-like Ctrl+ and Ctrl- hotkeys. These have not been implemented at this stage. Additional work on improving layouts with these settings would be good too, but this gives at least a simple way to tweak this now. commit f168a3b7ce4969035a275af11c111dfab93478c3 Author: Nathan Scott Date: Tue Feb 18 14:48:23 2014 +1100 Update copyright details for Red Hat in splash screens From chandana@desilva.id.au Wed Feb 19 02:27:50 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 05286801D for ; Wed, 19 Feb 2014 02:27:50 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id E48BA8F8078 for ; Wed, 19 Feb 2014 00:27:49 -0800 (PST) X-ASG-Debug-ID: 1392798463-04cb6c06cf26fbc0001-S8gJnT Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by cuda.sgi.com with ESMTP id 6G7PET2MbTkUeh1I (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 19 Feb 2014 00:27:43 -0800 (PST) X-Barracuda-Envelope-From: chandana@desilva.id.au X-Barracuda-Apparent-Source-IP: 204.13.248.66 Received: from ec2-54-252-74-219.ap-southeast-2.compute.amazonaws.com ([54.252.74.219] helo=mail.desilva.id.au) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1WG2VK-000Eal-LR; Wed, 19 Feb 2014 08:27:42 +0000 Received: from [192.168.1.135] (d211-31-205-134.sun802.vic.optusnet.com.au [211.31.205.134]) by mail.desilva.id.au (Postfix) with ESMTPSA id 7013E2435C; Wed, 19 Feb 2014 08:27:40 +0000 (UTC) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 54.252.74.219 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+9t72asZT2g709a8MWOrqoZYq4qbftYcs= Message-ID: <53046AFB.7080007@desilva.id.au> Date: Wed, 19 Feb 2014 19:27:39 +1100 From: Chandana De Silva Reply-To: chandana@desilva.id.au User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Scott CC: pcp@oss.sgi.com Subject: Re: [pcp] Detecting of a host is being logged by pmlogger References: <530437C7.4040900@desilva.id.au> <255091837.10539721.1392785738351.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] Detecting of a host is being logged by pmlogger In-Reply-To: <255091837.10539721.1392785738351.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mho-03-ewr.mailhop.org[204.13.248.66] X-Barracuda-Start-Time: 1392798463 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DOMAIN_4U2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145273 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 DOMAIN_4U2 URI: Domain name containing a "4u" variant Nathan Thanks. I tried it, but it does not seem to have full information on remote clients, I am assuming either inst 48 or 50 is what I am looking for. $ pminfo -ft pmcd.client.whoami pmcd.client.whoami [optional identification information for clients of pmcd] inst [40 or "40"] value "hr1.dom (192.168.x.y) pmie -b -h local: -l /var/log/pcp/pmie/hr1.m4u.com.au/healthstate.log -c healthstate.pmie" inst [44 or "44"] value "hr1.dom (192.168.x.y) pmie -b -h local: -l /var/log/pcp/pmie/hr1.m4u.com.au/pmie.log -c config.default" inst [47 or "47"] value "hr1.dom (192.168.x.y) pmie -b -h local: -l /var/log/pcp/pmie/hr1.m4u.com.au/config.linux.log -c config.linux" inst [48 or "48"] value "" inst [50 or "50"] value "" pmcd: Version 3.8.6-1 The IP address is the host ip address On 19/02/14 15:55, Nathan Scott wrote: > ----- Original Message ----- >> Does any one know of a way to detect if a remote pmlogger is connected >> to a host. >> >> I looked at the output from netstat (netstat -np | grep CONNECTED) and >> did not see anything. >> > pminfo -ft pmcd.client.whoami > > cheers. > > -- > Nathan From nscott@redhat.com Wed Feb 19 04:33:04 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id A779E800E for ; Wed, 19 Feb 2014 04:33:04 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 7CAD08F8078 for ; Wed, 19 Feb 2014 02:33:01 -0800 (PST) X-ASG-Debug-ID: 1392805976-04bdf00fc915a190001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id df1KzkrUrM9wJd0O for ; Wed, 19 Feb 2014 02:32:56 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1JAWt3W002830; Wed, 19 Feb 2014 05:32:55 -0500 Date: Wed, 19 Feb 2014 05:32:55 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: PCP Message-ID: <145432315.10899373.1392805975723.JavaMail.zimbra@redhat.com> In-Reply-To: <1156313559.10896389.1392805834068.JavaMail.zimbra@redhat.com> Subject: New OpenIndiana build failure MIME-Version: 1.0 X-ASG-Orig-Subj: New OpenIndiana build failure Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: New OpenIndiana build failure Thread-Index: L1YF8VmoXjNXebzdmRnJKKyhMLKRDA== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392805976 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145275 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi, I've just starting seeing build failure this for the first time... $ uname -a SunOS munch 5.11 oi_151a8 i86pc i386 i86pc Solaris [...] g++ -g -O2 -fPIC -fno-strict-aliasing -m64 -Wall -O2 -g -DPCP_DEBUG -DPCP_VERSION=\"3.9.0\" -I../../src/include -I../../src/include/pcp -c pmmgr.cxx -o pmmgr.o In file included from /usr/include/iso/stdlib_iso.h:46, from /usr/include/stdlib.h:34, from ../../src/include/pcp/pmapi.h:19, from pmmgr.h:19, from pmmgr.cxx:17: /usr/include/sys/feature_tests.h:355:2: #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications require the use of c99" make: *** [pmmgr.o] Error 1 The following seems to workaround it (#undef doesn't strangely)... diff --git a/src/pmmgr/pmmgr.cxx b/src/pmmgr/pmmgr.cxx index f9de01b..cc6ecb0 100644 --- a/src/pmmgr/pmmgr.cxx +++ b/src/pmmgr/pmmgr.cxx @@ -12,7 +12,9 @@ * for more details. */ +#ifndef _XOPEN_SOURCE #define _XOPEN_SOURCE 600 +#endif #include "pmmgr.h" #include "impl.h" ? Or would a configure update & addition to the existing BUILD_PMMGR check be better? cheers. -- Nathan From nscott@redhat.com Wed Feb 19 04:34:29 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 7DEA2800E for ; Wed, 19 Feb 2014 04:34:29 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 60C198F8078 for ; Wed, 19 Feb 2014 02:34:29 -0800 (PST) X-ASG-Debug-ID: 1392806068-04bdf0083a3d000001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id IKOBIHeEtGQ9Fau1 for ; Wed, 19 Feb 2014 02:34:28 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1JAYQ7s016765; Wed, 19 Feb 2014 05:34:27 -0500 Date: Wed, 19 Feb 2014 05:34:26 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: chandana@desilva.id.au Cc: pcp@oss.sgi.com Message-ID: <1466910430.10900672.1392806066557.JavaMail.zimbra@redhat.com> In-Reply-To: <53046AFB.7080007@desilva.id.au> References: <530437C7.4040900@desilva.id.au> <255091837.10539721.1392785738351.JavaMail.zimbra@redhat.com> <53046AFB.7080007@desilva.id.au> Subject: Re: [pcp] Detecting of a host is being logged by pmlogger MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] Detecting of a host is being logged by pmlogger Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Detecting of a host is being logged by pmlogger Thread-Index: Bp3Z2amAKGTAiJfQFOO3nFVwLbgGQw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392806068 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145275 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header ----- Original Message ----- > Nathan > > Thanks. I tried it, but it does not seem to have full information on > remote clients, I am assuming either inst 48 or 50 is what I am looking for. > Not sure - this mechanism uses pmStore(3), maybe that pmcd is only allowing local host stores (check pmcd.conf [access] section). cheers. -- Nathan From fche@redhat.com Wed Feb 19 06:14:46 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 4D6D3801D for ; Wed, 19 Feb 2014 06:14:46 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id D5A24AC007 for ; Wed, 19 Feb 2014 04:14:42 -0800 (PST) X-ASG-Debug-ID: 1392812078-04cb6c6de0593c60001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id ku4inlfLVg5HiBkC for ; Wed, 19 Feb 2014 04:14:38 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1JCEbMc023367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Feb 2014 07:14:38 -0500 Received: from fche.csb (vpn-236-177.phx2.redhat.com [10.3.236.177]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1JCEbVj022602; Wed, 19 Feb 2014 07:14:37 -0500 Received: by fche.csb (Postfix, from userid 2569) id 54FE65833C; Wed, 19 Feb 2014 07:14:37 -0500 (EST) Date: Wed, 19 Feb 2014 07:14:37 -0500 From: "Frank Ch. Eigler" To: Nathan Scott Cc: PCP Subject: Re: New OpenIndiana build failure Message-ID: <20140219121437.GB6516@redhat.com> X-ASG-Orig-Subj: Re: New OpenIndiana build failure References: <1156313559.10896389.1392805834068.JavaMail.zimbra@redhat.com> <145432315.10899373.1392805975723.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <145432315.10899373.1392805975723.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392812078 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - > The following seems to workaround it (#undef doesn't strangely)... > [...] > +#ifndef _XOPEN_SOURCE > #define _XOPEN_SOURCE 600 > +#endif If it works for that OS, it works for me. - FChE From scox@redhat.com Wed Feb 19 07:28:19 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 25A29801B for ; Wed, 19 Feb 2014 07:28:19 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id AC30CAC007 for ; Wed, 19 Feb 2014 05:28:18 -0800 (PST) X-ASG-Debug-ID: 1392816497-04bdf0083a4bd20001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id LgSRLdq3GCYmk5df for ; Wed, 19 Feb 2014 05:28:17 -0800 (PST) X-Barracuda-Envelope-From: scox@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1JDSG9a000384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Feb 2014 08:28:17 -0500 Received: from [10.13.129.29] (dhcp129-29.rdu.redhat.com [10.13.129.29]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1JDSG1F022110 for ; Wed, 19 Feb 2014 08:28:16 -0500 Message-ID: <5304B170.7080602@redhat.com> Date: Wed, 19 Feb 2014 08:28:16 -0500 From: Stan Cox User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: PCP Subject: Re: [pcp] datetime enhancements References: <53042BF5.5070704@redhat.com> X-ASG-Orig-Subj: Re: [pcp] datetime enhancements In-Reply-To: <53042BF5.5070704@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392816497 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Forgot to mention, that is located in: ssh://sourceware.org/git/pcpfans.git branch: scox/dev From brolley@redhat.com Wed Feb 19 09:39:11 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 3786A802A for ; Wed, 19 Feb 2014 09:39:11 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1972130409A for ; Wed, 19 Feb 2014 07:39:10 -0800 (PST) X-ASG-Debug-ID: 1392824349-04cbb00c295a2350001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id FpCdIiswRFoTfWiZ for ; Wed, 19 Feb 2014 07:39:10 -0800 (PST) X-Barracuda-Envelope-From: brolley@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1JFd8lN029906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Feb 2014 10:39:09 -0500 Received: from [10.10.49.31] (vpn-49-31.rdu2.redhat.com [10.10.49.31]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1JFd7aC031522; Wed, 19 Feb 2014 10:39:08 -0500 Message-ID: <5304D039.9010708@redhat.com> Date: Wed, 19 Feb 2014 10:39:37 -0500 From: Dave Brolley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Scott , "Frank Ch. Eigler" CC: pcp@oss.sgi.com Subject: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc In-Reply-To: <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392824349 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On 02/18/2014 07:33 PM, Nathan Scott wrote: > ----- Original Message ----- >> [...] >> A great idea! We could use ~/.pcp/pmlogger (which also houses the >> pmchart/pmcollectl/pm* personal recordings, so maybe not there) or >> ~/.pcp/tmp/pmlogger ala ($PCP_TMP_DIR/pmlogger) - somewhere below >> ~/.pcp anyway. On my system, PCP_TMP_DIR is /var/lib/pcp/tmp, which is where the pmlogger port map file is kept, and has the same issue as PCP_RUN_DIR, i.e. not writable by normal users. I think that ~/.pcp/pmlogger would be a good place. > Just realised we'll probably want other tools doing similar things - > the pmtime socket should be switched to af_unix too (having to seek > for an available port is not ideal), so we'll need a home for those > files too. Please choose a location with this in mind. > For other tools we could use ~/.pcp/. I don't see an existing environment variable for ~/.pcp. Systemtap uses SYSTEMTAPDIR, but PCPDIR doesn't seem to fit convention. How about PCP_USER_DIR. Any other suggestions? Dave From fche@redhat.com Wed Feb 19 10:56:24 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 453B37FD5 for ; Wed, 19 Feb 2014 10:56:24 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1E6A030408A for ; Wed, 19 Feb 2014 08:56:20 -0800 (PST) X-ASG-Debug-ID: 1392828979-04bdf00fca17f2a0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id g1WECVwh0yh8k98o for ; Wed, 19 Feb 2014 08:56:20 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1JGuHMd005147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Feb 2014 11:56:18 -0500 Received: from fche.csb (vpn-236-177.phx2.redhat.com [10.3.236.177]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1JGuGNw021037; Wed, 19 Feb 2014 11:56:17 -0500 Received: by fche.csb (Postfix, from userid 2569) id 61B3D5833C; Wed, 19 Feb 2014 11:56:16 -0500 (EST) To: chandana@desilva.id.au Cc: pcp@oss.sgi.com Subject: Re: Detecting of a host is being logged by pmlogger References: <530437C7.4040900@desilva.id.au> X-ASG-Orig-Subj: Re: Detecting of a host is being logged by pmlogger From: fche@redhat.com (Frank Ch. Eigler) Date: Wed, 19 Feb 2014 11:56:16 -0500 In-Reply-To: <530437C7.4040900@desilva.id.au> (Chandana De Silva's message of "Wed, 19 Feb 2014 15:49:11 +1100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392828979 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 chandana wrote: > Does any one know of a way to detect if a remote pmlogger is connected > to a host. Why do you need to know that? You can detect TCP traffic reliably at the OS level, but who or what exactly is on the other side of that connection, you cannot be sure. - FChE From fche@redhat.com Wed Feb 19 11:45:38 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 6B8357F90 for ; Wed, 19 Feb 2014 11:45:38 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 540F88F8039 for ; Wed, 19 Feb 2014 09:45:38 -0800 (PST) X-ASG-Debug-ID: 1392831934-04bdf00fc0184af0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id bdZm16PvKdxs5H4U for ; Wed, 19 Feb 2014 09:45:34 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1JHjXMe020190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 19 Feb 2014 12:45:33 -0500 Received: from fche.csb (vpn-236-177.phx2.redhat.com [10.3.236.177]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1JH6kGA021990; Wed, 19 Feb 2014 12:06:47 -0500 Received: by fche.csb (Postfix, from userid 2569) id 74FFF5833C; Wed, 19 Feb 2014 12:06:45 -0500 (EST) To: Stan Cox Cc: PCP Subject: Re: datetime enhancements References: <53042BF5.5070704@redhat.com> X-ASG-Orig-Subj: Re: datetime enhancements From: fche@redhat.com (Frank Ch. Eigler) Date: Wed, 19 Feb 2014 12:06:45 -0500 In-Reply-To: <53042BF5.5070704@redhat.com> (Stan Cox's message of "Tue, 18 Feb 2014 22:58:45 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392831934 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 scox wrote: > QA output created by 751 > "start " 2014-02-17 10:08:50 > "end " 2014-02-27 11:28:50 > [...] > "+1minute" 2014-02-17 10:09:50 > "-1minute" 2014-02-27 11:27:50 > [...] Where does the logic come in that additive or subtractive time intevals would need to be relative to the (archive?) start/end times vs. the actual current time? - FChE From chandana@desilva.id.au Wed Feb 19 11:53:15 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 8D1AF7F90 for ; Wed, 19 Feb 2014 11:53:15 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 031CBAC009 for ; Wed, 19 Feb 2014 09:53:11 -0800 (PST) X-ASG-Debug-ID: 1392832389-04cb6c6de25b5d70001-S8gJnT Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by cuda.sgi.com with ESMTP id yAEZ94etBbctvT22 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 19 Feb 2014 09:53:09 -0800 (PST) X-Barracuda-Envelope-From: chandana@desilva.id.au X-Barracuda-Apparent-Source-IP: 204.13.248.72 Received: from ec2-54-252-74-219.ap-southeast-2.compute.amazonaws.com ([54.252.74.219] helo=mail.desilva.id.au) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1WGBKW-0005O4-Ao; Wed, 19 Feb 2014 17:53:08 +0000 Received: from [192.168.1.135] (d211-31-205-134.sun802.vic.optusnet.com.au [211.31.205.134]) by mail.desilva.id.au (Postfix) with ESMTPSA id ED77C24243; Wed, 19 Feb 2014 17:53:05 +0000 (UTC) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 54.252.74.219 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18KMa4+rfJoWwHv/WUv0YrG84iT2CZqat4= Message-ID: <5304EF81.5060902@desilva.id.au> Date: Thu, 20 Feb 2014 04:53:05 +1100 From: Chandana De Silva Reply-To: chandana@desilva.id.au User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Scott CC: pcp@oss.sgi.com Subject: Re: [pcp] Detecting of a host is being logged by pmlogger References: <530437C7.4040900@desilva.id.au> <255091837.10539721.1392785738351.JavaMail.zimbra@redhat.com> <53046AFB.7080007@desilva.id.au> <1466910430.10900672.1392806066557.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] Detecting of a host is being logged by pmlogger In-Reply-To: <1466910430.10900672.1392806066557.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mho-02-ewr.mailhop.org[204.13.248.72] X-Barracuda-Start-Time: 1392832389 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DOMAIN_4U2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145286 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 DOMAIN_4U2 URI: Domain name containing a "4u" variant No luck $ cat /etc/pcp/pmcd/pmcd.conf # Performance Metrics Domain Specifications # # This file is automatically generated during the build # Name Id IPC IPC Params File/Cmd pmcd 2 dso pmcd_init /var/lib/pcp/pmdas/pmcd/pmda_pmcd.so linux 60 dso linux_init /var/lib/pcp/pmdas/linux/pmda_linux.so proc 3 pipe binary /var/lib/pcp/pmdas/proc/pmdaproc -d 3 mmv 70 dso mmv_init /var/lib/pcp/pmdas/mmv/pmda_mmv.so xfs 11 pipe binary /var/lib/pcp/pmdas/xfs/pmdaxfs -d 11 jbd2 122 dso jbd2_init /var/lib/pcp/pmdas/jbd2/pmda_jbd2.so apache 68 pipe binary /var/lib/pcp/pmdas/apache/pmdaapache -d 68 [access] disallow ".*" : store; disallow ":*" : store; allow "local:*" : all; allow "192.168.*" : store; $ pminfo -ft pmcd.client.whoami pmcd.client.whoami [optional identification information for clients of pmcd] inst [0 or "0"] value "hr1.m4u.com.au (192.168.7.155) pmie -b -h local: -l /var/log/pcp/pmie/hr1.m4u.com.au/healthstate.log -c healthstate.pmie" inst [3 or "3"] value "hr1.m4u.com.au (192.168.7.155) pmie -b -h local: -l /var/log/pcp/pmie/hr1.m4u.com.au/config.linux.log -c config.linux" inst [12 or "12"] value "hr1.m4u.com.au (192.168.7.155) pmie -b -h local: -l /var/log/pcp/pmie/hr1.m4u.com.au/pmie.log -c config.default" inst [13 or "13"] value "" inst [16 or "16"] value "" cat /var/log/pcp/pmcd/pmcd.log Log for pmcd on hr1.m4u.com.au started Thu Feb 20 04:45:32 2014 active agent dom pid in out ver protocol parameters ============ === ===== === === === ======== ========== pmcd 2 2 dso i:5 lib=/var/lib/pcp/pmdas/pmcd/pmda_pmcd.so entry=pmcd_init [0x7fef0cdc9980] linux 60 2 dso i:4 lib=/var/lib/pcp/pmdas/linux/pmda_linux.so entry=linux_init [0x7fef0c99aaa0] proc 3 13647 10 11 2 bin pipe cmd=/var/lib/pcp/pmdas/proc/pmdaproc -d 3 mmv 70 2 dso i:4 lib=/var/lib/pcp/pmdas/mmv/pmda_mmv.so entry=mmv_init [0x7fef0c78c870] xfs 11 13650 12 13 2 bin pipe cmd=/var/lib/pcp/pmdas/xfs/pmdaxfs -d 11 jbd2 122 2 dso i:4 lib=/var/lib/pcp/pmdas/jbd2/pmda_jbd2.so entry=jbd2_init [0x7fef0c589650] apache 68 13653 16 17 2 bin pipe cmd=/var/lib/pcp/pmdas/apache/pmdaapache -d 68 Host access list: 00 01 Cur/MaxCons host-spec host-mask lvl host-name == == =========== ======================================= ======================================= === ============== y y 0 0 192.168.7.155 255.255.255.255 0 localhost y y 0 0 / / 1 unix: y 0 0 192.168.0.0 255.255.0.0 2 192.168.* n 0 0 0.0.0.0 0.0.0.0 4 .* n 0 0 :: :: 8 :* User access list empty: user-based access control turned off Group access list empty: group-based access control turned off pmcd: PID = 13636, PDU version = 2 pmcd request port(s): sts fd port family address === ==== ===== ====== ======= ok 1026 unix /var/run/pcp/pmcd.socket ok 1024 44321 inet INADDR_ANY ok 1025 44321 ipv6 INADDR_ANY Chandana On 19/02/14 21:34, Nathan Scott wrote: > > ----- Original Message ----- >> Nathan >> >> Thanks. I tried it, but it does not seem to have full information on >> remote clients, I am assuming either inst 48 or 50 is what I am looking for. >> > Not sure - this mechanism uses pmStore(3), maybe that pmcd is only > allowing local host stores (check pmcd.conf [access] section). > > cheers. > > -- > Nathan From chandana@desilva.id.au Wed Feb 19 11:53:47 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 11AA67F90 for ; Wed, 19 Feb 2014 11:53:47 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 0696C8F8039 for ; Wed, 19 Feb 2014 09:53:47 -0800 (PST) X-ASG-Debug-ID: 1392832425-04cbb00c285b0520001-S8gJnT Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by cuda.sgi.com with ESMTP id 8yfejlNs11FoKRWF (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 19 Feb 2014 09:53:45 -0800 (PST) X-Barracuda-Envelope-From: chandana@desilva.id.au X-Barracuda-Apparent-Source-IP: 204.13.248.72 Received: from ec2-54-252-74-219.ap-southeast-2.compute.amazonaws.com ([54.252.74.219] helo=mail.desilva.id.au) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1WGBL7-0005l2-2D; Wed, 19 Feb 2014 17:53:45 +0000 Received: from [192.168.1.135] (d211-31-205-134.sun802.vic.optusnet.com.au [211.31.205.134]) by mail.desilva.id.au (Postfix) with ESMTPSA id C6B6324243; Wed, 19 Feb 2014 17:53:43 +0000 (UTC) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 54.252.74.219 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+SK4P5pfvxFp5KfdbYYhHxEu921OJzPkA= Message-ID: <5304EFA7.3030804@desilva.id.au> Date: Thu, 20 Feb 2014 04:53:43 +1100 From: Chandana De Silva Reply-To: chandana@desilva.id.au User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: pcp@oss.sgi.com Subject: Re: Detecting of a host is being logged by pmlogger References: <530437C7.4040900@desilva.id.au> X-ASG-Orig-Subj: Re: Detecting of a host is being logged by pmlogger In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mho-02-ewr.mailhop.org[204.13.248.72] X-Barracuda-Start-Time: 1392832425 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145286 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header I have a central pmlogger server. On a normal host, I need to detect if the host is being logged by the remote pmlogger, and if not send a message to the remote logger to start logging me. I am assuming that pmcd knows it's clients, and was hoping that it can tell me. On 20/02/14 03:56, Frank Ch. Eigler wrote: > Why do you need to know that? You can detect TCP traffic reliably at > the OS level, but who or what exactly is on the other side of that > connection, you cannot be sure. From fche@redhat.com Wed Feb 19 12:12:58 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id B415A7FD4 for ; Wed, 19 Feb 2014 12:12:58 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9C25930409A for ; Wed, 19 Feb 2014 10:12:55 -0800 (PST) X-ASG-Debug-ID: 1392833574-04bdf00fca187750001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id ZHinyRF4EU8H9WnN for ; Wed, 19 Feb 2014 10:12:54 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1JICr6s027013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Feb 2014 13:12:53 -0500 Received: from fche.csb (vpn-236-177.phx2.redhat.com [10.3.236.177]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1JICqNt024232; Wed, 19 Feb 2014 13:12:52 -0500 Received: by fche.csb (Postfix, from userid 2569) id EFCAF5833C; Wed, 19 Feb 2014 13:12:51 -0500 (EST) Date: Wed, 19 Feb 2014 13:12:51 -0500 From: "Frank Ch. Eigler" To: Chandana De Silva Cc: pcp@oss.sgi.com Subject: Re: Detecting of a host is being logged by pmlogger Message-ID: <20140219181251.GD6516@redhat.com> X-ASG-Orig-Subj: Re: Detecting of a host is being logged by pmlogger References: <530437C7.4040900@desilva.id.au> <5304EFA7.3030804@desilva.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5304EFA7.3030804@desilva.id.au> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392833574 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - > I have a central pmlogger server. > > On a normal host, I need to detect if the host is being logged by the > remote pmlogger, and if not send a message to the remote logger to start > logging me. This is not quite but close to the scenario supported by the pmcd avahi-announcement & pmmgr discovery machinery: where pmcd's come and go at the local network; a central server runs pmmgr to periodically look for pmcd's to attach pmlogger and/or pmie's to. pmmgr can find hosts based upon direct listing of host-names / IP addresses, or avahi mdns, and will soon grow active network-scanning. The only missing bit there is for a pmcd host to announce its existence actively, but through some means other than avahi (for sites where avahi is not installed or applicable). I've been thinking about a DNS- or IP-multicast-based method to do that. Or add SLP to the mix. But anyway, you might find pmmgr (esp. the version coming out in 3.9.0) may do the job for you, without any extra scripting; and future versions should do it with even less configuration. > I am assuming that pmcd knows it's clients, and was hoping that it > can tell me. (pmcd can only tell you what its clients told it, which may not be accurate/useful.) - FChE From chandana@desilva.id.au Wed Feb 19 13:10:05 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id BF96E7FBD for ; Wed, 19 Feb 2014 13:10:05 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id A4BA88F807A for ; Wed, 19 Feb 2014 11:10:02 -0800 (PST) X-ASG-Debug-ID: 1392836997-04cb6c6de05bdfb0001-S8gJnT Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by cuda.sgi.com with ESMTP id XwyFjQ7Fu34kZ4lU (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 19 Feb 2014 11:09:57 -0800 (PST) X-Barracuda-Envelope-From: chandana@desilva.id.au X-Barracuda-Apparent-Source-IP: 204.13.248.66 Received: from ec2-54-252-74-219.ap-southeast-2.compute.amazonaws.com ([54.252.74.219] helo=mail.desilva.id.au) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1WGCWr-00091j-4T; Wed, 19 Feb 2014 19:09:57 +0000 Received: from [192.168.1.135] (d211-31-205-134.sun802.vic.optusnet.com.au [211.31.205.134]) by mail.desilva.id.au (Postfix) with ESMTPSA id D505324305; Wed, 19 Feb 2014 19:09:54 +0000 (UTC) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 54.252.74.219 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19KAp/YXCBPBwltZx8h7t5QwdJwVAmHYLw= Message-ID: <53050182.2090703@desilva.id.au> Date: Thu, 20 Feb 2014 06:09:54 +1100 From: Chandana De Silva Reply-To: chandana@desilva.id.au User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: pcp@oss.sgi.com Subject: Re: Detecting of a host is being logged by pmlogger References: <530437C7.4040900@desilva.id.au> <5304EFA7.3030804@desilva.id.au> <20140219181251.GD6516@redhat.com> X-ASG-Orig-Subj: Re: Detecting of a host is being logged by pmlogger In-Reply-To: <20140219181251.GD6516@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mho-03-ewr.mailhop.org[204.13.248.66] X-Barracuda-Start-Time: 1392836997 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145288 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header I have been watching the avahi stuff. However, I needed this functionality in September 2013, and have a working kludge (in production) where the client announces itself to the pmlogger server via a simple script sitting behind xinetd on the pmlogger server. This is done via puppet, and I currently have a semaphore file to prevent the client announcing itself more than once. Trying to use pminfo -ft pmcd.client.whoami was a way to try and improve this. Once 3.9.0 is out, I will work on using pmmgr. Chandana On 20/02/14 05:12, Frank Ch. Eigler wrote: > But anyway, you might find pmmgr (esp. the version coming out in > 3.9.0) may do the job for you, without any extra scripting; and future > versions should do it with even less configuration. From kenj@internode.on.net Wed Feb 19 13:58:40 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id D20E87FF6 for ; Wed, 19 Feb 2014 13:58:40 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id B27C38F807A for ; Wed, 19 Feb 2014 11:58:40 -0800 (PST) X-ASG-Debug-ID: 1392839917-04bdf00fc91922e0001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id aTTAjI8Wsg5K58hi for ; Wed, 19 Feb 2014 11:58:38 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgdAF0MBVN20aH1PGdsb2JhbAANTItRtUODBoEyAwEBAQE4gloBAQEEOEARCxgJFg8JAwIBAgExFBMIAQGzc6JHF45rFoQiAQOuFQ Received: from ppp118-209-161-245.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.161.245]) by ipmail06.adl6.internode.on.net with ESMTP; 20 Feb 2014 06:28:37 +1030 Message-ID: <53050D07.8080206@internode.on.net> Date: Thu, 20 Feb 2014 06:59:03 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Re: [pcp] datetime enhancements References: <53042BF5.5070704@redhat.com> X-ASG-Orig-Subj: Re: [pcp] datetime enhancements In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1392839917 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145290 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 20/02/14 04:06, Frank Ch. Eigler wrote: > > scox wrote: > >> QA output created by 751 >> "start " 2014-02-17 10:08:50 >> "end " 2014-02-27 11:28:50 >> [...] >> "+1minute" 2014-02-17 10:09:50 >> "-1minute" 2014-02-27 11:27:50 >> [...] > > Where does the logic come in that additive or subtractive > time intevals would need to be relative to the (archive?) > start/end times vs. the actual current time? It has always been so when the context is an archive ... Stan's output is from a formative QA test where an archive context is the only thing that is deterministic. From kenj@internode.on.net Wed Feb 19 15:49:17 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E23C87F83 for ; Wed, 19 Feb 2014 15:49:16 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 6107AAC004 for ; Wed, 19 Feb 2014 13:49:13 -0800 (PST) X-ASG-Debug-ID: 1392846550-04cbb00c295c8640001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id rtYnlrYc2xVqUNzf for ; Wed, 19 Feb 2014 13:49:10 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au9SAGImBVN20aH1PGdsb2JhbAANTIM+iBOiU5V4gTMDAQEBATiCWgEBAQR4EQsYCRYPCQMCAQIBMRQTCAEBs3qiQReOaxaEIgSuFQ Received: from ppp118-209-161-245.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.161.245]) by ipmail06.adl6.internode.on.net with ESMTP; 20 Feb 2014 08:19:10 +1030 Message-ID: <530526F1.9020004@internode.on.net> Date: Thu, 20 Feb 2014 08:49:37 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Re: [pcp] Detecting of a host is being logged by pmlogger References: <530437C7.4040900@desilva.id.au> <255091837.10539721.1392785738351.JavaMail.zimbra@redhat.com> <53046AFB.7080007@desilva.id.au> <1466910430.10900672.1392806066557.JavaMail.zimbra@redhat.com> <5304EF81.5060902@desilva.id.au> X-ASG-Orig-Subj: Re: [pcp] Detecting of a host is being logged by pmlogger In-Reply-To: <5304EF81.5060902@desilva.id.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1392846550 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=DOMAIN_4U2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145293 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 DOMAIN_4U2 URI: Domain name containing a "4u" variant On 20/02/14 04:53, Chandana De Silva wrote: > No luck > > ... > $ pminfo -ft pmcd.client.whoami > > pmcd.client.whoami [optional identification information for clients of pmcd] > inst [0 or "0"] value "hr1.m4u.com.au (192.168.7.155) pmie -b -h local: -l /var/log/pcp/pmie/hr1.m4u.com.au/healthstate.log -c healthstate.pmie" > inst [3 or "3"] value "hr1.m4u.com.au (192.168.7.155) pmie -b -h local: -l /var/log/pcp/pmie/hr1.m4u.com.au/config.linux.log -c config.linux" > inst [12 or "12"] value "hr1.m4u.com.au (192.168.7.155) pmie -b -h local: -l /var/log/pcp/pmie/hr1.m4u.com.au/pmie.log -c config.default" > inst [13 or "13"] value "" > inst [16 or "16"] value "" One of the empty instances is pminfo, not sure about the other one. How old is the pmlogger version on the system doing the logging? (this was added with the -m option to pmlogger in Aug 2011 so would have escaped in PCP 2.5.9 or later). For my test case, on the system being logged ... kenj@vm04:~$ pminfo -f pmcd.client.whoami pmcd.client.whoami inst [1 or "1"] value "bozo.localdomain (192.168.1.100) pmlogger -h vm04 -r -T24h10m -c config.default -m pmlogger_check 20140220.08.23" inst [4 or "4"] value "vm04.localdomain (192.168.1.204) pmlogger -P -c config.default -m pmlogger_check 20140220.08.25" inst [7 or "7"] value "vm04.localdomain (192.168.1.204) pmie -b -h vm04 -l /var/log/pcp/pmie/vm04/pmie.log -c config.default" inst [8 or "8"] value "" (inst 1 is our happy camper) And on the system where pmlogger is running ... kenj@bozo:~$ ps -ef | grep 'pmlogger.*vm0[4]' pcp 4588 3530 0 08:23 pts/23 00:00:00 pmlogger -h vm04 -r -T24h10m -c config.default -m pmlogger_check 20140220.08.23 From nscott@redhat.com Wed Feb 19 21:46:09 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C533E7FB2 for ; Wed, 19 Feb 2014 21:46:09 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 53B54AC008 for ; Wed, 19 Feb 2014 19:46:08 -0800 (PST) X-ASG-Debug-ID: 1392867963-04cb6c6de15e3400001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id xgh3eu7QDjqr9NyR for ; Wed, 19 Feb 2014 19:46:03 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1K3k37d028963 for ; Wed, 19 Feb 2014 22:46:03 -0500 Date: Wed, 19 Feb 2014 22:46:02 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp@oss.sgi.com Message-ID: <1346949218.12123345.1392867962918.JavaMail.zimbra@redhat.com> In-Reply-To: <913011450.12123309.1392867947639.JavaMail.zimbra@redhat.com> Subject: pcp-gui updates: pmchart MIME-Version: 1.0 X-ASG-Orig-Subj: pcp-gui updates: pmchart Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp-gui updates: pmchart Thread-Index: 1X4ni0F+qMTGfI/liPDKN6/eeJLL1w== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392867963 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC5_SA210e, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145303 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC5_SA210e Custom Rule SA210e Changes committed to git://oss.sgi.com/pcp/pcp-gui.git dev doc/CHANGES | 9 ++++ src/chart/chartdialog.cpp | 2 - src/chart/main.cpp | 1 src/chart/searchdialog.cpp | 83 +++++++++++++++++++++++++++++++-------------- src/chart/searchdialog.ui | 41 ++++++++++++++++++---- 5 files changed, 103 insertions(+), 33 deletions(-) commit 76f5a10722160dc80f5629e9d6588fe0dee50521 Author: Nathan Scott Date: Thu Feb 20 14:44:52 2014 +1100 Improve pmchart metric selection with multiple hosts For the multi-host case, do not expand all namespace trees all at once in the New/Edit Chart dialogs, as it results in user interface clutter. Just show the top level hosts, at first, so the user can choose where navigation should begin and so they have a clear view of available hosts. When many hosts (5+) are in use, this becomes a massive aid to the metric selection process. commit 78c865770be0240605c0d579852e45a92665b7ab Author: Nathan Scott Date: Thu Feb 20 14:39:34 2014 +1100 Fix botch in getopts handling causing local context creation always commit efe837cff6d77c0d67ee8ab5815448fe3cc9f195 Author: Nathan Scott Date: Thu Feb 20 14:24:22 2014 +1100 Improvements to the pmchart metric searching capabilities Update pmchart Metric Search dialog to display hosts also, for all matching search results. Handy for cluster monitoring. Add to the UI and search logic to allow regular expression matching on host names, in addition to metric and instance names. Resolves Red Hat bug #1066175. From nscott@redhat.com Wed Feb 19 23:42:39 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id D65CA7F7E for ; Wed, 19 Feb 2014 23:42:39 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id AF3F9304039 for ; Wed, 19 Feb 2014 21:42:36 -0800 (PST) X-ASG-Debug-ID: 1392874952-04bdf00fca1b8b80001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 6JAAD1T0g0sj5d3v for ; Wed, 19 Feb 2014 21:42:32 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1K5gV7h028733; Thu, 20 Feb 2014 00:42:31 -0500 Date: Thu, 20 Feb 2014 00:42:31 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Dave Brolley Cc: pcp@oss.sgi.com Message-ID: <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> In-Reply-To: <5304D039.9010708@redhat.com> References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> Subject: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Thread-Index: h1P6VH1jiKFK93zgFtLgLX8a0psSRw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392874952 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145305 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > [...] > On my system, PCP_TMP_DIR is /var/lib/pcp/tmp, which is where the > pmlogger port map file is kept, and has the same issue as PCP_RUN_DIR, > i.e. not writable by normal users. *nod*, yep, understood. > I think that ~/.pcp/pmlogger would be a good place. The problem (which I failed to get across :) is that local pmloggers are already writing to that location. We would end up mixing up log folios, per-host subdirectories, and so on with these new PID files. Which would likely end in occassional wierd namespace conflicts, and generally make management of these files more difficult. Hence, the suggestion of ~/.pcp/tmp/pmlogger mirroring (a little, wrt the suffix) the layout we're using for the system loggers port map. > I don't see an existing environment variable for ~/.pcp. Systemtap uses > SYSTEMTAPDIR, but PCPDIR doesn't seem to fit convention. How about > PCP_USER_DIR. Any other suggestions? Its $HOME/.pcp (aka QDir::homePath().append(".pcp") in the Qt code). cheers. -- Nathan From dak-unpriv@franck.debian.org Thu Feb 20 02:37:20 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 306247FB8 for ; Thu, 20 Feb 2014 02:37:20 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 09670304093 for ; Thu, 20 Feb 2014 00:37:19 -0800 (PST) X-ASG-Debug-ID: 1392885434-04bdf00fca1c4200001-S8gJnT Received: from franck.debian.org (franck.debian.org [138.16.160.12]) by cuda.sgi.com with ESMTP id F5PqxXAlHrJFgX78 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Feb 2014 00:37:15 -0800 (PST) X-Barracuda-Envelope-From: dak-unpriv@franck.debian.org X-Barracuda-Apparent-Source-IP: 138.16.160.12 Received: from dak-unpriv by franck.debian.org with local (Exim 4.80) (envelope-from ) id 1WGP85-0001wA-To for pcp@oss.sgi.com; Thu, 20 Feb 2014 08:37:13 +0000 To: pcp@oss.sgi.com From: Debian FTP Masters Subject: Processing of pcp-gui_1.5.12_i386.changes Date: Thu, 20 Feb 2014 08:37:13 +0000 X-ASG-Orig-Subj: Processing of pcp-gui_1.5.12_i386.changes X-Debian: DAK X-DAK: DAK Precedence: bulk Auto-Submitted: auto-generated X-Debian-Package: pcp-gui Message-Id: Sender: unprivileged ftp-master role account X-Barracuda-Connect: franck.debian.org[138.16.160.12] X-Barracuda-Start-Time: 1392885435 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145309 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- pcp-gui_1.5.12_i386.changes uploaded successfully to localhost along with the files: pcp-gui_1.5.12.dsc pcp-gui_1.5.12.tar.xz pcp-gui_1.5.12_i386.deb pcp-doc_1.5.12_all.deb pcp-gui-testsuite_1.5.12_i386.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) From dak-unpriv@franck.debian.org Thu Feb 20 02:47:21 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id BAFCD7FBA for ; Thu, 20 Feb 2014 02:47:21 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 4C7E7AC008 for ; Thu, 20 Feb 2014 00:47:18 -0800 (PST) X-ASG-Debug-ID: 1392886036-04cbb00c2a5ef8d0001-S8gJnT Received: from franck.debian.org (franck.debian.org [138.16.160.12]) by cuda.sgi.com with ESMTP id OSM7oLo8oquc0wDX (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Feb 2014 00:47:17 -0800 (PST) X-Barracuda-Envelope-From: dak-unpriv@franck.debian.org X-Barracuda-Apparent-Source-IP: 138.16.160.12 Received: from dak-unpriv by franck.debian.org with local (Exim 4.80) (envelope-from ) id 1WGPHo-0002km-Hg for pcp@oss.sgi.com; Thu, 20 Feb 2014 08:47:16 +0000 To: pcp@oss.sgi.com From: Debian FTP Masters Subject: Processing of pcp_3.9.0_i386.changes Date: Thu, 20 Feb 2014 08:47:16 +0000 X-ASG-Orig-Subj: Processing of pcp_3.9.0_i386.changes X-Debian: DAK X-DAK: DAK Precedence: bulk Auto-Submitted: auto-generated X-Debian-Package: pcp Message-Id: Sender: unprivileged ftp-master role account X-Barracuda-Connect: franck.debian.org[138.16.160.12] X-Barracuda-Start-Time: 1392886037 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145309 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- pcp_3.9.0_i386.changes uploaded successfully to localhost along with the files: pcp_3.9.0.dsc pcp_3.9.0.tar.xz pcp_3.9.0_i386.deb pcp-conf_3.9.0_i386.deb libpcp3-dev_3.9.0_i386.deb libpcp3_3.9.0_i386.deb libpcp-gui2-dev_3.9.0_i386.deb libpcp-gui2_3.9.0_i386.deb libpcp-mmv1-dev_3.9.0_i386.deb libpcp-mmv1_3.9.0_i386.deb libpcp-pmda3-dev_3.9.0_i386.deb libpcp-pmda3_3.9.0_i386.deb libpcp-trace2-dev_3.9.0_i386.deb libpcp-trace2_3.9.0_i386.deb libpcp-import1-dev_3.9.0_i386.deb libpcp-import1_3.9.0_i386.deb python-pcp_3.9.0_i386.deb libpcp-pmda-perl_3.9.0_i386.deb libpcp-import-perl_3.9.0_i386.deb libpcp-logsummary-perl_3.9.0_i386.deb libpcp-mmv-perl_3.9.0_i386.deb pcp-import-sar2pcp_3.9.0_all.deb pcp-import-mrtg2pcp_3.9.0_all.deb pcp-import-sheet2pcp_3.9.0_all.deb pcp-import-iostat2pcp_3.9.0_all.deb pcp-import-collectl2pcp_3.9.0_i386.deb pcp-testsuite_3.9.0_i386.deb pcp-manager_3.9.0_i386.deb pcp-webapi_3.9.0_i386.deb Greetings, Your Debian queue daemon (running on host franck.debian.org) From pcp-announce-bounces@oss.sgi.com Thu Feb 20 03:17:40 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RP_MATCHES_RCVD autolearn=unavailable version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from oss.sgi.com (localhost [IPv6:::1]) by oss.sgi.com (Postfix) with ESMTP id 470097FE6; Thu, 20 Feb 2014 03:17:40 -0600 (CST) X-Original-To: pcp-announce@oss.sgi.com Delivered-To: pcp-announce@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 8D9E87F7D for ; Thu, 20 Feb 2014 03:17:37 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 0EC2BAC003 for ; Thu, 20 Feb 2014 01:17:36 -0800 (PST) X-ASG-Debug-ID: 1392887833-04cb6c6de05f6e40001-87ZIJf Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id iyEFS4PrBScqxp8X for ; Thu, 20 Feb 2014 01:17:14 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1K9HA7v019280 for ; Thu, 20 Feb 2014 04:17:10 -0500 Date: Thu, 20 Feb 2014 04:17:10 -0500 (EST) From: Nathan Scott To: pcp-announce@oss.sgi.com Message-ID: <2120528552.12473588.1392887830274.JavaMail.zimbra@redhat.com> In-Reply-To: <170444574.12452469.1392886897834.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 X-ASG-Orig-Subj: Performance Co-Pilot releases - pcp-3.9.0 and pcp-gui-1.5.12 X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Performance Co-Pilot releases - pcp-3.9.0 and pcp-gui-1.5.12 Thread-Index: SJxRuLFOYf9ToojfUZ4ManHFhZ4oVw== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392887833 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145311 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Subject: [pcp-announce] Performance Co-Pilot releases - pcp-3.9.0 and pcp-gui-1.5.12 X-BeenThere: pcp-announce@oss.sgi.com X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Nathan Scott List-Id: pcp announcements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pcp-announce-bounces@oss.sgi.com Sender: pcp-announce-bounces@oss.sgi.com Hi all, It's been a busy few weeks since the last release, and shiny new PCP and PCP GUI packages are now available for download! This PCP release introduces some packaging changes, and the 3.8 -> 3.9 version number change is to reflect this. There are new rpm and deb packages for pcp-conf, pcp-manager and pcp-webapi. This separates configuration from the libraries (primarily for multilib support) and some daemons have moved into their own little packages. There is new Python module documentation in the Programmers Guide, and several new pmchart features and fixes - so it is well worth upgrading everything, right away. :^) http://oss.sgi.com/projects/pcp/ ftp://oss.sgi.com/projects/pcp/download/ pcp-3.9.0 (19 February 2014) - Packaging changes for multilib pcp-libs{-devel},pcp-conf - Packaging changes for pcp-manager and pcp-webapi split - pmmgr: signal-response improvements - pmmgr: add pmlogmerge-granular mode - pmmgr: pmlogrewrite support - pmmgr: latency-based tie-break for multi-URL target pmcds - pmmgr.1 man page: outline archiving strategy tradeoffs - pmdalinux: s390x platform issues in /proc/cpuinfo parser - pmdalinux: valgrind fix for /proc/stat parser - pmdagluster: improvements to multiple volume handling - pmdagluster: support for additional file operations - pmlogextract: record handling fix - pmdas: further robustness improvements to dynamic names - pmdas: Install scripts can run even when pmcd is stopped - pmdanfsclient: add source code (not yet enabled in build), thanks to Ben Myers - pcp-archive.5 man page: new, documents on-disk log format - pmdammv: fix sigsegv when no MMV tempdir is present - pmclient: updated to match the Programmers Guide examples - pmapi.py: fix python interface to pmLocaltime and pmCtime - debian: use autotools-dev to update config.{sub,guess}, thanks to Logan Rosen - pmdumplog: add a -x option for extended timestamp reports - pmie: fix count_* operators with dynamic instance domains - pmie: fix fetch logic with dynamic instance domains - testsuite: ensure pcpqa account creation does not warn - testsuite: numerous new tests, updates to existing tests pcp-gui 1.5.12 (19 February 2014) - Updates to the Programmers Guide to cover Python modules - Fix removal of plots from a chart with multiple selections - Fix pmchart window resizing on chart deletion and title changes - Improvements to Edit Chart dialog plot deletion and later re-animation - Ensure correct pmContext is used for several libqmc calls - Support full hostname dynamic expansion via %H, analagous to the existing short hostname dynamic expansion via %h, for chart titles. - Fix %i expansion in pmchart plot legend; during the File -> Save View menu option this plot wildcard was not being preserved. - Extend the wildcard set for plot legends - full and short variants for instances, metrics and hosts now exist, with the heuristics used for shortening described in pmchart(1). - Update pmchart Metric Search dialog to display hosts also, for all matching search results. - Add to the UI and search logic to allow regular expression matching on host names, in addition to metric and instance names. - Improve pmchart metric selection with multiple hosts - for this case, do not expand all namespace trees all at once, it results in UI clutter. Just show the top level hosts, initially, so the user can choose where navigation starts. Enjoy! -- Nathan _______________________________________________ pcp-announce mailing list pcp-announce@oss.sgi.com http://oss.sgi.com/mailman/listinfo/pcp-announce From envelope@ftp-master.debian.org Thu Feb 20 03:37:23 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id ED8F57F7C for ; Thu, 20 Feb 2014 03:37:22 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7ED66AC004 for ; Thu, 20 Feb 2014 01:37:22 -0800 (PST) X-ASG-Debug-ID: 1392889037-04cb6c6de25f8010001-S8gJnT Received: from franck.debian.org (franck.debian.org [138.16.160.12]) by cuda.sgi.com with ESMTP id zBPxmfvaUaQGK8xg (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Feb 2014 01:37:17 -0800 (PST) X-Barracuda-Envelope-From: envelope@ftp-master.debian.org X-Barracuda-Apparent-Source-IP: 138.16.160.12 Received: from dak by franck.debian.org with local (Exim 4.80) (envelope-from ) id 1WGQ4C-0006El-PB; Thu, 20 Feb 2014 09:37:16 +0000 From: Debian FTP Masters To: PCP Development Team , Nathan Scott X-DAK: dak process-upload X-Debian: DAK X-Debian-Package: pcp Precedence: bulk Auto-Submitted: auto-generated MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: pcp_3.9.0_i386.changes is NEW Message-Id: X-ASG-Orig-Subj: pcp_3.9.0_i386.changes is NEW Sender: Archive Administrator Date: Thu, 20 Feb 2014 09:37:16 +0000 X-Barracuda-Connect: franck.debian.org[138.16.160.12] X-Barracuda-Start-Time: 1392889037 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145311 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- binary:pcp-webapi is NEW. binary:pcp-conf is NEW. binary:pcp-manager is NEW. Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. From envelope@ftp-master.debian.org Thu Feb 20 03:37:34 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 4E6B07FAF for ; Thu, 20 Feb 2014 03:37:34 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 36F0F8F8078 for ; Thu, 20 Feb 2014 01:37:31 -0800 (PST) X-ASG-Debug-ID: 1392889050-04cbb00c2a5f2440001-S8gJnT Received: from franck.debian.org (franck.debian.org [138.16.160.12]) by cuda.sgi.com with ESMTP id DBYTVmjGAdx6DJbF (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Feb 2014 01:37:30 -0800 (PST) X-Barracuda-Envelope-From: envelope@ftp-master.debian.org X-Barracuda-Apparent-Source-IP: 138.16.160.12 Received: from dak by franck.debian.org with local (Exim 4.80) (envelope-from ) id 1WGQ4P-0006Nm-Vi; Thu, 20 Feb 2014 09:37:29 +0000 From: Debian FTP Masters To: PCP Development Team , Nathan Scott X-DAK: dak process-upload X-Debian: DAK X-Debian-Package: pcp-gui Precedence: bulk Auto-Submitted: auto-generated MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: pcp-gui_1.5.12_i386.changes ACCEPTED into unstable Message-Id: X-ASG-Orig-Subj: pcp-gui_1.5.12_i386.changes ACCEPTED into unstable Sender: Archive Administrator Date: Thu, 20 Feb 2014 09:37:29 +0000 X-Barracuda-Connect: franck.debian.org[138.16.160.12] X-Barracuda-Start-Time: 1392889050 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145311 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Wed, 19 Feb 2014 14:05:29 +1100 Source: pcp-gui Binary: pcp-gui pcp-doc pcp-gui-testsuite Architecture: source i386 all Version: 1.5.12 Distribution: unstable Urgency: low Maintainer: PCP Development Team Changed-By: Nathan Scott Description: pcp-doc - Documentation and tutorial for the Performance Co-Pilot pcp-gui - Visualisation tools for the Performance Co-Pilot toolkit pcp-gui-testsuite - Performance Co-Pilot (PCP) GUI Test Suite Changes: pcp-gui (1.5.12) unstable; urgency=low . * New pcp-gui release (see doc/CHANGES for details). Checksums-Sha1: e0a7577cdf9e852abe86ef36cedf9e29fad62032 1002 pcp-gui_1.5.12.dsc 8113427caed1b3ecf8c33e6c6be5ea6201153789 4400456 pcp-gui_1.5.12.tar.xz c0adc2a76b657d585622dab03ddcb4ed40acd692 875618 pcp-gui_1.5.12_i386.deb 5efda890f05fb4bbbd56cee4d1c2496c03f78920 2904680 pcp-doc_1.5.12_all.deb 6cdb4465c378aef8a820b346a978a4d80f35c985 247458 pcp-gui-testsuite_1.5.12_i386.deb Checksums-Sha256: 50f338b2ae8ac3d32c1d68bf061383aa8f49e052cb1e459950aaa254ac03f363 1002 pcp-gui_1.5.12.dsc eac6ab6eb91b06b3c64d9778b2c6573dfaef0a2f8b0915ae52fde56cff62c584 4400456 pcp-gui_1.5.12.tar.xz a3711d4a5204c4281d8a7484446c9f9f934e20dcbed8ade2ff5441256d9938c1 875618 pcp-gui_1.5.12_i386.deb 11cd4dce45bc2bbe1b84b39c657871a824e93b1619d746f9c80df0cfdd6c8164 2904680 pcp-doc_1.5.12_all.deb 5c0cde78fd3340e9ffa9ac1093d00f4bd0d70e324f5590f1fb87ca16c9568d74 247458 pcp-gui-testsuite_1.5.12_i386.deb Files: d85cb459284beabcbe7dd00f13081f5c 1002 utils extra pcp-gui_1.5.12.dsc f3e536698dc38a99a3a20726a08cbde6 4400456 utils extra pcp-gui_1.5.12.tar.xz ad9048b371241332b6a10478dd5c133a 875618 utils extra pcp-gui_1.5.12_i386.deb f6e172d22ea2e6e65c1817baaa441083 2904680 doc extra pcp-doc_1.5.12_all.deb 32528188b6c5552c1511310d773b3664 247458 utils extra pcp-gui-testsuite_1.5.12_i386.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlMFjiIACgkQm8fl3HSIa2NNAgCgrL0z/rAiSveJsfPMMK4O1NB+ T7IAn1DTa7dpHQb9K3FfbHviSr4ho2lO =58Y0 -----END PGP SIGNATURE----- Thank you for your contribution to Debian. From brolley@redhat.com Thu Feb 20 08:36:03 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id CF2E47FC0 for ; Thu, 20 Feb 2014 08:36:03 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id AEC548F8050 for ; Thu, 20 Feb 2014 06:36:03 -0800 (PST) X-ASG-Debug-ID: 1392906959-04cb6c6de260e290001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 5IjSoxWvRkiiIEhR for ; Thu, 20 Feb 2014 06:35:59 -0800 (PST) X-Barracuda-Envelope-From: brolley@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1KEZwJg011838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Feb 2014 09:35:59 -0500 Received: from [10.15.16.178] (dhcp-10-15-16-178.yyz.redhat.com [10.15.16.178]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1KEZvFK023383; Thu, 20 Feb 2014 09:35:58 -0500 Message-ID: <530612EC.8020206@redhat.com> Date: Thu, 20 Feb 2014 09:36:28 -0500 From: Dave Brolley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Scott CC: pcp@oss.sgi.com Subject: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc In-Reply-To: <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392906959 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On 02/20/2014 12:42 AM, Nathan Scott wrote: > > ----- Original Message ----- >> I think that ~/.pcp/pmlogger would be a good place. > The problem (which I failed to get across :) is that local pmloggers > are already writing to that location. We would end up mixing up log > folios, per-host subdirectories, and so on with these new PID files. > Which would likely end in occassional wierd namespace conflicts, and > generally make management of these files more difficult. > > Hence, the suggestion of ~/.pcp/tmp/pmlogger mirroring (a little, wrt > the suffix) the layout we're using for the system loggers port map. The actual full name of the socket would be ~/.pcp/pmlogger/pmlogger..socket. I don't see how this could end up with a namespace conflict. Could you perhaps give an example? There is some redundancy there. It could be shortened to ~/.pcp/pmlogger/.socket. Have said that, I'm not attached to my choice, and it would be easy to add the extra tmp component. > >> I don't see an existing environment variable for ~/.pcp. Systemtap uses >> SYSTEMTAPDIR, but PCPDIR doesn't seem to fit convention. How about >> PCP_USER_DIR. Any other suggestions? > Its $HOME/.pcp (aka QDir::homePath().append(".pcp") in the Qt code). OK. Overnight testing has revealed no qa issues. Once we agree on the location of the socket, I can push the changes. Dave From fche@redhat.com Thu Feb 20 08:56:22 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 789D87FC0 for ; Thu, 20 Feb 2014 08:56:22 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 1B29EAC008 for ; Thu, 20 Feb 2014 06:56:21 -0800 (PST) X-ASG-Debug-ID: 1392908180-04bdf00fca1df360001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id pSZTANtB7Qz4GvQQ for ; Thu, 20 Feb 2014 06:56:21 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1KEuGLo012761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Feb 2014 09:56:16 -0500 Received: from fche.csb (vpn-236-177.phx2.redhat.com [10.3.236.177]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1KEuFs6030458; Thu, 20 Feb 2014 09:56:16 -0500 Received: by fche.csb (Postfix, from userid 2569) id 57BAF5812D; Thu, 20 Feb 2014 09:56:15 -0500 (EST) To: Ken McDonell Cc: pcp@oss.sgi.com Subject: Re: datetime enhancements References: <53042BF5.5070704@redhat.com> <53050D07.8080206@internode.on.net> X-ASG-Orig-Subj: Re: datetime enhancements From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 20 Feb 2014 09:56:15 -0500 In-Reply-To: <53050D07.8080206@internode.on.net> (Ken McDonell's message of "Thu, 20 Feb 2014 06:59:03 +1100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392908181 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 kenj wrote: > [...] >> Where does the logic come in that additive or subtractive >> time intevals would need to be relative to the (archive?) >> start/end times vs. the actual current time? > > It has always been so when the context is an archive ... Stan's output > is from a formative QA test where an archive context is the only thing > that is deterministic. Understood. One can also see a need also to use relative-to-now types of queries against archives, like "play back stats X from exactly 24 hours ago"; would that be covered by the -O/-S "@TIMESTR" syntax? - FChE From yaronriv@inter.net.il Thu Feb 20 10:55:00 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,T_MANY_HDRS_LCASE autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id CBBEA7FA1 for ; Thu, 20 Feb 2014 10:55:00 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9C848304089 for ; Thu, 20 Feb 2014 08:54:57 -0800 (PST) X-ASG-Debug-ID: 1392915291-04bdf00fc01ec870001-S8gJnT Received: from dist2.012.net.il ([192.117.60.4]) by cuda.sgi.com with ESMTP id wt26ebjALZfQakBR for ; Thu, 20 Feb 2014 08:54:51 -0800 (PST) X-Barracuda-Envelope-From: yaronriv@inter.net.il X-Barracuda-Apparent-Source-IP: 192.117.60.4 Received: from IIS-ZELDA.WEB-DOMAIN2 ([192.117.172.100]) by a-dist2.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N1B007YQ0BEJ5C0@a-dist2.012.net.il> for pcp@oss.sgi.com; Thu, 20 Feb 2014 18:54:50 +0200 (IST) Received: from IISZELDA ([127.0.0.1]) by IIS-ZELDA.WEB-DOMAIN2 with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Feb 2014 18:54:49 +0200 Date: Thu, 20 Feb 2014 18:54:49 +0200 From: =?windows-1255?B?7vrw5CDn5eHkIOzk5fjp7Q==?= Subject: =?windows-1255?B?5PH0+CDy6ePl4yDp7OPp7SDs5Pbs5+Q=?= X-012-Sender: hosting@012.net.il X-ASG-Orig-Subj: =?windows-1255?B?5PH0+CDy6ePl4yDp7OPp7SDs5Pbs5+Q=?= To: pcp@oss.sgi.com Message-id: <67D48E26933A471AA3195B31348E9B08@WEBDOMAIN2> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 X-Mailer: Microsoft CDO for Windows 2000 Content-type: multipart/alternative; boundary="Boundary_(ID_buytR9+b37+I1930NQuuiQ)" Content-class: urn:content-classes:message Importance: normal Priority: normal Thread-topic: =?windows-1255?B?5PH0+CDy6ePl4yDp7OPp7SDs5Pbs5+Q=?= Thread-index: Ac8uXHfAlKsuLuGLTJORLzU6oWdBIQ== Sun-Java-System-SMTP-Warning: Lines longer than SMTP allows found and truncated. X-OriginalArrivalTime: 20 Feb 2014 16:54:49.0798 (UTC) FILETIME=[77C01660:01CF2E5C] X-Barracuda-Connect: UNKNOWN[192.117.60.4] X-Barracuda-Start-Time: 1392915291 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.62 X-Barracuda-Spam-Status: No, SCORE=0.62 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC5_MJ1963, HTML_MESSAGE, RDNS_NONE, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145321 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 HTML_MESSAGE BODY: HTML included in message 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 This is a multi-part message in MIME format. --Boundary_(ID_buytR9+b37+I1930NQuuiQ) Content-type: text/plain; charset=windows-1255 Content-transfer-encoding: base64 6+PpIOz34ewg5+nw7SDg+iDk8fT4ICLy6ePl4yDp7OPp7SDs5Pbs5+QiIOT37On35SDr4O8uDQo8 aHR0cDovL2tpZC1jaGVzcy5jby5pbC9pZHVkL3llbGFkaW1fYm9vay95ZWxhZGltX2Jvb2suaHRt bD4gDQoNCg0K6+Tl+OntLCDr7uX46e0g5evh5eL46e0sIOHp4+nw5SDk6evl7Pog5eTr5ecg7On2 5fgg6ezjIOHy7A0K5+Xx7yDl4Onp+vDl+iDw9Pnp+i4g6ezjIOHy7CDh6Ofl7yDl4+nu5ekg8vbu 6SDi4eXk6e0uIA0K6ezjIOfl9/gg6eXm7SDl7uDl+fgg5O7y5fbhIOzk9uzn5CDl5OL57uQg8vbu 6fouIA0KDQrn5eXp6fog5Ons4+X6IPnsIOTp7OMg+vL24SDg+iDn6enlIOHy+unjIOX64uPp+CDg +iDu5OX65S4gDQru+Ovp4SDh8enx6SDh8un25eEg5ODp+enl+iDk6fDlICL69Onx+iDk7vHl4uzl +iDk8vbu6foiIC0gDQrk4O7l8OQg4enr5ez6IOzk+u7l4+Mg8u0g4Pri+OntIOX3+enp7SDl7O7u +SDp8uPp7SDl7uj45fouIA0KDQoi+vTp8fog5O7x5eLs5fog5PL27un6IiDk6eAg4OfjIO7y7uXj 6SDk+uXl6iD57CDk5Pbs5+QgDQrl5Pjl5efkIOTw9Pnp+i4g7PbjIPr06fH65CDu8eXi7OX6IOTy 9u7p+iDw6fbh5fog+frpIA0K7unl7vDl6eX6IOnx5eMg8OXx9OX6OiANCvDn6fnl+iwg5eT67uPk LiANCunr5ezl+iDg7OQg7vri4fnl+iDh4unsIOTp7OPl+iDl7vbp6ePl+iDg+iDk4OPtIOEi7vDl 8iIgDQr56eXh6ewg4OX65SDs7unu5fkg6fLj6e0sIOT27OfkIOXx6fTl9y4gDQoNCuDqIOzgIPj3 IOD6IOTr7OntIOXk6+XnIOzk+eniIOXs7u75IOny4+ntIODw5SDk7uHl4vjp7SANCvb46evp7SDs 5PLw6fcg5ez0+ucg4PbsIOTp7OMuIO769Pfp4/DlIOLtIOzk8Ofp7CDs5SDg+iANCuTr5ecg5eTk 4fDkIOzh9vIg4Pog5OHn6fjl+iDk8Ovl8OX6LiDu5fH46eX6LCDy5vjkIOzm5ez6IOXx5eHs8OX6 Lg0K4eDs5CDl4fDl+eDp7SDn+eXh6e0g8OXx9OntIPLl8fcg5PH0+CAi4OXu8OX6IOTy6ePl4yIu IA0KDQoNCg0K6+PpIOz34ewg5+nw7SDg+iDk8fT4ICLy6ePl4yDp7OPp7SDs5Pbs5+QiIOT37On3 5SDr4O8uDQo8aHR0cDovL2tpZC1jaGVzcy5jby5pbC9pZHVkL3llbGFkaW1fYm9vay95ZWxhZGlt X2Jvb2suaHRtbD4gDQoNCuns4yD54uPsIPLtIOTl4vDl+iAtIOzl7uMg9uP3DQrp7OMg+eLj7CDy 7SDh6Ofl7yAtIOzl7uMg7OTg7unvDQrp7OMg+eLj7CDy7SDg5OHkIOzl7uMg7ODk5eENCuns4yD5 4uPsIPLtIPLp4+XjIC0g4uPsIOzk9uzn5CDl7OTi+e7kIPL27un6DQoNCg0K+en64vnu5SDr7CDu +eDs5fog7OHr7SDs6OXh5CANCg0K5O746+Yg7PTp+uXnIOTp7OMgKEMpDQoNCvrp4fog4+XgIuwg 5uUg4Onw5CDu8OXo+PogDQrr4+kg7OAg7Pfh7CDj6eXl+OntIOT37On35SDr4O8NCjxodHRwOi8v d3d3LmtpZC1jaGVzcy5jby5pbC9pZHVkL2RlbGV0ZS5odG1sPiANCg0KDQo= --Boundary_(ID_buytR9+b37+I1930NQuuiQ) Content-type: text/html; charset=windows-1255 Content-transfer-encoding: 8BIT îééì îçáøú -

ëãé ì÷áì çéðí àú äñôø "òéãåã éìãéí ìäöìçä" ä÷ìé÷å ëàï.

ëäåøéí, ëîåøéí åëáåâøéí, áéãéðå äéëåìú åäëåç ìéöåø éìã áòì
çåñï åàééúðåú ðôùéú. éìã áòì áèçåï åãéîåé òöîé âáåäéí.
éìã çå÷ø éåæí åîàåùø äîòåöá ìäöìçä åäâùîä òöîéú.

çååééú äéìãåú ùì äéìã úòöá àú çééå áòúéã åúâãéø àú îäåúå.
îøëéá áñéñé áòéöåá äàéùéåú äéðå "úôéñú äîñåâìåú äòöîéú" -
äàîåðä áéëåìú ìäúîåãã òí àúâøéí å÷ùééí åìîîù éòãéí åîèøåú.

"úôéñú äîñåâìåú äòöîéú" äéà àçã îòîåãé äúååê ùì ääöìçä
åäøååçä äðôùéú. ìöã úôéñúä îñåâìåú äòöîéú ðéöáåú ùúé
îéåîðåéåú éñåã ðåñôåú:
ðçéùåú, åäúîãä.
éëåìåú àìä îúâáùåú áâéì äéìãåú åîöééãåú àú äàãí á"îðåò"
ùéåáéì àåúå ìîéîåù éòãéí, äöìçä åñéôå÷.

àê ìà ø÷ àú äëìéí åäëåç ìäùéâ åìîîù éòãéí àðå äîáåâøéí
öøéëéí ìäòðé÷ åìôúç àöì äéìã. îúô÷éãðå âí ìäðçéì ìå àú
äëåç åääáðä ìáöò àú äáçéøåú äðëåðåú. îåñøéåú, òæøä ìæåìú åñåá ìðåú.
ëãé ì÷áì çéðí àú äñôø "òéãåã éìãéí ìäöìçä" ä÷ìé÷å ëàï.

éìã ùâãì òí äåâðåú - ìåîã öã÷
éìã ùâãì òí áèçåï - ìåîã ìäàîéï
éìã ùâãì òí àäáä ìåîã ìàäåá
éìã ùâãì òí òéãåã - âãì ìäöìçä åìäâùîä òöîéú

ùéúâùîå ëì îùàìåú ìáëí ìèåáä

äîøëæ ìôéúåç äéìã (C)

úéáú ãåà"ì æå àéðä îðåèøú
ëãé ìà ì÷áì ãéååøéí ä÷ìé÷å ëàï

--Boundary_(ID_buytR9+b37+I1930NQuuiQ)-- From fche@redhat.com Thu Feb 20 14:18:41 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 546E07FBA for ; Thu, 20 Feb 2014 14:18:41 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id CE0ECAC00C for ; Thu, 20 Feb 2014 12:18:37 -0800 (PST) X-ASG-Debug-ID: 1392927516-04cbb00c28624fe0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id QNZopiV4TW7oGBNI for ; Thu, 20 Feb 2014 12:18:36 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1KKIZig021528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 Feb 2014 15:18:35 -0500 Received: from fche.csb (vpn-236-177.phx2.redhat.com [10.3.236.177]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1KKIZHm015735 for ; Thu, 20 Feb 2014 15:18:35 -0500 Received: by fche.csb (Postfix, from userid 2569) id D6847581C7; Thu, 20 Feb 2014 15:18:34 -0500 (EST) To: pcp@oss.sgi.com Subject: pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> X-ASG-Orig-Subj: pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 20 Feb 2014 15:18:34 -0500 In-Reply-To: <530612EC.8020206@redhat.com> (Dave Brolley's message of "Thu, 20 Feb 2014 09:36:28 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392927516 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - Dave and I got talking about why we're doing AF_UNIX comms for pmlc<->pmlogger at all: it's primarily for securing pmlogger against hostile users. The current patchset doesn't address that aspect, so let's discuss some possibilities while our mental caches are fresh. To secure pmlogger across AF_UNIX, it's not enough to put the sockets into variously owned owned directories. /var/lib/pcp/tmp is currently world-readable, and the socket's own permissions may or may not be factored by the kernel, so potentially any local joe can attach. That's no better than tcp/localhost. With AF_UNIX, we get the connecting client's uid/gid/pid for free, which we pass along for PMAPI authentication purposes within PMCD. I propose pmlogger also use that information to extend the pmlogger ACL language to assert simple predicates like allow unix-uidmatch : all; # allow unix-gidmatch : all; # probably not a good default allow unix : enquire; which we could then put into the default / pmlogconf-generated files. As an aside, the pmlogger acl system has a nice separation of "enquire" vs "all" operations. However, some mutative operations are in the enquire category, but probably shouldn't be: namely "new volume" and "flush". Both these could be misused for denial-of-service, so should be restricted. - FChE From kenj@internode.on.net Thu Feb 20 14:32:30 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id AE8517FC0 for ; Thu, 20 Feb 2014 14:32:30 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8A52A30407F for ; Thu, 20 Feb 2014 12:32:30 -0800 (PST) X-ASG-Debug-ID: 1392928344-04cb6c6de262c470001-S8gJnT Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id ps07qAEi5YxARd3h for ; Thu, 20 Feb 2014 12:32:25 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkdAAxfBlN20aH1PGdsb2JhbAANTItRtU2DBoEnAwEBAQE4gloBAQEEOEABEAsYCRYPCQMCAQIBMRQGDQEHAQG0HqIeF45kB4Q4AQOuFQ Received: from ppp118-209-161-245.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.161.245]) by ipmail06.adl2.internode.on.net with ESMTP; 21 Feb 2014 06:34:51 +1030 Message-ID: <53066001.3060603@internode.on.net> Date: Fri, 21 Feb 2014 07:05:21 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: pcp@oss.sgi.com Subject: Re: datetime enhancements References: <53042BF5.5070704@redhat.com> <53050D07.8080206@internode.on.net> X-ASG-Orig-Subj: Re: datetime enhancements In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1392928345 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145326 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header On 21/02/14 01:56, Frank Ch. Eigler wrote: > > Understood. One can also see a need also to use relative-to-now types > of queries against archives, like "play back stats X from exactly 24 > hours ago"; would that be covered by the -O/-S "@TIMESTR" syntax? Yes, the @ctime-like-string handling was for this purpose, and the "something weird happened at 04:13 last Fri, show me stuff from 04:00 in that archive". Just an aside, the -z option is _really_ useful here when the archive is collected in one timezone and analysed in another timezone. From kenj@internode.on.net Thu Feb 20 15:18:58 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 9AC857FBA for ; Thu, 20 Feb 2014 15:18:58 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 32305AC009 for ; Thu, 20 Feb 2014 13:18:54 -0800 (PST) X-ASG-Debug-ID: 1392931131-04cb6c06cf31a780001-S8gJnT Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id gPm31qOoSuzQi1dN for ; Thu, 20 Feb 2014 13:18:52 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkdAMRwBlN20aH1PGdsb2JhbAANTItRtU2DBoEnAwEBAQE4gloBAQEDAThABgsLGAkWBAsJAwIBAgExFBMIAQGHeas2oh8XjmsWhCIErEOBUg Received: from ppp118-209-161-245.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.161.245]) by ipmail06.adl2.internode.on.net with ESMTP; 21 Feb 2014 07:48:51 +1030 Message-ID: <53067159.9050409@internode.on.net> Date: Fri, 21 Feb 2014 08:19:21 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1392931132 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145327 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 21/02/14 07:18, Frank Ch. Eigler wrote: > ... I > propose pmlogger also use that information to extend the pmlogger ACL > language to assert simple predicates like > > allow unix-uidmatch : all; > # allow unix-gidmatch : all; # probably not a good default > allow unix : enquire; > > which we could then put into the default / pmlogconf-generated files. This looks fine to me. > As an aside, the pmlogger acl system has a nice separation of > "enquire" vs "all" operations. However, some mutative operations are > in the enquire category, but probably shouldn't be: namely "new > volume" and "flush". Both these could be misused for denial-of-service, > so should be restricted. The status quo just seems wrong ... anything that can change the state of pmlogger should not be in the "enquire" class. Shall I fix this? Locking down pmlc is unlikely to have any negative fallout. I believe pmlc use is very rare, probably because I have not managed to convince anyone else that the "value add" proposition for pmlc in the following scenario is real: * pmlogger configured with shallow metric coverage and long sample intervals * pmie looking for badness * pmie rule fires to ... use pmlc to increase metric depth and/or reduce sample interval wait a while use pmlc to return pmlogger to default configuration Even for this scenario, one could use a second pmlogger instance and later merge the two archives with pmlogextract, avoiding pmlc altogether. From nscott@redhat.com Thu Feb 20 15:50:39 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 9CF107F73 for ; Thu, 20 Feb 2014 15:50:39 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 3D359AC009 for ; Thu, 20 Feb 2014 13:50:39 -0800 (PST) X-ASG-Debug-ID: 1392933037-04bdf0083ae5630001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 6bTiLqUAMnP2mD0Z for ; Thu, 20 Feb 2014 13:50:37 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1KLoZna013185; Thu, 20 Feb 2014 16:50:35 -0500 Date: Thu, 20 Feb 2014 16:50:35 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: pcp@oss.sgi.com Message-ID: <187907209.13373325.1392933035206.JavaMail.zimbra@redhat.com> In-Reply-To: <53067159.9050409@internode.on.net> References: <52FE5058.4030702@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> <53067159.9050409@internode.on.net> Subject: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Thread-Index: 5LWBXSvUkBHCP14cbFDwo6RBpKoBzw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392933037 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145329 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > The status quo just seems wrong ... anything that can change the state > of pmlogger should not be in the "enquire" class. Shall I fix this? Yes please! :) > Locking down pmlc is unlikely to have any negative fallout. > > I believe pmlc use is very rare, probably because I have not managed to > convince anyone else that the "value add" proposition for pmlc in the > following scenario is real: The other scenario, where I've seen pmlc used (as in: really used, not a hypothetical scenario) is to query/check "is pmlogger really logging the things its meant to be" - so extending to the "is pmlogger running at all" checks. > * pmlogger configured with shallow metric coverage and long sample intervals > * pmie looking for badness > > * pmie rule fires to ... > use pmlc to increase metric depth and/or reduce sample interval > wait a while > use pmlc to return pmlogger to default configuration *nod* - have never seen this used in the wild FWIW. But, high volume event metric data could make a stronger case for this model, which is potentially much more of a firehose than regular sampled data - so an on/off logging switch is more compelling. > Even for this scenario, one could use a second pmlogger instance and > later merge the two archives with pmlogextract, avoiding pmlc altogether. *nod* - its all a bit manual though, whereas the above is more neatly automated (eg we could enable that sort of thing in a default install if some common situation came up, whereas this latter model would be possibly a little more awkward to integrate). cheers. -- Nathan From fche@redhat.com Thu Feb 20 16:13:49 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 5F4547FAD for ; Thu, 20 Feb 2014 16:13:49 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 4B38330407B for ; Thu, 20 Feb 2014 14:13:46 -0800 (PST) X-ASG-Debug-ID: 1392934425-04cb6c06cf31e0f0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 78fTIoi9NmsKa0jc for ; Thu, 20 Feb 2014 14:13:45 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1KMDg58004939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Feb 2014 17:13:42 -0500 Received: from fche.csb (vpn-236-177.phx2.redhat.com [10.3.236.177]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1KMDgNC000750; Thu, 20 Feb 2014 17:13:42 -0500 Received: by fche.csb (Postfix, from userid 2569) id BEB29582E4; Thu, 20 Feb 2014 17:13:41 -0500 (EST) To: Ken McDonell Cc: pcp@oss.sgi.com Subject: Re: pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> <53067159.9050409@internode.on.net> X-ASG-Orig-Subj: Re: pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 20 Feb 2014 17:13:41 -0500 In-Reply-To: <53067159.9050409@internode.on.net> (Ken McDonell's message of "Fri, 21 Feb 2014 08:19:21 +1100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392934425 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Ken McDonell writes: > [...] I believe pmlc use is very rare, probably because I have not > managed to convince anyone else that the "value add" proposition for > pmlc in the following scenario is real: [...] I very much believe in that scenario! I'm just not sure whether it's best done within pmie vice within a more clever pmlogger. An extra complication is that pmie requires a second connection to pmcd (a temporary one at that, repeatedly suffering startup costs); it cannot piggy-back on an archive being written-to by pmlogger. - FChE From nscott@redhat.com Thu Feb 20 16:56:32 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id C34307FB9 for ; Thu, 20 Feb 2014 16:56:32 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 4A9D7AC002 for ; Thu, 20 Feb 2014 14:56:29 -0800 (PST) X-ASG-Debug-ID: 1392936985-04cb6c6de26358c0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id tXAyfDFKNjezcT1X for ; Thu, 20 Feb 2014 14:56:27 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1KMuP3H026333; Thu, 20 Feb 2014 17:56:25 -0500 Date: Thu, 20 Feb 2014 17:56:25 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: pcp@oss.sgi.com Message-ID: <1760935757.13397936.1392936985421.JavaMail.zimbra@redhat.com> In-Reply-To: References: <52FE5058.4030702@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> Subject: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Thread-Index: mnCo+Sj1k38nSmX1Xb9GIGmjgBipKQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392936987 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145331 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > [...] > To secure pmlogger across AF_UNIX, it's not enough to put the sockets > into variously owned owned directories. /var/lib/pcp/tmp is currently > world-readable, and the socket's own permissions may or may not be Its /var/lib/pcp/tmp/pmlogger though isn't it? We could install that 770 with no trouble, nowadays, I think...? (and likewise for pmie) cheers. -- Nathan From nscott@redhat.com Thu Feb 20 17:09:41 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 6CDE67F53 for ; Thu, 20 Feb 2014 17:09:41 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 112E8AC001 for ; Thu, 20 Feb 2014 15:09:37 -0800 (PST) X-ASG-Debug-ID: 1392937776-04bdf00fca2077c0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 5qHVen2QPJnFeAGV for ; Thu, 20 Feb 2014 15:09:37 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1KN9VW3028568; Thu, 20 Feb 2014 18:09:31 -0500 Date: Thu, 20 Feb 2014 18:09:31 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: Ken McDonell , pcp@oss.sgi.com Message-ID: <2078588943.13402683.1392937771745.JavaMail.zimbra@redhat.com> In-Reply-To: References: <52FE5058.4030702@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> <53067159.9050409@internode.on.net> Subject: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Thread-Index: u0cCbt+NLxGUUccjlecfZbU/0ro0xw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392937776 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145331 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > Ken McDonell writes: > > > [...] I believe pmlc use is very rare, probably because I have not > > managed to convince anyone else that the "value add" proposition for > > pmlc in the following scenario is real: [...] > > I very much believe in that scenario! I'm just not sure whether it's > best done within pmie vice within a more clever pmlogger. An extra > complication is that pmie requires a second connection to pmcd (a > temporary one at that, repeatedly suffering startup costs); The usual model would be local pmie daemon (no temporary connection). I'm not following how its a complication to have a second connection to pmcd...? (relative to the level of complication of pmlogger code that we'd have to consider, which would appear to require a decision making engine like pmie to be built into pmlogger...?). > it cannot piggy-back on an archive being written-to by pmlogger. Can you explain that some more? ("piggy-back" in what way?) The pmlc model is that pmie tells pmlogger what (extra) to log dynamically, via pmlc, so in that sense it is piggy-backing on the existing archive...? cheers. -- Nathan From nscott@redhat.com Thu Feb 20 17:24:30 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 586107F9C for ; Thu, 20 Feb 2014 17:24:30 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id DDEB6AC002 for ; Thu, 20 Feb 2014 15:24:29 -0800 (PST) X-ASG-Debug-ID: 1392938667-04bdf00fc02085a0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id hY4MElpnShC4cYPC for ; Thu, 20 Feb 2014 15:24:28 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1KNORRv017037; Thu, 20 Feb 2014 18:24:27 -0500 Date: Thu, 20 Feb 2014 18:24:27 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Dave Brolley Cc: pcp@oss.sgi.com Message-ID: <1679311501.13409718.1392938667397.JavaMail.zimbra@redhat.com> In-Reply-To: <530612EC.8020206@redhat.com> References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> Subject: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Thread-Index: AD8K2hhiKC0yPzGDdoHqT7kCzCuTgg== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392938668 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145331 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi Dave, ----- Original Message ----- > On 02/20/2014 12:42 AM, Nathan Scott wrote: > > > > ----- Original Message ----- > >> I think that ~/.pcp/pmlogger would be a good place. > > The problem (which I failed to get across :) is that local pmloggers > > are already writing to that location. We would end up mixing up log > > folios, per-host subdirectories, and so on with these new PID files. > > Which would likely end in occassional wierd namespace conflicts, and > > generally make management of these files more difficult. > > > > Hence, the suggestion of ~/.pcp/tmp/pmlogger mirroring (a little, wrt > > the suffix) the layout we're using for the system loggers port map. > The actual full name of the socket would be > ~/.pcp/pmlogger/pmlogger..socket. I don't see how this could end up > with a namespace conflict. Could you perhaps give an example? There is > some redundancy there. It could be shortened to > ~/.pcp/pmlogger/.socket. Have said that, I'm not attached to my > choice, and it would be easy to add the extra tmp component. As long as the name (the basename(1) I mean) is the same as the system variant, its fine by me - although as you mention, yeah, the pmlogger. prefix is redundant under all schemes so I guess I'd prefer it gone. Wrt "namespace conflict", yeah, no specific scenario - just a general vibe that separating permanent files (archives, folios and so on) from temporary rundir type files is a Good Thing generally. One example off the top of my head would be usability in pmchart. When someone browses their local archives in the GUI, looking at ~/.pcp/pmchart/* it'd be a shame for them to have to sort through socket files in there too which would have nothing to do with the task at hand. *shrug*... just seems to make sense to keep 'em apart. I suppose if we managed to lose track of these socket files somehow, & ended up leaving some lying around after pmlogger exited, its easier to cleanup when its a separate directory too. > Overnight testing has revealed no qa issues. Mhmmm, is test 750 passing for you atm? :) I accidentally included my hostname in its output, so it should be failing everywhere else. Sorry 'bout that - will be fixed shortly ... but do you have any other common failures though? (that fail without these new changes, I mean). cheers. -- Nathan From nscott@redhat.com Thu Feb 20 17:47:37 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id EB9067FC8 for ; Thu, 20 Feb 2014 17:47:36 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id E077430406B for ; Thu, 20 Feb 2014 15:47:33 -0800 (PST) X-ASG-Debug-ID: 1392940051-04cbb00c29631880001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id mkfuwztxVePPWTS0 for ; Thu, 20 Feb 2014 15:47:32 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1KNlRDZ003164; Thu, 20 Feb 2014 18:47:27 -0500 Date: Thu, 20 Feb 2014 18:47:27 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" , Dave Brolley , Ken McDonell Cc: pcp@oss.sgi.com Message-ID: <1184965444.13413022.1392940047456.JavaMail.zimbra@redhat.com> In-Reply-To: References: <52FE5058.4030702@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> Subject: Re: [pcp] pmlc access control MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmlc access control Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmlc access control Thread-Index: mHJsBqDsz9Aje2EiPMaQTEARUWqmdw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392940051 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145331 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi guys, ----- Original Message ----- > [...] > With AF_UNIX, we get the connecting client's uid/gid/pid for free, > which we pass along for PMAPI authentication purposes within PMCD. I > propose pmlogger also use that information to extend the pmlogger ACL > language to assert simple predicates like > > allow unix-uidmatch : all; > # allow unix-gidmatch : all; # probably not a good default > allow unix : enquire; > > which we could then put into the default / pmlogconf-generated files. > I wonder if we're over-thinking it - could we simplify things by just insisting that the uid/gid match? The 99.9% case will be user/group pcp/pcp I'd expect ... and the other 0.009% case would be some other regular users pmlc to their own pmlogger. In both cases, it seems to me it'd be perfectly fine to give a fully-authenticated local: style connection read+write access, dispensing with even local host ACLs for that special case. There was another IRC question asked, which I'd really like to see us tackle, and that is how to go about allowing the inet/ipv6 port to be disabled completely if someone wishes (which we may want to make into a default too at some point? IMO we should, once we have local: in). One suggestion would be to add the (missing?!) -p option here, so that firstly we get command-line control over the pmlogger port (in pmlogger I mean - pmlc already supports -p of course). At the moment, we only have env var control (PMLOGGER_PORT), else its the hard-coded port number we start from. Then extend with the ability to use "-p-" and/or "-p 0" and/or "-p-1" meaning "no soup^Wports for you". cheers. -- Nathan From fche@redhat.com Thu Feb 20 17:49:01 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8A01D7FC8 for ; Thu, 20 Feb 2014 17:49:01 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 7B890304070 for ; Thu, 20 Feb 2014 15:49:01 -0800 (PST) X-ASG-Debug-ID: 1392940140-04cb6c6de1638740001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 3Yht1wXLmFbb2jrw for ; Thu, 20 Feb 2014 15:49:00 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1KNmvN4016539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Feb 2014 18:48:57 -0500 Received: from fche.csb (vpn-236-177.phx2.redhat.com [10.3.236.177]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1KNmvsY017089; Thu, 20 Feb 2014 18:48:57 -0500 Received: by fche.csb (Postfix, from userid 2569) id 75C46582E4; Thu, 20 Feb 2014 18:48:56 -0500 (EST) Date: Thu, 20 Feb 2014 18:48:56 -0500 From: "Frank Ch. Eigler" To: Nathan Scott Cc: Ken McDonell , pcp@oss.sgi.com Subject: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Message-ID: <20140220234856.GG6516@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc References: <52FE5058.4030702@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> <53067159.9050409@internode.on.net> <2078588943.13402683.1392937771745.JavaMail.zimbra@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2078588943.13402683.1392937771745.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392940140 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - nathans wrote: > The usual model would be local pmie daemon (no temporary connection). Sorry, I was extrapolating from observations of a particular local pmie process here, which maintained no permanent tcp connection to the -h HOSTNAME, but rather closed / reopened it every pmie polling cycle. But looking at it now more closely, the affected pmie is one that is using an ssh tunnel (-h localhost:XYZ), where the remote pmcd.hostname is of course different from localhost etc. I see pmie trying to connect to the pmcd.hostname, failing (since it's firewalled that route), then falling back to the initially supplied -h HOSTSTRING. There's a real bug in there. > I'm not following how its a complication to have a second connection > to pmcd...? (relative to the level of complication of pmlogger code > that we'd have to consider, which would appear to require a decision > making engine like pmie to be built into pmlogger...?). Sure, from the PoV that the pmie codebase was not written to be encapsulated as a library. From the PoV of the target pmcd though, there would be less run-time complexity, in the form of one fewer client. > > it cannot piggy-back on an archive being written-to by pmlogger. > > Can you explain that some more? ("piggy-back" in what way?) The pmlc > model is that pmie tells pmlogger what (extra) to log dynamically, via > pmlc, so in that sense it is piggy-backing on the existing archive...? Right, I was referring to a hypothetical scenario where pmie's inputs could be taken from the pmlogger-archive being written, rather than via a secondary connection to pmcd. That would reduce the load on pmcd, if the predicate inputs happened to be subsets of the pmlogger outputs. - FChE From nscott@redhat.com Thu Feb 20 18:06:24 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id AD1A37FC8 for ; Thu, 20 Feb 2014 18:06:24 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id A3D3A304070 for ; Thu, 20 Feb 2014 16:06:21 -0800 (PST) X-ASG-Debug-ID: 1392941179-04cb6c6de2639890001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id Iv7De8OgdW9kVonJ for ; Thu, 20 Feb 2014 16:06:20 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1L06F4a023829; Thu, 20 Feb 2014 19:06:15 -0500 Date: Thu, 20 Feb 2014 19:06:15 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: Ken McDonell , pcp@oss.sgi.com Message-ID: <2116166352.13416762.1392941175041.JavaMail.zimbra@redhat.com> In-Reply-To: <20140220234856.GG6516@redhat.com> References: <52FE5058.4030702@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> <53067159.9050409@internode.on.net> <2078588943.13402683.1392937771745.JavaMail.zimbra@redhat.com> <20140220234856.GG6516@redhat.com> Subject: pmie hostname handling bugs (was Re: [pcp] pmlc access control, was [something else again]) MIME-Version: 1.0 X-ASG-Orig-Subj: pmie hostname handling bugs (was Re: [pcp] pmlc access control, was [something else again]) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmie hostname handling bugs (was Re: [pcp] pmlc access control, was [something else again]) Thread-Index: uGF+1j8s6kPjM12ESAF/G9s+s06P3A== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1392941180 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145332 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > > > The usual model would be local pmie daemon (no temporary connection). > > Sorry, I was extrapolating from observations of a particular local > pmie process here, which maintained no permanent tcp connection to the > -h HOSTNAME, but rather closed / reopened it every pmie polling cycle. > But looking at it now more closely, the affected pmie is one that is > using an ssh tunnel (-h localhost:XYZ), where the remote pmcd.hostname > is of course different from localhost etc. I see pmie trying to > connect to the pmcd.hostname, failing (since it's firewalled that > route), then falling back to the initially supplied -h HOSTSTRING. > There's a real bug in there. > *nod* - the hostname mismanagement we observed with local: handling in pmie is also in that neck of the woods (a separate copy of the hostname is kept in internal data structures, and used for newContext calls - it seems to lack the differentiation between "connection string" and "host name" that's been introduced everywhere else). My bug list is already long, if someone else could take these on that'd be fantastic. Hopefully its just the one underlying issue. cheers. -- Nathan From nscott@redhat.com Thu Feb 20 21:54:51 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 82B507F86 for ; Thu, 20 Feb 2014 21:54:51 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 567FD8F804B for ; Thu, 20 Feb 2014 19:54:51 -0800 (PST) X-ASG-Debug-ID: 1392954886-04cb6c6de0646300001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 3FMtDkEbSYM84zfi for ; Thu, 20 Feb 2014 19:54:46 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1L3sjHm010824 for ; Thu, 20 Feb 2014 22:54:45 -0500 Date: Thu, 20 Feb 2014 22:54:45 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp@oss.sgi.com Message-ID: <1240607619.13473442.1392954885925.JavaMail.zimbra@redhat.com> In-Reply-To: <1178994411.13473436.1392954864757.JavaMail.zimbra@redhat.com> Subject: pcp updates: qa, tmpdir perms, python vs timezones MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: qa, tmpdir perms, python vs timezones Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: qa, tmpdir perms, python vs timezones Thread-Index: P4EuF6yRN0OJBGsNOw6sYpOP+ufOhw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1392954886 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145338 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev CHANGELOG | 5 ++++- VERSION.pcp | 2 +- build/rpm/fedora.spec | 7 +++++-- debian/changelog | 6 ++++++ qa/003 | 1 + qa/737 | 7 ++++++- qa/737.out | 9 +++++---- qa/750 | 3 ++- qa/750.out.1 | 34 +++++++++++++++++----------------- qa/750.out.2 | 36 ++++++++++++++++++------------------ qa/750.out.3 | 36 ++++++++++++++++++------------------ qa/common.secure | 5 +++++ qa/src/permslist | 4 ++-- qa/src/test_pcp_time.python | 2 ++ src/libpcp_gui/src/record.c | 2 +- src/pmie/GNUmakefile | 2 +- src/pmlogger/GNUmakefile | 2 +- src/pmlogger/src/ports.c | 9 ++------- src/python/pcp/pmapi.py | 26 +++++++++++++------------- 19 files changed, 110 insertions(+), 88 deletions(-) commit 2633a9948658a7fb0236a4740dc30b6c0193c91e Author: Nathan Scott Date: Fri Feb 21 14:31:55 2014 +1100 Resolve timezone handling bugs in python wrapper API We were incorrectly changing the context when asked to change the timezone, this nullifying the zone change, and in one sad location even calling the wrong PMAPI routine (hohum). Fixed those, then extended qa/737 to cover pmWhichZone use as well. Problem found by the Red Hat testing folks using test qa/737. commit 3428c59e7f2e2bdd25e1f6d5b899a853f6845553 Author: Nathan Scott Date: Fri Feb 21 14:26:50 2014 +1100 Do not attempt to run NSS tests affected by bz 1035509 commit e7f46a10ebee89e7f5693337e71a08406c2a1a59 Author: Nathan Scott Date: Fri Feb 21 14:26:02 2014 +1100 Update pmlogger for more restrictive tmpdir permission settings commit 13a5562e18910ecffaba5b60f3b7adc5a01d7e56 Author: Nathan Scott Date: Fri Feb 21 14:11:51 2014 +1100 Extend qa/003 filter for non-x86 hosts, with less cpuinfo commit 66ce1d4adc73cbe18b2ffac9d95efd820cf3ca44 Author: Nathan Scott Date: Fri Feb 21 13:29:44 2014 +1100 Make test qa/750 deterministic, remove hard-wired hostname commit 2086f3abb2100e8f616707b4a7938cd3c9f2d91d Author: Nathan Scott Date: Fri Feb 21 12:16:01 2014 +1100 Fix a little typo in a record API comment commit a06928de388bf82832f7886e401add8929b71ccc Author: Nathan Scott Date: Fri Feb 21 12:15:42 2014 +1100 Remove world readable bit from access pmie and pmlogger tmpdirs. commit df02cef3c1fa9e9c1233e77ea760e8546516b509 Author: Nathan Scott Date: Fri Feb 21 11:41:09 2014 +1100 Bump version, update changelog to reflect next planned release date From brolley@redhat.com Fri Feb 21 07:21:52 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 444ED7FA3 for ; Fri, 21 Feb 2014 07:21:52 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id CBD2BAC006 for ; Fri, 21 Feb 2014 05:21:48 -0800 (PST) X-ASG-Debug-ID: 1392988904-04cbb00c2965e260001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id fFu7ByQjd1a65dIE for ; Fri, 21 Feb 2014 05:21:44 -0800 (PST) X-Barracuda-Envelope-From: brolley@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1LDLiFF031714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Feb 2014 08:21:44 -0500 Received: from [10.10.48.205] (vpn-48-205.rdu2.redhat.com [10.10.48.205]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1LDLhvw001718; Fri, 21 Feb 2014 08:21:43 -0500 Message-ID: <53075306.8090708@redhat.com> Date: Fri, 21 Feb 2014 08:22:14 -0500 From: Dave Brolley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Scott CC: pcp@oss.sgi.com Subject: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc References: <52FE5058.4030702@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> <1760935757.13397936.1392936985421.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc In-Reply-To: <1760935757.13397936.1392936985421.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392988904 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On 02/20/2014 05:56 PM, Nathan Scott wrote: > > ----- Original Message ----- >> [...] >> To secure pmlogger across AF_UNIX, it's not enough to put the sockets >> into variously owned owned directories. /var/lib/pcp/tmp is currently >> world-readable, and the socket's own permissions may or may not be > Its /var/lib/pcp/tmp/pmlogger though isn't it? We could install that 770 > with no trouble, nowadays, I think...? (and likewise for pmie) > I've currently got the system-wide socket being created in /var/run/pcp (same location as the pmcd socket) as /var/run/pcp/pmlogger..socket. I figured that the sockets should all be in the same location. Currently the user level socket is created as ~/.pcp/pmlogger/pmlogger..socket. If the system-wide one stays where it is, and you want the user level hierarchy to match the systen-wide one, then then the user level socket would then go into to ~/.pcp/run/pmlogger..socket, I suppose. If you want the system-wide socket to go into /var/lib/pcp/tmp/pmlogger, then they would become /var/lib/pcp/tmp/pmlogger/.socket and ~/.pcp/tmp/pmlogger/.socket respectively. It doesn't matter to me. This is all encapsulated into __pmLogLocalSocketDefault() and __pmLogLocalSocketUser() and can be changed easily. I'm on vacation starting this afternoon and not returning until Friday Feb 28. I'll push what I have and you can change/merge/ignore it in the mean time. Dave From brolley@redhat.com Fri Feb 21 07:26:16 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 242F57FA3 for ; Fri, 21 Feb 2014 07:26:16 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 052C0304064 for ; Fri, 21 Feb 2014 05:26:12 -0800 (PST) X-ASG-Debug-ID: 1392989171-04bdf00fca23dc60001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id vxcC6gwU2LLFEFY8 for ; Fri, 21 Feb 2014 05:26:11 -0800 (PST) X-Barracuda-Envelope-From: brolley@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1LDQ9PY031382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Feb 2014 08:26:09 -0500 Received: from [10.10.48.205] (vpn-48-205.rdu2.redhat.com [10.10.48.205]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1LDQ8KQ020500; Fri, 21 Feb 2014 08:26:09 -0500 Message-ID: <53075410.3060508@redhat.com> Date: Fri, 21 Feb 2014 08:26:40 -0500 From: Dave Brolley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Nathan Scott CC: pcp@oss.sgi.com Subject: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc References: <52FE5058.4030702@redhat.com> <53023D4E.1060504@redhat.com> <757832688.10280462.1392753861578.JavaMail.zimbra@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> <1679311501.13409718.1392938667397.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc In-Reply-To: <1679311501.13409718.1392938667397.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392989171 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 On 02/20/2014 06:24 PM, Nathan Scott wrote: > Hi Dave, > > > Mhmmm, is test 750 passing for you atm? :) I accidentally included my > hostname in its output, so it should be failing everywhere else. Sorry > 'bout that - will be fixed shortly ... but do you have any other common > failures though? (that fail without these new changes, I mean). Yeah 750 fails for me in this manner. I have no other qa regressions from these changes. Dave From brolley@redhat.com Fri Feb 21 08:05:35 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id C94C17FA7 for ; Fri, 21 Feb 2014 08:05:35 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id A9CE930407A for ; Fri, 21 Feb 2014 06:05:32 -0800 (PST) X-ASG-Debug-ID: 1392991528-04cb6c06cf352ae0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id zsBzppcmWi1wyBg8 for ; Fri, 21 Feb 2014 06:05:28 -0800 (PST) X-Barracuda-Envelope-From: brolley@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1LE5SBr011698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Feb 2014 09:05:28 -0500 Received: from [10.10.48.205] (vpn-48-205.rdu2.redhat.com [10.10.48.205]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1LE5RAX025604 for ; Fri, 21 Feb 2014 09:05:27 -0500 Message-ID: <53075D46.6090807@redhat.com> Date: Fri, 21 Feb 2014 09:05:58 -0500 From: Dave Brolley User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: PCP Updates: pmlogger AF_UNIX socket for normal users; qa version check bump Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ASG-Orig-Subj: PCP Updates: pmlogger AF_UNIX socket for normal users; qa version check bump Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1392991528 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 commit 6f89daa0c76bfb53267b5367e40c0815dd0fd738 Author: Dave Brolley Date: Fri Feb 21 09:02:54 2014 -0500 Bump pcp version check for qa tests 368 and 497 to 3901. pmlogger/pmlc AF_UNIX changes missed release 3.9.0 commit aabeef72f915d50fcaec4ea168d282b23b184ea7 Author: Dave Brolley Date: Fri Feb 21 08:28:30 2014 -0500 Create pmLogger AF_UNIX socket under the home directory for normal users. When a normal user runs pmlogger, the AF_UNIX socket cannot be created in the normal system-wide location, since that location is not world writable. In this case, create the socket under the user's home directory (i.e. under ~/.pcp). From nscott@redhat.com Sun Feb 23 17:54:52 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 69F337F57 for ; Sun, 23 Feb 2014 17:54:52 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id CF1F5AC003 for ; Sun, 23 Feb 2014 15:54:48 -0800 (PST) X-ASG-Debug-ID: 1393199683-04cbb00c2b725930001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id 7XzgOdxkTFpHzqdn for ; Sun, 23 Feb 2014 15:54:43 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1NNshZF021471; Sun, 23 Feb 2014 18:54:43 -0500 Date: Sun, 23 Feb 2014 18:54:43 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Dave Brolley Cc: pcp@oss.sgi.com Message-ID: <1110810860.14424477.1393199683226.JavaMail.zimbra@redhat.com> In-Reply-To: <53075306.8090708@redhat.com> References: <52FE5058.4030702@redhat.com> <896174788.10421447.1392770006295.JavaMail.zimbra@redhat.com> <5304D039.9010708@redhat.com> <1347098955.12246278.1392874951684.JavaMail.zimbra@redhat.com> <530612EC.8020206@redhat.com> <1760935757.13397936.1392936985421.JavaMail.zimbra@redhat.com> <53075306.8090708@redhat.com> Subject: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmlc access control, was Re: PCP Updates: qa fallout from ipv6/unix sockets for pmlogger and pmlc Thread-Index: pHu2uUsLrxk4Wqvnr2gYG2mYvU+Uvg== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1393199683 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145441 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > On 02/20/2014 05:56 PM, Nathan Scott wrote: > > > > ----- Original Message ----- > >> [...] > >> To secure pmlogger across AF_UNIX, it's not enough to put the sockets > >> into variously owned owned directories. /var/lib/pcp/tmp is currently > >> world-readable, and the socket's own permissions may or may not be > > Its /var/lib/pcp/tmp/pmlogger though isn't it? We could install that 770 > > with no trouble, nowadays, I think...? (and likewise for pmie) > > > I've currently got the system-wide socket being created in /var/run/pcp > (same location as the pmcd socket) as Aha, good point - I missed that & thought it was located with the port map files. > /var/run/pcp/pmlogger..socket. I figured that the sockets should > all be in the same location. *nod* > If the system-wide one stays where it is, and you want the user level > hierarchy to match the systen-wide one, then then the user level socket > would then go into to ~/.pcp/run/pmlogger..socket, I suppose. Yes, that sounds like a better option. > If you want the system-wide socket to go into /var/lib/pcp/tmp/pmlogger, > then they would become /var/lib/pcp/tmp/pmlogger/.socket and > ~/.pcp/tmp/pmlogger/.socket respectively. I don't like that option anymore, 20/20 hind-sight. :) > It doesn't matter to me. This is all encapsulated into > __pmLogLocalSocketDefault() and __pmLogLocalSocketUser() and can be > changed easily. OK. > I'm on vacation starting this afternoon and not returning until Friday > Feb 28. I'll push what I have and you can change/merge/ignore it in the > mean time. Thanks Dave - I hope to take a closer look today. Have a great holiday! cheers. -- Nathan From nscott@redhat.com Mon Feb 24 00:51:52 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 45CAC7F53 for ; Mon, 24 Feb 2014 00:51:52 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 304C98F8052 for ; Sun, 23 Feb 2014 22:51:48 -0800 (PST) X-ASG-Debug-ID: 1393224705-04cbb00c2a738680001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id wg9ZQP1PPdhqC4Rg for ; Sun, 23 Feb 2014 22:51:46 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1O6pihY020660; Mon, 24 Feb 2014 01:51:44 -0500 Date: Mon, 24 Feb 2014 01:51:43 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Stan Cox Cc: PCP Message-ID: <2061040535.14512907.1393224703952.JavaMail.zimbra@redhat.com> In-Reply-To: <53042BF5.5070704@redhat.com> References: <53042BF5.5070704@redhat.com> Subject: Re: [pcp] datetime enhancements MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] datetime enhancements Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: datetime enhancements Thread-Index: d8g0Cw74PDn2oOK8KPOZ+3ut5w+Sug== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1393224705 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145451 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > commit 7ef03c90217b adds support for the gnulib get_date module to > pcplib/rtime.c::__pmParseTime. First it tries the existing mechanism. > If that fails it tries gnulib get_date. Here is an example from the > testcase which shows example datetimes and how the start/end times are > adjusted. No doc changes yet but the date command uses the gnulib > get_date support and documents it in > info date 'date input' > Apologies for the delay in review Stan. BTW, that fpaste on the man page change hasn't been committed yet - your approach of referencing the "info" page looked OK-ish to me. Maybe not ideal though ... it'd be better to have it in man format like everything else - I read thru the info pages, and the content did not seem particularly lengthy...? If you do add in the new __pmParseTime (impl.h/exports), as discussed below - and I think you probably should now - a new pmparsetime.3 man page would be a welcome addition (see pmparsectime.3 for a template). Anyway, here's the rest of the review... diff --git a/qa/751 b/qa/751 new file mode 100755 index 0000000..a239f71 --- /dev/null +++ b/qa/751 @@ -0,0 +1,19 @@ +#!/bin/sh +# PCP QA Test No. 751 +# Test supported datetime strings test $PCP_VER -ge 3901 || _notrun "No support for new extended datetime strings" diff --git a/qa/group b/qa/group index 06a1f08..eca61fe 100644 --- a/qa/group +++ b/qa/group @@ -889,6 +889,7 @@ avahi 748 pmlogrewrite pmda.mysql local oss 749 pmcd local oss 750 pmda.rpm local oss +751 libpcp local oss (there is a "git merge" conflict here with other recent test additions - just FYI, in case you do a git pull to update to current pcp dev code) 755 pmda.apache pmda.install local oss 768 pmlogextract local oss 775 sanity pmfind local oss diff --git a/qa/src/GNUlocaldefs b/qa/src/GNUlocaldefs index e3a5793..2933f9a 100644 --- a/qa/src/GNUlocaldefs +++ b/qa/src/GNUlocaldefs @@ -74,7 +74,7 @@ CFILES = disk_test.c exercise.c context_test.c chkoptfetch.c \ pmdacache.c check_import.c unpack.c aggrstore.c atomstr.c \ grind_conv.c getconfig.c err.c torture_logmeta.c keycache.c \ keycache2.c pmdaqueue.c drain-server.c template.c anon-sa.c \ - username.c + username.c rtimetest.c Awesome, testing! Thanks Stan! ifeq ($(shell test -f ../localconfig && echo 1), 1) include ../localconfig diff --git a/qa/src/rtimetest.c b/qa/src/rtimetest.c new file mode 100644 index 0000000..3b3222f --- /dev/null +++ b/qa/src/rtimetest.c @@ -0,0 +1,123 @@ Missing copyright annotation. +#include +#include +#include Guess we *really* want the time headers! :) To be sure to be sure. +#include +#include +#include It will make life easier to remove all those headers and just include pmapi.h (and probably impl.h too, depending on other questions below). pmapi.h indirectly gets config.h which has platform-specific details. +int __pmParseTime( + const char *string, /* string to be parsed */ + struct timeval *logStart, /* start of log or current time */ + struct timeval *logEnd, /* end of log or tv_sec == INT_MAX */ + /* assumes sizeof(t_time) == sizeof(int) */ + struct timeval *rslt, /* if parsed ok, result filled in */ + char **errMsg); /* error message, please free */ Er, wha? That's not going to fly; this symbol would need to be added to the exports file in libpcp. Do we want this directly callable via client tools? (maybe? dunno) If so, updates needed to exports and to impl.h -- if not, this test needs to call the API that calls this internal API. We do need to update exports file for other things planned for this next release, so its probably for the best to simply add it there I guess, then testing is simpler too. That does make me realise however, that there is no test coverage of the non-double-underscore API interfaces that will usually be used to access this functionality. A second test program (or perhaps a command line option for this one) could exercise that. That should check that examples of the existing syntax continue to be parsed in addition to the extended syntax. I suppose the "existing parsing is still working" is already tested, but we need to make sure the new parsing is indeed working from the non-double-underscore API - that latter part is all we really need still. +int +main () +{ IIRC, this main() definition may cause compiler warnings on some platforms. Adding some getopts handling for the above issue will of course resolve this. + set_tm (NULL, &tmtmp, &tmstart, 0, 19, 11, 45); + tmtmp_str = asctime(&tmtmp); + char *tmtmp_c = strchr (tmtmp_str, '\n'); + *tmtmp_c = ' '; + __pmParseTime (tmtmp_str, &tvstart, &tvend, &tvrslt, &errmsg); + localtime_r (&tvrslt.tv_sec, &tmrslt); // time_t => tm Hmm, is this not timezone sensitive? (will this test pass no matter where it is run?) + int sfx; + for (sfx = 0; sfx < (sizeof(strftime_fmt) / sizeof(void*)); sfx++) { + int len = strftime (buffer, sizeof (buffer), strftime_fmt[sfx], &tmtmp); + if (len != 0) Inconsistency with braces? (on the "for" vs "if" lines - pick one and preferably the same as rest of pcp). Actually, the entire source file code style differs to all other qa/src programs. diff --git a/src/libpcp/src/GNUmakefile b/src/libpcp/src/GNUmakefile index 176079b..4a19e4b 100644 --- a/src/libpcp/src/GNUmakefile +++ b/src/libpcp/src/GNUmakefile @@ -58,6 +58,11 @@ LSRCFILES += accounts.c LLDLIBS += -lpsapi endif +CFILES += gettime.c xmalloc.c getdate.c Add directly into the original CFILES list. We've also added new headers here, so HFILES needs updating for the new headers. YFILES needs to be extended to include getdate.y - see pmie makefile for example. +.y.c: + $(YACC) $< + /bin/mv y.tab.c `basename $< .y`.c See pmie makefile again - e.g. no hard-coded paths to binaries. diff --git a/src/libpcp/src/check-statics b/src/libpcp/src/check-statics index bc30905..050c9bd 100755 --- a/src/libpcp/src/check-statics +++ b/src/libpcp/src/check-statics @@ -181,6 +181,26 @@ fetchlocal.o b splitmax.[0-9]* # single-threaded PM_SCOPE_DSO_PMDA fetch.o freeresult.o +getdate.o + d dst_table + d meridian_table + d military_table + d month_and_day_table + b RELATIVE_TIME_0 + d relative_time_table + d time_units_table + d time_zone_table + d universal_time_zone_table + r yycheck + r yydefact + r yydefgoto + r yypact + r yypgoto + r yyr1 + r yyr2 + r yytable + r yytranslate +gettime.o hash.o Comments need to be added to each of these explaining why/how they are safe in a multi-threaded environment. Everything ending in _table looks like it is a "const static" (readonly & hence safe). However all the yacc symbols are highly suspect and need comments and probably code audit to add missing locking. I also found the build failed for me in the check-statics phase - I had some unexpected symbols - yyval_default.[0-9]* in getdate.o and also some strange C.[0-9][0-9].[0-9]* symbol that I could not trace. Do you know what that might be? A regex as wide-open as C.* in check-statics would not be ideal, so I'd really least like to find out what this symbol is. diff --git a/src/libpcp/src/getdate.c b/src/libpcp/src/getdate.c new file mode 100644 index 0000000..448657e --- /dev/null +++ b/src/libpcp/src/getdate.c This file is generated and should not be committed to the git repo. Remove from CFILES in Makefile too - check out pmie makefile for an example. +static char * +get_tz (char tzbuf[TZBUFSIZE]) + char *tz = getenv ("TZ"); Ah - this doesn't take into account the current timezone, in the stack that libpcp provides. See pmNewZone and pmUseZone. + tmp = localtime (&now->tv_sec); pmLocaltime? + if (strncmp (p, "TZ=\"", 4) == 0) Hmm, suspiscious for above reasons. +#if HAVE_STRUCT_TM_TM_ZONE We have no configure support for this. +#if HAVE_TZNAME We have no configure support for this. +# ifndef tzname + extern char *tzname[]; +# endif We unconditionally access this over in tz.c so the ifdef appears unnecessary for all platforms PCP has ever supported. + for (i = 0; i < 2; i++) + { + pc.local_time_zone_table[i].name = tzname[i]; Oh we keep pointers to it - can tzname ever change? I would punt that it can (see tz.c, which calls tzset - hmm, why is there no tzset in this new code??) + if (setenv ("TZ", tz1buf, 1) != 0) + goto fail; This is unlikely to play well with the existing timezone stacking in tz.c. +#ifdef HAVE_TM_GMTOFF We have no configure support for this. + done: + if (tz_was_altered) + ok &= (tz0 ? setenv ("TZ", tz0, 1) : unsetenv ("TZ")) == 0; Hmmm. Interesting, maybe this can be made to play nice after all. We do still need to take into account the existing zone setting - a QA test exercising use of pmNewZone & pmUseZone in conjunction with this new (internal) API seems warranted. diff --git a/src/libpcp/src/getdate.h b/src/libpcp/src/getdate.h new file mode 100644 index 0000000..142231e --- /dev/null +++ b/src/libpcp/src/getdate.h @@ -0,0 +1,23 @@ +/* Parse a string into an internal time stamp. + + Copyright (C) 1995, 1997, 1998, 2003, 2004, 2007 Free Software + Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software Foundation, + Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ + +#include +#include + +bool get_date (struct timespec *, char const *, struct timespec const *); get_date function needs _PCP_HIDDEN annotation. This header should probably be rolled into internal.h. The use of bool as an error handling mechanism is different to the way the rest of libpcp works, so I'd advise not keeping that aspect either. --- /dev/null +++ b/src/libpcp/src/getdate.y @@ -0,0 +1,1520 @@ [...] + nanosecond-resolution time stamps, and in October 2004 to support + TZ strings in dates. */ We should verify if this latter feature functions with (or breaks) timezone stacking in libpcp. +/* FIXME: Check for arithmetic overflow in all cases, not just + some of them. */ Eek. +// #include Mhmm. We need to sort out configuration by auditing the code, and adding to our configure checks, not just commenting the header out. + +/* Since the code of getdate.y is not included in the Emacs executable + itself, there is no need to #define static in this file. Even if + the code were included in the Emacs executable, it probably + wouldn't do any harm to #undef it here; this will only cause + problems if we try to write to a static variable, which I don't + think this code needs to do. */ +#ifdef emacs +# undef static +#endif The above can certainly go. This entire file has a different coding style to the rest of libpcp, not surprisingly. We need to decide whether to tradeoff consistency with the ability to make direct comparisons to new versions of the source code -- how often is this code updated? (upstream, I mean) I suspect we should embrace the existing code and make it our own - the header comments suggest few updates. +#if HAVE_COMPOUND_LITERALS We have no configure support for this. +/* We want a reentrant parser, even if the TZ manipulation and the calls to (Ah, good to hear!) + localtime and gmtime are not reentrant. */ Rest of libpcp uses the pcp lock to provide these guarantees - this code will need to be audited to check interactions there, and whether it is circumventing the existing locking. At first glance, it appears to be broken in this regard. + } + else + { This coding style is really jarring when reading it, to me at least - should be made consistent with the rest of the PCP code base. The use of whitespace inconsistently also is problematic (different whitespace in conditionals, function calls, etc). +static table const * +lookup_zone (parser_control const *pc, char const *name) +{ + table const *tp; + + for (tp = universal_time_zone_table; tp->name; tp++) + if (strcmp (name, tp->name) == 0) + return tp; + + /* Try local zone abbreviations before those in time_zone_table, as + the local ones are more likely to be right. */ + for (tp = pc->local_time_zone_table; tp->name; tp++) + if (strcmp (name, tp->name) == 0) + return tp; + + for (tp = time_zone_table; tp->name; tp++) + if (strcmp (name, tp->name) == 0) + return tp; + + return NULL; +} The above timezone table continues to make me nervous. :) Surely this needs to interact with the timezone code in tz.c in some way? +/* A reasonable upper bound for the size of ordinary TZ strings. + Use heap allocation if TZ's length exceeds this. */ +enum { TZBUFSIZE = 100 }; + +/* Return a copy of TZ, stored in TZBUF if it fits, and heap-allocated + otherwise. */ +static char * +get_tz (char tzbuf[TZBUFSIZE]) +{ + char *tz = getenv ("TZ"); + if (tz) + { + size_t tzsize = strlen (tz) + 1; + tz = (tzsize <= TZBUFSIZE + ? memcpy (tzbuf, tz, tzsize) + : xmemdup (tz, tzsize)); + } + return tz; +} Same comments as above. +#else +#if HAVE_TZNAME + { +# ifndef tzname + extern char *tzname[]; +# endif Same comments as earlier. +#if TEST + +int +main (int ac, char **av) +{ + char buff[BUFSIZ]; + + printf ("Enter date, or blank line to exit.\n\t> "); + fflush (stdout); + + buff[BUFSIZ - 1] = '\0'; + while (fgets (buff, BUFSIZ - 1, stdin) && buff[0]) + { + struct timespec d; + struct tm const *tm; + if (! get_date (&d, buff, NULL)) + printf ("Bad format - couldn't convert.\n"); + else if (! (tm = localtime (&d.tv_sec))) + { + long int sec = d.tv_sec; + printf ("localtime (%ld) failed\n", sec); + } + else + { + int ns = d.tv_nsec; + printf ("%04ld-%02d-%02d %02d:%02d:%02d.%09d\n", + tm->tm_year + 1900L, tm->tm_mon + 1, tm->tm_mday, + tm->tm_hour, tm->tm_min, tm->tm_sec, ns); + } + printf ("\t> "); + fflush (stdout); + } + return 0; +} +#endif /* TEST */ Is there actual test data that the authors of this code used with this test program? It would be good to pull that into our tests as well, in the same way we have pulled in the code. diff --git a/src/libpcp/src/gettime.c b/src/libpcp/src/gettime.c new file mode 100644 index 0000000..70bb5de --- /dev/null +++ b/src/libpcp/src/gettime.c @@ -0,0 +1,49 @@ [...] +// #include (same issue discussed earlier) +/* Get the system time into *TS. */ + +void +gettime (struct timespec *ts) +{ +#if HAVE_NANOTIME + nanotime (ts); +#else We have no configure check for this. nanotime doesn't appear to exist in Linux headers? +# if defined CLOCK_REALTIME Nor this. +[...] && HAVE_CLOCK_GETTIME Nor this. + struct timeval tv; + gettimeofday (&tv, NULL); + ts->tv_sec = tv.tv_sec; + ts->tv_nsec = tv.tv_usec * 1000; The accuracy of gettimeofday tends to be accepted as plenty for the sorts of problems PCP is used to tackle. diff --git a/src/libpcp/src/rtime.c b/src/libpcp/src/rtime.c index 086981b..26f8ccb 100644 --- a/src/libpcp/src/rtime.c +++ b/src/libpcp/src/rtime.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 1995, 2014 Silicon Graphics, Inc. All Rights Reserved. *cough* - heh. * This library is free software; you can redistribute it and/or modify it * under the terms of the GNU Lesser General Public License as published @@ -14,6 +14,7 @@ #include #include +#include #include "pmapi.h" #include "impl.h" [ Not needed? ... ] $ grep string.h /usr/include/pcp/*h /usr/include/pcp/pmapi.h:#include @@ -519,6 +520,74 @@ __pmConvertTime( + +/* + * Used by xmalloc/xrealloc/xcalloc which are called by get_date, the datetime parser + */ + +void +xalloc_die (void) +{ + // error (exit_failure, 0, "%s", _("memory exhausted")); + abort (); +} + Not really appropriate error handling for a library. A __pmNoMem call would be more appropriate than xalloc_die too - but will need more context - I'd imagine date string parsing should never cause program exit - a graphical tool like pmchart might be calling it with an interactively-user-supplied string, for example. int /* 0 -> ok, -1 -> error */ __pmParseTime( const char *string, /* string to be parsed */ @@ -533,7 +602,7 @@ __pmParseTime( struct timeval start; struct timeval end; struct timeval tval; - + int get_date (struct timespec *, char const *, struct timespec const *); No inline extern function definitions. This is already in a header, use that instead (should be internal.h by the time we're done). @@ -542,33 +611,62 @@ __pmParseTime( /* ctime string */ if (parseChar(&scan, '@')) { - if (__pmParseCtime(scan, &tm, errMsg) < 0) - return -1; - tm.tm_wday = NO_OFFSET; - __pmConvertTime(&tm, &start, rslt); + if (__pmParseCtime(scan, &tm, errMsg) >= 0) { + tm.tm_wday = NO_OFFSET; + __pmConvertTime(&tm, &start, rslt); + return 0; + } } (is there a memory leak on errMsg here) /* relative to end of archive */ else if (end.tv_sec < INT_MAX && parseChar(&scan, '-')) { - if (pmParseInterval(scan, &tval, errMsg) < 0) - return -1; - tm.tm_wday = NEG_OFFSET; - tm.tm_sec = (int)tval.tv_sec; - tm.tm_yday = (int)tval.tv_usec; - __pmConvertTime(&tm, &end, rslt); + if (pmParseInterval(scan, &tval, errMsg) >= 0) { + tm.tm_wday = NEG_OFFSET; + tm.tm_sec = (int)tval.tv_sec; + tm.tm_yday = (int)tval.tv_usec; + __pmConvertTime(&tm, &end, rslt); + return 0; + } } (is there another memory leak on errMsg here) /* relative to start of archive or current time */ else { parseChar(&scan, '+'); - if (pmParseInterval(scan, &tval, errMsg) < 0) - return -1; - tm.tm_wday = PLUS_OFFSET; - tm.tm_sec = (int)tval.tv_sec; - tm.tm_yday = (int)tval.tv_usec; - __pmConvertTime(&tm, &start, rslt); + if (pmParseInterval(scan, &tval, errMsg) >= 0) { + tm.tm_wday = PLUS_OFFSET; + tm.tm_sec = (int)tval.tv_sec; + tm.tm_yday = (int)tval.tv_usec; + __pmConvertTime(&tm, &start, rslt); + return 0; + } } (is there another memory leak on errMsg here) + /* datetime is not a pcp defined one, so drop down into the glib get_date case */ + int status = -1; + int rel_type = have_relative_date (scan); + struct timespec tsrslt; + struct timespec *tsrsltp = &tsrslt; IIRC, this (locals declared in the middle of a function) was reported as not working under some compiler versions recently - perhaps take this to a separate function? + if (parseChar(&scan, '@')) + rel_type = NO_OFFSET; + + if (rel_type == NO_OFFSET) + status = get_date (tsrsltp, scan, NULL); + else if (rel_type == NEG_OFFSET && end.tv_sec < INT_MAX) { + struct timespec tsend; + struct timespec *tsendp = &tsend; + TIMEVAL_TO_TIMESPEC (&end, tsendp); + status = get_date (tsrsltp, scan, &tsend); We're mixing up different code styles now - PCP style and glib style (4 space indents vs extra whitespace). get_date returns a bool doesn't it? This is the sort of bug I was half wondering might happen. Remove the use of bool would be best I think. Oh, whooah - are we guaranteed that an errMsg string will be correctly initialised for all failing cases? Might be OK, on reflection - if the strategy is just that we provide more passing cases (which AIUI is what we're doing), and pass out the earlier error string. Yeah, that's OK. I think. :) We definitely leak errMsg though - in all newly added passing cases, we leak the earlier error messages. An additional free right near the end, before "return 0;" should do the trick. diff --git a/src/libpcp/src/setenv.h b/src/libpcp/src/setenv.h new file mode 100644 index 0000000..92e7bba --- /dev/null +++ b/src/libpcp/src/setenv.h @@ -0,0 +1,54 @@ +#if HAVE_SETENV || HAVE_UNSETENV Its luck of the draw as to whether these will be defined correctly, if we don't pull in our config.h first here. (success would depend on the order of #includes at any/all places including this header) That said, everywhere else that modifies the environment (see tz.c, in particular) in libpcp uses putenv and provides locking. diff --git a/src/libpcp/src/timespec.h b/src/libpcp/src/timespec.h new file mode 100644 index 0000000..cce2d66 --- /dev/null +++ b/src/libpcp/src/timespec.h @@ -0,0 +1,37 @@ +/* timespec -- System time interface + + Copyright (C) 2000, 2002, 2004, 2005, 2007 Free Software Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software Foundation, + Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ + +#if ! defined TIMESPEC_H +# define TIMESPEC_H + +# include + +/* Return negative, zero, positive if A < B, A == B, A > B, respectively. + Assume the nanosecond components are in range, or close to it. */ +static inline int +timespec_cmp (struct timespec a, struct timespec b) +{ + return (a.tv_sec < b.tv_sec ? -1 + : a.tv_sec > b.tv_sec ? 1 + : a.tv_nsec - b.tv_nsec); +} +void gettime (struct timespec *); (Open code use of gettimeofday like everywhere else in libpcp, remove gettime use - or, make everywhere else use it if it has value to us? I recommend the former option) +int settime (struct timespec const *); (unused - remove) So, could just move that inline call into internal.h, and remove the new header entirely. diff --git a/src/libpcp/src/xalloc.h b/src/libpcp/src/xalloc.h new file mode 100644 index 0000000..0c6d8dc --- /dev/null +++ b/src/libpcp/src/xalloc.h @@ -0,0 +1,271 @@ +/* xalloc.h -- malloc with out-of-memory checking This entire header needs to be removed. Its not appropriate to abort() on memory allocation error in a library, nor to introduce special, different handling of memory allocation just for this new code. Fortunately, there's almost nothing using these interfaces, so conversion to usual libpcp memory allocation failure handling should be straightforward. In fact, most of the routines and defines in this new header are completely unused anyway. diff --git a/src/libpcp/src/xmalloc.c b/src/libpcp/src/xmalloc.c --- /dev/null +++ b/src/libpcp/src/xmalloc.c @@ -0,0 +1,123 @@ Likewise, remove this file entirely please. cheers. -- Nathan From kenj@internode.on.net Mon Feb 24 02:27:57 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 118A97F52 for ; Mon, 24 Feb 2014 02:27:57 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id A0607AC004 for ; Mon, 24 Feb 2014 00:27:53 -0800 (PST) X-ASG-Debug-ID: 1393230470-04bdf00fc932ea80001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id jh3JNBCWFsjoBhhZ for ; Mon, 24 Feb 2014 00:27:51 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAKwBC1N20aH1/2dsb2JhbAANTMYog1IBRT0WGAMCAQIBPwwNCAEBrFqhf5MjBK4c Received: from ppp118-209-161-245.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.161.245]) by ipmail07.adl2.internode.on.net with ESMTP; 24 Feb 2014 18:57:50 +1030 Message-ID: <530B0279.6080607@internode.on.net> Date: Mon, 24 Feb 2014 19:27:37 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: PCP Mailing List Subject: assorted build errors Content-Type: text/plain; charset=windows-1252 X-ASG-Orig-Subj: assorted build errors Content-Transfer-Encoding: 8bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1393230471 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145453 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- I'm just trying to resurrect my QA farm and the first 2 machines are Ubuntu 12.04 and 13.10 The former dies with == dpkg-buildpackage: binary-arch cp: cannot stat `debian/pcp/etc/init.d/pmwebd': No such file or directory dh_install: cp -a debian/pcp/etc/init.d/pmwebd debian/pcp-webapi//etc/init.d/ returned exit code 1 make: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 The latter dies with == dpkg-buildpackage: binary-arch chown: invalid user: ‘pcp:pcp’ make[1]: *** [install] Error 1 make: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Anyone else seeing anything similar? From debbugs@buxtehude.debian.org Mon Feb 24 04:48:16 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B83007F52 for ; Mon, 24 Feb 2014 04:48:16 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 7820C8F8035 for ; Mon, 24 Feb 2014 02:48:13 -0800 (PST) X-ASG-Debug-ID: 1393238891-04bdf00fca3362d0001-S8gJnT Received: from buxtehude.debian.org (buxtehude.debian.org [140.211.166.26]) by cuda.sgi.com with ESMTP id W4Wx4acXJZ7E3aqV (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 24 Feb 2014 02:48:11 -0800 (PST) X-Barracuda-Envelope-From: debbugs@buxtehude.debian.org X-Barracuda-Apparent-Source-IP: 140.211.166.26 Received: from debbugs by buxtehude.debian.org with local (Exim 4.80) (envelope-from ) id 1WHt4w-0001J9-Iy; Mon, 24 Feb 2014 10:48:06 +0000 X-Loop: owner@bugs.debian.org Subject: Bug#739952: missing license in debian/copyright Reply-To: Thorsten Alteholz , 739952@bugs.debian.org X-ASG-Orig-Subj: Bug#739952: missing license in debian/copyright Resent-From: Thorsten Alteholz Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: ftpmaster@ftp-master.debian.org, PCP Development Team X-Loop: owner@bugs.debian.org Resent-Date: Mon, 24 Feb 2014 10:48:02 +0000 Resent-Message-ID: X-Debian-PR-Message: report 739952 X-Debian-PR-Package: pcp X-Debian-PR-Keywords: X-Debian-PR-Source: pcp Received: via spool by submit@bugs.debian.org id=B.13932387113689 (code B); Mon, 24 Feb 2014 10:48:02 +0000 Received: (at submit) by bugs.debian.org; 24 Feb 2014 10:45:11 +0000 Received: from idefix.server.alteholz.net ([78.47.192.125]) by buxtehude.debian.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1WHt27-0000wx-3t for submit@bugs.debian.org; Mon, 24 Feb 2014 10:45:11 +0000 Received: from uucp by idefix.server.alteholz.net with local-rmail (Exim 4.72) (envelope-from ) id 1WHt23-0001Jp-J6 for submit@bugs.debian.org; Mon, 24 Feb 2014 11:45:07 +0100 Received: from debian (helo=localhost) by jupiter.server.alteholz.net with local-esmtp (Exim 4.80) (envelope-from ) id 1WHssN-0008TH-7w for submit@bugs.debian.org; Mon, 24 Feb 2014 11:35:07 +0100 Date: Mon, 24 Feb 2014 11:35:07 +0100 (CET) From: Thorsten Alteholz X-X-Sender: debian@jupiter.server.alteholz.net To: submit@bugs.debian.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Delivered-To: submit@bugs.debian.org Resent-Sender: Debian BTS X-Barracuda-Connect: buxtehude.debian.org[140.211.166.26] X-Barracuda-Start-Time: 1393238891 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145456 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Package: pcp Severity: serious User: alteholz@debian.org Usertags: ftp X-Debbugs-CC: ftpmaster@ftp-master.debian.org thanks Dear Maintainer, please add the missing MIT and BSD licenses of files in pcp-3.9.0/src/pmwebapi/jsdemos/* especially jquery-ui-themes-1.10.2.tar.gz to debian/copyright. (you should also mention the version of LGPL in debian/copyright) Thanks! Thorsten From envelope@ftp-master.debian.org Mon Feb 24 05:00:11 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 879BF7F52 for ; Mon, 24 Feb 2014 05:00:11 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 5E74A304048 for ; Mon, 24 Feb 2014 03:00:11 -0800 (PST) X-ASG-Debug-ID: 1393239609-04cbb00c297468f0001-S8gJnT Received: from franck.debian.org (franck.debian.org [138.16.160.12]) by cuda.sgi.com with ESMTP id fZTC2ZbBTdIUX23R (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 24 Feb 2014 03:00:09 -0800 (PST) X-Barracuda-Envelope-From: envelope@ftp-master.debian.org X-Barracuda-Apparent-Source-IP: 138.16.160.12 Received: from dak by franck.debian.org with local (Exim 4.80) (envelope-from ) id 1WHtGa-0008JK-0K; Mon, 24 Feb 2014 11:00:08 +0000 From: Debian FTP Masters To: PCP Development Team , Nathan Scott X-DAK: dak process-policy X-Debian: DAK X-Debian-Package: pcp Precedence: bulk Auto-Submitted: auto-generated MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: pcp_3.9.0_i386.changes ACCEPTED into unstable, unstable Message-Id: X-ASG-Orig-Subj: pcp_3.9.0_i386.changes ACCEPTED into unstable, unstable Sender: Archive Administrator Date: Mon, 24 Feb 2014 11:00:08 +0000 X-Barracuda-Connect: franck.debian.org[138.16.160.12] X-Barracuda-Start-Time: 1393239609 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145457 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Accepted: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Wed, 19 Feb 2014 10:38:40 +1100 Source: pcp Binary: pcp pcp-conf libpcp3-dev libpcp3 libpcp-gui2-dev libpcp-gui2 libpcp-mmv1-dev libpcp-mmv1 libpcp-pmda3-dev libpcp-pmda3 libpcp-trace2-dev libpcp-trace2 libpcp-import1-dev libpcp-import1 python-pcp libpcp-pmda-perl libpcp-import-perl libpcp-logsummary-perl libpcp-mmv-perl pcp-import-sar2pcp pcp-import-mrtg2pcp pcp-import-sheet2pcp pcp-import-iostat2pcp pcp-import-collectl2pcp pcp-testsuite pcp-manager pcp-webapi Architecture: source i386 all Version: 3.9.0 Distribution: unstable Urgency: low Maintainer: PCP Development Team Changed-By: Nathan Scott Description: libpcp-gui2 - Performance Co-Pilot graphical client tools library libpcp-gui2-dev - Performance Co-Pilot graphical client tools library and headers libpcp-import-perl - Performance Co-Pilot log import Perl module libpcp-import1 - Performance Co-Pilot data import library libpcp-import1-dev - Performance Co-Pilot data import library and headers libpcp-logsummary-perl - Performance Co-Pilot historical log summary module libpcp-mmv-perl - Performance Co-Pilot Memory Mapped Value Perl module libpcp-mmv1 - Performance Co-Pilot Memory Mapped Value client library libpcp-mmv1-dev - Performance Co-Pilot Memory Mapped Value library and headers libpcp-pmda-perl - Performance Co-Pilot Domain Agent Perl module libpcp-pmda3 - Performance Co-Pilot Domain Agent library libpcp-pmda3-dev - Performance Co-Pilot Domain Agent library and headers libpcp-trace2 - Performance Co-Pilot application tracing library libpcp-trace2-dev - Performance Co-Pilot application tracing library and headers libpcp3 - Performance Co-Pilot library libpcp3-dev - Performance Co-Pilot library and headers pcp - System level performance monitoring and performance management pcp-conf - Performance Co-Pilot runtime configuration pcp-import-collectl2pcp - Tool for importing data from collectl into PCP archive logs pcp-import-iostat2pcp - Tool for importing data from iostat into PCP archive logs pcp-import-mrtg2pcp - Tool for importing data from MRTG into PCP archive logs pcp-import-sar2pcp - Tool for importing data from sar into PCP archive logs pcp-import-sheet2pcp - Tool for importing data from a spreadsheet into PCP archive logs pcp-manager - Performance Co-Pilot (PCP) manager daemon pcp-testsuite - Performance Co-Pilot (PCP) Test Suite pcp-webapi - Performance Co-Pilot (PCP) web API service python-pcp - Performance Co-Pilot Python PMAPI module Closes: 655440 737340 Changes: pcp (3.9.0) unstable; urgency=low . * New release (full details in CHANGELOG). * Use autotools-dev to update config.{sub,guess} (closes: #737340) * Split libpcp3 library and configuration files (closes: #655440) Checksums-Sha1: 845da697184dc760e452477cc4290ea172b5f37b 2462 pcp_3.9.0.dsc 8eafdd2b5b0e1ae3c07c24b98665fb306c4632d8 5257496 pcp_3.9.0.tar.xz a71102de08f9e16526b5b803a5d23ec5fad234f2 1133528 pcp_3.9.0_i386.deb 9936620d8927e93d93db0bb61d91486cd592c978 14644 pcp-conf_3.9.0_i386.deb def91f7117e57e97612e51101acffe57282f7c81 370590 libpcp3-dev_3.9.0_i386.deb c82b66782af8b2e53a4f935f0c9d604656c31ee1 167624 libpcp3_3.9.0_i386.deb f38399acbe5424c3dbb752c15adbdcac52aaf915 15602 libpcp-gui2-dev_3.9.0_i386.deb 2da393b9fbae67fc2bba699fcf5a202acb2e68a2 14400 libpcp-gui2_3.9.0_i386.deb 878d1cb30dce04c1892ca90f905063126273b1de 18216 libpcp-mmv1-dev_3.9.0_i386.deb b6f51139753c81c5eae5e10b1eb66bab287aefeb 11504 libpcp-mmv1_3.9.0_i386.deb c318543fe9bec8a96e5b842e32542de20c9dce7c 91604 libpcp-pmda3-dev_3.9.0_i386.deb 72d3274b84488b16ffa4da495524cd4fa556464b 34332 libpcp-pmda3_3.9.0_i386.deb e1108c4ac6f3deb9239129194b7a150024ff0a27 25814 libpcp-trace2-dev_3.9.0_i386.deb e7098e4f97ce0aa41dd7d1bdbd5130d8f199b2cd 18298 libpcp-trace2_3.9.0_i386.deb 6d61056f534f1415fc4398c98aaf8831b5e09975 15310 libpcp-import1-dev_3.9.0_i386.deb a79810fa40cf2e2c6acc98deab513720bef2dce6 14802 libpcp-import1_3.9.0_i386.deb 61cd469388f98b17bb963c4a95052e1d4c6ae273 39900 python-pcp_3.9.0_i386.deb eaa3d2b327ceacb175d4e89930e20ad6632089a2 30708 libpcp-pmda-perl_3.9.0_i386.deb fc079bab65d13281278830a3c63c6351de72bddb 15962 libpcp-import-perl_3.9.0_i386.deb 68fa131a0f9c843934eec78c5943509426a1ea1c 10906 libpcp-logsummary-perl_3.9.0_i386.deb e7dfa5e7b94dc6f953eda1e2891dbab3f4c9f775 17220 libpcp-mmv-perl_3.9.0_i386.deb 19e5ea702a35ab15e364b926b537b8a6a6d7262f 16194 pcp-import-sar2pcp_3.9.0_all.deb 226b03b267fa68bb1404d7e4a654534c01cae5bc 10056 pcp-import-mrtg2pcp_3.9.0_all.deb fd786ff986dec688da99dff43bb5198169e8f6fb 19056 pcp-import-sheet2pcp_3.9.0_all.deb dc52e9af89fa456bd5ceda712d5182252203d734 17726 pcp-import-iostat2pcp_3.9.0_all.deb d122de094f41f9260dcc2e1a35e80bcef7d00ae1 22814 pcp-import-collectl2pcp_3.9.0_i386.deb be0b8a9d87d7c6f495f2cecb1d8f45ae448dd494 2214498 pcp-testsuite_3.9.0_i386.deb 23cf4b36b673a0121a76e56c0013cd2eac1b12d4 45968 pcp-manager_3.9.0_i386.deb 303fa05750ea298a4caf080a4fdf9dac09bcbe75 30230 pcp-webapi_3.9.0_i386.deb Checksums-Sha256: 538c4d9979c988bdf1d0acd5bcd5554a92f9a93d9c797f0c198d3267da533bc1 2462 pcp_3.9.0.dsc a450345c8c875a4b16209e1a13bc93a11f652420a69094d0c5b43242428cec38 5257496 pcp_3.9.0.tar.xz e436f1dadeedd554f029be093aa2a6682003bd12821963fde914a61886a3cc11 1133528 pcp_3.9.0_i386.deb 9014c3e6c9a2a4c1c05ff694607787cb7d4e0e872ba584245a50778726ae5a0d 14644 pcp-conf_3.9.0_i386.deb 5a261a72f2b8b92f95d8a21dc8e167f060b34a92e2ae9235ab5051ceb10e073a 370590 libpcp3-dev_3.9.0_i386.deb 32d0c846b006c410d3e12c69de285a950781079c8523628a35e9b85718375973 167624 libpcp3_3.9.0_i386.deb ad14c37cc5023a75ccc6d6ccc5274ee5c86c31d483e448d341acfe50f66a88f7 15602 libpcp-gui2-dev_3.9.0_i386.deb 337e6924a93868fb1d44bb611d06049ca6a6494f1e507e150eb8574390db8911 14400 libpcp-gui2_3.9.0_i386.deb 182bcba8b4185738ed2ef2d3176670c77abbe24521ccbbe9c6318ab4686cc9ef 18216 libpcp-mmv1-dev_3.9.0_i386.deb e5337b3abf4f64d86a242927bb65234c3ae4e3232d59c71000ef6ef996235a83 11504 libpcp-mmv1_3.9.0_i386.deb acfdcf27d921df488715b91f29ab85bd4b89aaca4317f0e519244e977c203666 91604 libpcp-pmda3-dev_3.9.0_i386.deb fee200ac231850ae5486735e504033f45cae993bcdf63347935f5f1a086632b2 34332 libpcp-pmda3_3.9.0_i386.deb d0d62e5ff03916f595038b28ccffb3a874b17b20bb315802faa184e9e9db5672 25814 libpcp-trace2-dev_3.9.0_i386.deb ca3603bc4337e007a1198d5fb6d0629f6739ed07266b4abb16536c51c54d511d 18298 libpcp-trace2_3.9.0_i386.deb ea27fad54db3e030f49b75d8ecd40ce6bed6ed9f9319b97454678cf0faf60c8b 15310 libpcp-import1-dev_3.9.0_i386.deb 6628e3057ab24a6208f761dcc6e4cea222d803004481878ea107588e00a977de 14802 libpcp-import1_3.9.0_i386.deb 0ca5936506dc42c18b710c931b7aa88ace79f2c9e6f47740c2ef8b699068e693 39900 python-pcp_3.9.0_i386.deb 02fdf8f7b986b9602bf9877a2d59db15115560bb023f1ddbf3f8f653b6b22cfa 30708 libpcp-pmda-perl_3.9.0_i386.deb 4977b964523fd647a8c80bedd6657b5df08957c50996259e597aed63a7319767 15962 libpcp-import-perl_3.9.0_i386.deb 96e8830e67dece19e1970d6ef00111caad3f2a87f93e10ce7e6161379a9d9f2f 10906 libpcp-logsummary-perl_3.9.0_i386.deb fe8a07970e6a8306b3a9fd71c6e07af1cdc1eb5d7bc5a7dc77efc315d9c2e69e 17220 libpcp-mmv-perl_3.9.0_i386.deb ab72517046afc9347ce852f4b16af9a0eee09bb909cdf0c911e2db5645c0e895 16194 pcp-import-sar2pcp_3.9.0_all.deb 2403d6d61e702f8aabfd019fa8d1746588cda6c9f441a9827ef7f6be0631c880 10056 pcp-import-mrtg2pcp_3.9.0_all.deb 3daa22f21e02799167a6b99ee8a3d6524b609805936fd3470382ae88431b9f7f 19056 pcp-import-sheet2pcp_3.9.0_all.deb bae5c6e370c27cf8d3cbaf5ae6929706904eb962b8d44525a43265a354235939 17726 pcp-import-iostat2pcp_3.9.0_all.deb ebcc9a2cbc8aeacc19fc34acd12b1cf3ad905219a59524bb1445180d12527da3 22814 pcp-import-collectl2pcp_3.9.0_i386.deb a0323d7d7bc7f0d85580746a5428305ec38c70f8fd6a00fb74c0dcf23a9069ba 2214498 pcp-testsuite_3.9.0_i386.deb 5848f5a4546db298670756db23ab29032e7a8bd93467bf143c447a4eafb01148 45968 pcp-manager_3.9.0_i386.deb abbc555f9a68f25a99bc6165ac62315bfcd0f147659f8eb3df587cb130b69b3d 30230 pcp-webapi_3.9.0_i386.deb Files: f7aa42bd369573cf8d4e2b9377061bfb 2462 utils extra pcp_3.9.0.dsc 7b307671cba12db5d0a07f7cc2b8c673 5257496 utils extra pcp_3.9.0.tar.xz bee93ef250ebe7fd2da942f47e0587bf 1133528 utils extra pcp_3.9.0_i386.deb e17bf3254a55c74fb06554688e8c7a66 14644 libs extra pcp-conf_3.9.0_i386.deb 38ce23e15d530a3a10d2a5833962e8a0 370590 libdevel extra libpcp3-dev_3.9.0_i386.deb aa09329a8140445cb2de38ea75182386 167624 libs extra libpcp3_3.9.0_i386.deb 4886161facffcb1a0d609bd8d8d09e72 15602 libdevel extra libpcp-gui2-dev_3.9.0_i386.deb 1409a5fa672a7e09e7809612c14c61cf 14400 libs extra libpcp-gui2_3.9.0_i386.deb 97f7fec48f237bb39c23c66d2effd13f 18216 libdevel extra libpcp-mmv1-dev_3.9.0_i386.deb 25c11898fb9d36e476e024216ec9a25d 11504 libs extra libpcp-mmv1_3.9.0_i386.deb b16298012d4fa7815e7d1e5cf7fe476f 91604 libdevel extra libpcp-pmda3-dev_3.9.0_i386.deb 26d1294e553822303cb68cb1e1ab62df 34332 libs extra libpcp-pmda3_3.9.0_i386.deb 1a99b010343b246c0f8315e87d1d269a 25814 libdevel extra libpcp-trace2-dev_3.9.0_i386.deb 07ebdc7022c613d9d3445c3a926dfbc7 18298 libs extra libpcp-trace2_3.9.0_i386.deb 5f2ee0b5966926091a09d77435270725 15310 libdevel extra libpcp-import1-dev_3.9.0_i386.deb 3ad15d05b569ab0aa38c1ce2d11191c9 14802 libs extra libpcp-import1_3.9.0_i386.deb c5f7b19de8d24fae0f18e5e98532db27 39900 python extra python-pcp_3.9.0_i386.deb 0f0cff52207652fa66be333517d6fc60 30708 perl extra libpcp-pmda-perl_3.9.0_i386.deb 75034386a942fb24cb03afcc5f0e56a0 15962 perl extra libpcp-import-perl_3.9.0_i386.deb 66f615178ef589aec48ddec03eef8796 10906 perl extra libpcp-logsummary-perl_3.9.0_i386.deb f6903456a674c7124b8c3218ecca970f 17220 perl extra libpcp-mmv-perl_3.9.0_i386.deb 77b0bbe616461f504083a50d2e1ec1e3 16194 utils extra pcp-import-sar2pcp_3.9.0_all.deb e408b60d75e80dd738747502356ab140 10056 utils extra pcp-import-mrtg2pcp_3.9.0_all.deb 3a6e0b119ff25914f0b4a9d0d471904a 19056 utils extra pcp-import-sheet2pcp_3.9.0_all.deb a5abfa7f71f091b8f5af8a30a86b6a7e 17726 utils extra pcp-import-iostat2pcp_3.9.0_all.deb 2426ff81271ee50690a54cbf5aa2cc9d 22814 utils extra pcp-import-collectl2pcp_3.9.0_i386.deb fbe5ac8c5886efd51a8ee820960e6658 2214498 utils extra pcp-testsuite_3.9.0_i386.deb ad44bddd5df562928a93c5d67eb85362 45968 utils extra pcp-manager_3.9.0_i386.deb 515d067e598010b1385330847a2b356c 30230 utils extra pcp-webapi_3.9.0_i386.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlMFWEwACgkQm8fl3HSIa2MbTQCdEIz47AHivZQqyngNQUj6uGwn FnoAoJ2W0MyYx+UFEUb/uhG4CsEakRTc =cxix -----END PGP SIGNATURE----- Thank you for your contribution to Debian. From debbugs@buxtehude.debian.org Mon Feb 24 05:04:32 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id D2E597F59 for ; Mon, 24 Feb 2014 05:04:31 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 67F4BAC005 for ; Mon, 24 Feb 2014 03:04:31 -0800 (PST) X-ASG-Debug-ID: 1393239868-04bdf00fc0337380001-S8gJnT Received: from buxtehude.debian.org (buxtehude.debian.org [140.211.166.26]) by cuda.sgi.com with ESMTP id 4RCNYVMkbCEHyaCF (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 24 Feb 2014 03:04:29 -0800 (PST) X-Barracuda-Envelope-From: debbugs@buxtehude.debian.org X-Barracuda-Apparent-Source-IP: 140.211.166.26 Received: from debbugs by buxtehude.debian.org with local (Exim 4.80) (envelope-from ) id 1WHtKj-0002zg-Ll; Mon, 24 Feb 2014 11:04:25 +0000 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: owner@bugs.debian.org From: owner@bugs.debian.org (Debian Bug Tracking System) To: Nathan Scott Subject: Bug#737340: marked as done (pcp: use autotools-dev to update config.{sub,guess} for new arches) Message-ID: X-ASG-Orig-Subj: Bug#737340: marked as done (pcp: use autotools-dev to update config.{sub,guess} for new arches) References: <20140201203247.3705.32398.reportbug@logan-VirtualBox> X-Debian-PR-Message: closed 737340 X-Debian-PR-Package: pcp X-Debian-PR-Keywords: patch X-Debian-PR-Source: pcp Date: Mon, 24 Feb 2014 11:04:25 +0000 Content-Type: multipart/mixed; boundary="----------=_1393239865-11501-0" Sender: Debian BTS X-Barracuda-Connect: buxtehude.debian.org[140.211.166.26] X-Barracuda-Start-Time: 1393239869 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145457 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- This is a multi-part message in MIME format... ------------=_1393239865-11501-0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Your message dated Mon, 24 Feb 2014 11:00:08 +0000 with message-id and subject line Bug#737340: fixed in pcp 3.9.0 has caused the Debian Bug report #737340, regarding pcp: use autotools-dev to update config.{sub,guess} for new arches to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) --=20 737340: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D737340 Debian Bug Tracking System Contact owner@bugs.debian.org with problems ------------=_1393239865-11501-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by bugs.debian.org; 1 Feb 2014 20:32:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2-bugs.debian.org_2005_01_02 (2011-06-06) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-11.7 required=4.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FOURLA,FREEMAIL_FROM,HAS_PACKAGE,MURPHY_DRUGS_REL8, RCVD_IN_DNSWL_LOW,SPF_PASS,XMAILER_REPORTBUG autolearn=ham version=3.3.2-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 12; hammy, 151; neutral, 202; spammy, 0. spammytokens: hammytokens:0.000-+--H*r:TLSv1.2, 0.000-+--H*F:D*ubuntu.com, 0.000-+--H*M:reportbug, 0.000-+--H*MI:reportbug, 0.000-+--H*x:reportbug Return-path: Received: from mail-qc0-f182.google.com ([209.85.216.182]) by buxtehude.debian.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from ) id 1W9hFF-0006YA-2f for submit@bugs.debian.org; Sat, 01 Feb 2014 20:32:53 +0000 Received: by mail-qc0-f182.google.com with SMTP id c9so9132418qcz.13 for ; Sat, 01 Feb 2014 12:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:from:to:subject:message-id:date; bh=CDgjXJWavcl0OX8FG1BSC6TjoDqgRPGgnWXvsojbK/E=; b=JdXVeL9vsxc4odml3+jLxP5utMUb2NAaK4dlXbAnt3Lqg1vnSqhGOwJx/mF7VnFkZ4 Wd/p/jzVdh/PaqboXWP0Sr8H9MRZStlEQxsET041iQs1XZd+P+ofqu96pITHo2/1OBp9 fdvlfGMwWKXJptmJgt0JY4hDL7GpuNrzzgGIXqhvHJ3ER77QZseUM9aTyEpiDDITc6Jm yoOzgp5mjrUW1ggAmhcceN6SCg2qSAHVH45nkRgKloETGpkTb5fnmBmlzjqaG4DRkHTP g4wg1MND1hZYVodOdJdgF+MV5P+jhB39ANIJrRxtNyHTgJmRo84YTYX3wx4xhV1l1C0A oH1g== X-Received: by 10.140.42.51 with SMTP id b48mr41057392qga.23.1391286766938; Sat, 01 Feb 2014 12:32:46 -0800 (PST) Received: from [127.0.1.1] (nat-128-84-124-0-627.cit.cornell.edu. [128.84.126.115]) by mx.google.com with ESMTPSA id o68sm19424847qge.8.2014.02.01.12.32.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 01 Feb 2014 12:32:46 -0800 (PST) Sender: Logan Rosen Content-Type: multipart/mixed; boundary="===============2182504735896600445==" MIME-Version: 1.0 From: Logan Rosen To: Debian Bug Tracking System Subject: pcp: use autotools-dev to update config.{sub,guess} for new arches Message-ID: <20140201203247.3705.32398.reportbug@logan-VirtualBox> X-Mailer: reportbug 6.5.0ubuntu1 Date: Sat, 01 Feb 2014 15:32:47 -0500 Delivered-To: submit@bugs.debian.org This is a multi-part MIME message sent by reportbug. --===============2182504735896600445== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Package: pcp Version: 3.8.12 Severity: normal Tags: patch User: ubuntu-devel@lists.ubuntu.com Usertags: origin-ubuntu trusty ubuntu-patch Dear Maintainer, Please use autotools-dev to update config.{sub,guess} for new architectures. For example, we needed these updates in Ubuntu for the new arm64 and ppc64el architectures. In Ubuntu, the attached patch was applied to achieve the following: * Use autotools-dev to update config.{sub,guess} for new arches. Thanks for considering the patch. Logan Rosen -- System Information: Debian Release: jessie/sid APT prefers trusty-updates APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty'), (100, 'trusty-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-6-generic (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --===============2182504735896600445== Content-Type: text/x-diff; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pcp_3.8.12ubuntu1.debdiff" === modified file 'debian/control' --- debian/control 2013-11-03 07:25:23 +0000 +++ debian/control 2014-02-01 20:31:34 +0000 @@ -2,9 +2,9 @@ Section: utils Priority: extra Homepage: http://oss.sgi.com/projects/pcp Maintainer: PCP Development Team Uploaders: Nathan Scott , Anibal Monsalve Salazar -Build-Depends: bison, flex, gawk, procps, pkg-config, debhelper (>= 5), perl (>= 5.6), libreadline-dev | libreadline5-dev | libreadline-gplv2-dev, chrpath, libbsd-dev [kfreebsd-any], libkvm-dev [kfreebsd-any], python-all, python-all-dev, libnspr4-dev, libnss3-dev, libsasl2-dev, libmicrohttpd-dev, libavahi-common-dev +Build-Depends: bison, flex, gawk, procps, pkg-config, debhelper (>= 5), perl (>= 5.6), libreadline-dev | libreadline5-dev | libreadline-gplv2-dev, chrpath, libbsd-dev [kfreebsd-any], libkvm-dev [kfreebsd-any], python-all, python-all-dev, libnspr4-dev, libnss3-dev, libsasl2-dev, libmicrohttpd-dev, libavahi-common-dev, autotools-dev #Architecture-dependent -- Build-Depends: libibumad-dev, libibmad-dev Standards-Version: 3.9.3 X-Python-Version: >= 2.6 === modified file 'debian/rules' --- debian/rules 2013-09-09 18:20:08 +0000 +++ debian/rules 2014-01-29 20:32:01 +0000 @@ -109,6 +109,7 @@ .census: @echo "== dpkg-buildpackage: configure" 1>&2 $(checkdir) + dh_autotools-dev_updateconfig $(configure_tools) ./configure $(configure_paths) touch .census @@ -119,6 +120,8 @@ $(MAKE) realclean -rm -rf $(alldir) -rm -f debian/*substvars debian/files* debian/*.debhelper + dh_autotools-dev_restoreconfig + dh_clean binary-indep: --===============2182504735896600445==-- ------------=_1393239865-11501-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 737340-close) by bugs.debian.org; 24 Feb 2014 11:00:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2-bugs.debian.org_2005_01_02 (2011-06-06) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-12.8 required=4.0 tests=BAYES_00,DIGITS_LETTERS, FOURLA,FROMDEVELOPER,FVGT_m_MULTI_ODD,HAS_BUG_NUMBER,PGPSIGNATURE, RCVD_IN_DNSWL_MED,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 154; hammy, 151; neutral, 226; spammy, 0. spammytokens: hammytokens:0.000-+--HX-Debian:DAK, 0.000-+--H*rp:D*ftp-master.debian.org, 0.000-+--H*MI:franck, 0.000-+--H*m:franck, 0.000-+--Hx-spam-relays-external:sk:franck. Return-path: Received: from franck.debian.org ([138.16.160.12]) from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=franck.debian.org,EMAIL=hostmaster@franck.debian.org (verified) by buxtehude.debian.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WHtGe-0002SQ-7Q for 737340-close@bugs.debian.org; Mon, 24 Feb 2014 11:00:12 +0000 Received: from dak by franck.debian.org with local (Exim 4.80) (envelope-from ) id 1WHtGa-0008JZ-2t; Mon, 24 Feb 2014 11:00:08 +0000 From: Nathan Scott To: 737340-close@bugs.debian.org X-DAK: dak process-policy X-Debian: DAK X-Debian-Package: pcp MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Bug#737340: fixed in pcp 3.9.0 Message-Id: Sender: Archive Administrator Date: Mon, 24 Feb 2014 11:00:08 +0000 X-CrossAssassin-Score: 2 Source: pcp Source-Version: 3.9.0 We believe that the bug you reported is fixed in the latest version of pcp, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 737340@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Nathan Scott (supplier of updated pcp package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Wed, 19 Feb 2014 10:38:40 +1100 Source: pcp Binary: pcp pcp-conf libpcp3-dev libpcp3 libpcp-gui2-dev libpcp-gui2 libpcp-mmv1-dev libpcp-mmv1 libpcp-pmda3-dev libpcp-pmda3 libpcp-trace2-dev libpcp-trace2 libpcp-import1-dev libpcp-import1 python-pcp libpcp-pmda-perl libpcp-import-perl libpcp-logsummary-perl libpcp-mmv-perl pcp-import-sar2pcp pcp-import-mrtg2pcp pcp-import-sheet2pcp pcp-import-iostat2pcp pcp-import-collectl2pcp pcp-testsuite pcp-manager pcp-webapi Architecture: source i386 all Version: 3.9.0 Distribution: unstable Urgency: low Maintainer: PCP Development Team Changed-By: Nathan Scott Description: libpcp-gui2 - Performance Co-Pilot graphical client tools library libpcp-gui2-dev - Performance Co-Pilot graphical client tools library and headers libpcp-import-perl - Performance Co-Pilot log import Perl module libpcp-import1 - Performance Co-Pilot data import library libpcp-import1-dev - Performance Co-Pilot data import library and headers libpcp-logsummary-perl - Performance Co-Pilot historical log summary module libpcp-mmv-perl - Performance Co-Pilot Memory Mapped Value Perl module libpcp-mmv1 - Performance Co-Pilot Memory Mapped Value client library libpcp-mmv1-dev - Performance Co-Pilot Memory Mapped Value library and headers libpcp-pmda-perl - Performance Co-Pilot Domain Agent Perl module libpcp-pmda3 - Performance Co-Pilot Domain Agent library libpcp-pmda3-dev - Performance Co-Pilot Domain Agent library and headers libpcp-trace2 - Performance Co-Pilot application tracing library libpcp-trace2-dev - Performance Co-Pilot application tracing library and headers libpcp3 - Performance Co-Pilot library libpcp3-dev - Performance Co-Pilot library and headers pcp - System level performance monitoring and performance management pcp-conf - Performance Co-Pilot runtime configuration pcp-import-collectl2pcp - Tool for importing data from collectl into PCP archive logs pcp-import-iostat2pcp - Tool for importing data from iostat into PCP archive logs pcp-import-mrtg2pcp - Tool for importing data from MRTG into PCP archive logs pcp-import-sar2pcp - Tool for importing data from sar into PCP archive logs pcp-import-sheet2pcp - Tool for importing data from a spreadsheet into PCP archive logs pcp-manager - Performance Co-Pilot (PCP) manager daemon pcp-testsuite - Performance Co-Pilot (PCP) Test Suite pcp-webapi - Performance Co-Pilot (PCP) web API service python-pcp - Performance Co-Pilot Python PMAPI module Closes: 655440 737340 Changes: pcp (3.9.0) unstable; urgency=low . * New release (full details in CHANGELOG). * Use autotools-dev to update config.{sub,guess} (closes: #737340) * Split libpcp3 library and configuration files (closes: #655440) Checksums-Sha1: 845da697184dc760e452477cc4290ea172b5f37b 2462 pcp_3.9.0.dsc 8eafdd2b5b0e1ae3c07c24b98665fb306c4632d8 5257496 pcp_3.9.0.tar.xz a71102de08f9e16526b5b803a5d23ec5fad234f2 1133528 pcp_3.9.0_i386.deb 9936620d8927e93d93db0bb61d91486cd592c978 14644 pcp-conf_3.9.0_i386.deb def91f7117e57e97612e51101acffe57282f7c81 370590 libpcp3-dev_3.9.0_i386.deb c82b66782af8b2e53a4f935f0c9d604656c31ee1 167624 libpcp3_3.9.0_i386.deb f38399acbe5424c3dbb752c15adbdcac52aaf915 15602 libpcp-gui2-dev_3.9.0_i386.deb 2da393b9fbae67fc2bba699fcf5a202acb2e68a2 14400 libpcp-gui2_3.9.0_i386.deb 878d1cb30dce04c1892ca90f905063126273b1de 18216 libpcp-mmv1-dev_3.9.0_i386.deb b6f51139753c81c5eae5e10b1eb66bab287aefeb 11504 libpcp-mmv1_3.9.0_i386.deb c318543fe9bec8a96e5b842e32542de20c9dce7c 91604 libpcp-pmda3-dev_3.9.0_i386.deb 72d3274b84488b16ffa4da495524cd4fa556464b 34332 libpcp-pmda3_3.9.0_i386.deb e1108c4ac6f3deb9239129194b7a150024ff0a27 25814 libpcp-trace2-dev_3.9.0_i386.deb e7098e4f97ce0aa41dd7d1bdbd5130d8f199b2cd 18298 libpcp-trace2_3.9.0_i386.deb 6d61056f534f1415fc4398c98aaf8831b5e09975 15310 libpcp-import1-dev_3.9.0_i386.deb a79810fa40cf2e2c6acc98deab513720bef2dce6 14802 libpcp-import1_3.9.0_i386.deb 61cd469388f98b17bb963c4a95052e1d4c6ae273 39900 python-pcp_3.9.0_i386.deb eaa3d2b327ceacb175d4e89930e20ad6632089a2 30708 libpcp-pmda-perl_3.9.0_i386.deb fc079bab65d13281278830a3c63c6351de72bddb 15962 libpcp-import-perl_3.9.0_i386.deb 68fa131a0f9c843934eec78c5943509426a1ea1c 10906 libpcp-logsummary-perl_3.9.0_i386.deb e7dfa5e7b94dc6f953eda1e2891dbab3f4c9f775 17220 libpcp-mmv-perl_3.9.0_i386.deb 19e5ea702a35ab15e364b926b537b8a6a6d7262f 16194 pcp-import-sar2pcp_3.9.0_all.deb 226b03b267fa68bb1404d7e4a654534c01cae5bc 10056 pcp-import-mrtg2pcp_3.9.0_all.deb fd786ff986dec688da99dff43bb5198169e8f6fb 19056 pcp-import-sheet2pcp_3.9.0_all.deb dc52e9af89fa456bd5ceda712d5182252203d734 17726 pcp-import-iostat2pcp_3.9.0_all.deb d122de094f41f9260dcc2e1a35e80bcef7d00ae1 22814 pcp-import-collectl2pcp_3.9.0_i386.deb be0b8a9d87d7c6f495f2cecb1d8f45ae448dd494 2214498 pcp-testsuite_3.9.0_i386.deb 23cf4b36b673a0121a76e56c0013cd2eac1b12d4 45968 pcp-manager_3.9.0_i386.deb 303fa05750ea298a4caf080a4fdf9dac09bcbe75 30230 pcp-webapi_3.9.0_i386.deb Checksums-Sha256: 538c4d9979c988bdf1d0acd5bcd5554a92f9a93d9c797f0c198d3267da533bc1 2462 pcp_3.9.0.dsc a450345c8c875a4b16209e1a13bc93a11f652420a69094d0c5b43242428cec38 5257496 pcp_3.9.0.tar.xz e436f1dadeedd554f029be093aa2a6682003bd12821963fde914a61886a3cc11 1133528 pcp_3.9.0_i386.deb 9014c3e6c9a2a4c1c05ff694607787cb7d4e0e872ba584245a50778726ae5a0d 14644 pcp-conf_3.9.0_i386.deb 5a261a72f2b8b92f95d8a21dc8e167f060b34a92e2ae9235ab5051ceb10e073a 370590 libpcp3-dev_3.9.0_i386.deb 32d0c846b006c410d3e12c69de285a950781079c8523628a35e9b85718375973 167624 libpcp3_3.9.0_i386.deb ad14c37cc5023a75ccc6d6ccc5274ee5c86c31d483e448d341acfe50f66a88f7 15602 libpcp-gui2-dev_3.9.0_i386.deb 337e6924a93868fb1d44bb611d06049ca6a6494f1e507e150eb8574390db8911 14400 libpcp-gui2_3.9.0_i386.deb 182bcba8b4185738ed2ef2d3176670c77abbe24521ccbbe9c6318ab4686cc9ef 18216 libpcp-mmv1-dev_3.9.0_i386.deb e5337b3abf4f64d86a242927bb65234c3ae4e3232d59c71000ef6ef996235a83 11504 libpcp-mmv1_3.9.0_i386.deb acfdcf27d921df488715b91f29ab85bd4b89aaca4317f0e519244e977c203666 91604 libpcp-pmda3-dev_3.9.0_i386.deb fee200ac231850ae5486735e504033f45cae993bcdf63347935f5f1a086632b2 34332 libpcp-pmda3_3.9.0_i386.deb d0d62e5ff03916f595038b28ccffb3a874b17b20bb315802faa184e9e9db5672 25814 libpcp-trace2-dev_3.9.0_i386.deb ca3603bc4337e007a1198d5fb6d0629f6739ed07266b4abb16536c51c54d511d 18298 libpcp-trace2_3.9.0_i386.deb ea27fad54db3e030f49b75d8ecd40ce6bed6ed9f9319b97454678cf0faf60c8b 15310 libpcp-import1-dev_3.9.0_i386.deb 6628e3057ab24a6208f761dcc6e4cea222d803004481878ea107588e00a977de 14802 libpcp-import1_3.9.0_i386.deb 0ca5936506dc42c18b710c931b7aa88ace79f2c9e6f47740c2ef8b699068e693 39900 python-pcp_3.9.0_i386.deb 02fdf8f7b986b9602bf9877a2d59db15115560bb023f1ddbf3f8f653b6b22cfa 30708 libpcp-pmda-perl_3.9.0_i386.deb 4977b964523fd647a8c80bedd6657b5df08957c50996259e597aed63a7319767 15962 libpcp-import-perl_3.9.0_i386.deb 96e8830e67dece19e1970d6ef00111caad3f2a87f93e10ce7e6161379a9d9f2f 10906 libpcp-logsummary-perl_3.9.0_i386.deb fe8a07970e6a8306b3a9fd71c6e07af1cdc1eb5d7bc5a7dc77efc315d9c2e69e 17220 libpcp-mmv-perl_3.9.0_i386.deb ab72517046afc9347ce852f4b16af9a0eee09bb909cdf0c911e2db5645c0e895 16194 pcp-import-sar2pcp_3.9.0_all.deb 2403d6d61e702f8aabfd019fa8d1746588cda6c9f441a9827ef7f6be0631c880 10056 pcp-import-mrtg2pcp_3.9.0_all.deb 3daa22f21e02799167a6b99ee8a3d6524b609805936fd3470382ae88431b9f7f 19056 pcp-import-sheet2pcp_3.9.0_all.deb bae5c6e370c27cf8d3cbaf5ae6929706904eb962b8d44525a43265a354235939 17726 pcp-import-iostat2pcp_3.9.0_all.deb ebcc9a2cbc8aeacc19fc34acd12b1cf3ad905219a59524bb1445180d12527da3 22814 pcp-import-collectl2pcp_3.9.0_i386.deb a0323d7d7bc7f0d85580746a5428305ec38c70f8fd6a00fb74c0dcf23a9069ba 2214498 pcp-testsuite_3.9.0_i386.deb 5848f5a4546db298670756db23ab29032e7a8bd93467bf143c447a4eafb01148 45968 pcp-manager_3.9.0_i386.deb abbc555f9a68f25a99bc6165ac62315bfcd0f147659f8eb3df587cb130b69b3d 30230 pcp-webapi_3.9.0_i386.deb Files: f7aa42bd369573cf8d4e2b9377061bfb 2462 utils extra pcp_3.9.0.dsc 7b307671cba12db5d0a07f7cc2b8c673 5257496 utils extra pcp_3.9.0.tar.xz bee93ef250ebe7fd2da942f47e0587bf 1133528 utils extra pcp_3.9.0_i386.deb e17bf3254a55c74fb06554688e8c7a66 14644 libs extra pcp-conf_3.9.0_i386.deb 38ce23e15d530a3a10d2a5833962e8a0 370590 libdevel extra libpcp3-dev_3.9.0_i386.deb aa09329a8140445cb2de38ea75182386 167624 libs extra libpcp3_3.9.0_i386.deb 4886161facffcb1a0d609bd8d8d09e72 15602 libdevel extra libpcp-gui2-dev_3.9.0_i386.deb 1409a5fa672a7e09e7809612c14c61cf 14400 libs extra libpcp-gui2_3.9.0_i386.deb 97f7fec48f237bb39c23c66d2effd13f 18216 libdevel extra libpcp-mmv1-dev_3.9.0_i386.deb 25c11898fb9d36e476e024216ec9a25d 11504 libs extra libpcp-mmv1_3.9.0_i386.deb b16298012d4fa7815e7d1e5cf7fe476f 91604 libdevel extra libpcp-pmda3-dev_3.9.0_i386.deb 26d1294e553822303cb68cb1e1ab62df 34332 libs extra libpcp-pmda3_3.9.0_i386.deb 1a99b010343b246c0f8315e87d1d269a 25814 libdevel extra libpcp-trace2-dev_3.9.0_i386.deb 07ebdc7022c613d9d3445c3a926dfbc7 18298 libs extra libpcp-trace2_3.9.0_i386.deb 5f2ee0b5966926091a09d77435270725 15310 libdevel extra libpcp-import1-dev_3.9.0_i386.deb 3ad15d05b569ab0aa38c1ce2d11191c9 14802 libs extra libpcp-import1_3.9.0_i386.deb c5f7b19de8d24fae0f18e5e98532db27 39900 python extra python-pcp_3.9.0_i386.deb 0f0cff52207652fa66be333517d6fc60 30708 perl extra libpcp-pmda-perl_3.9.0_i386.deb 75034386a942fb24cb03afcc5f0e56a0 15962 perl extra libpcp-import-perl_3.9.0_i386.deb 66f615178ef589aec48ddec03eef8796 10906 perl extra libpcp-logsummary-perl_3.9.0_i386.deb f6903456a674c7124b8c3218ecca970f 17220 perl extra libpcp-mmv-perl_3.9.0_i386.deb 77b0bbe616461f504083a50d2e1ec1e3 16194 utils extra pcp-import-sar2pcp_3.9.0_all.deb e408b60d75e80dd738747502356ab140 10056 utils extra pcp-import-mrtg2pcp_3.9.0_all.deb 3a6e0b119ff25914f0b4a9d0d471904a 19056 utils extra pcp-import-sheet2pcp_3.9.0_all.deb a5abfa7f71f091b8f5af8a30a86b6a7e 17726 utils extra pcp-import-iostat2pcp_3.9.0_all.deb 2426ff81271ee50690a54cbf5aa2cc9d 22814 utils extra pcp-import-collectl2pcp_3.9.0_i386.deb fbe5ac8c5886efd51a8ee820960e6658 2214498 utils extra pcp-testsuite_3.9.0_i386.deb ad44bddd5df562928a93c5d67eb85362 45968 utils extra pcp-manager_3.9.0_i386.deb 515d067e598010b1385330847a2b356c 30230 utils extra pcp-webapi_3.9.0_i386.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlMFWEwACgkQm8fl3HSIa2MbTQCdEIz47AHivZQqyngNQUj6uGwn FnoAoJ2W0MyYx+UFEUb/uhG4CsEakRTc =cxix -----END PGP SIGNATURE----- ------------=_1393239865-11501-0-- From debbugs@buxtehude.debian.org Mon Feb 24 05:04:32 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 4B3307F5A for ; Mon, 24 Feb 2014 05:04:32 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id B9787AC007 for ; Mon, 24 Feb 2014 03:04:31 -0800 (PST) X-ASG-Debug-ID: 1393239866-04cb6c6de174ea00001-S8gJnT Received: from buxtehude.debian.org (buxtehude.debian.org [140.211.166.26]) by cuda.sgi.com with ESMTP id eT4ogA0OtIcTlmu0 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 24 Feb 2014 03:04:26 -0800 (PST) X-Barracuda-Envelope-From: debbugs@buxtehude.debian.org X-Barracuda-Apparent-Source-IP: 140.211.166.26 Received: from debbugs by buxtehude.debian.org with local (Exim 4.80) (envelope-from ) id 1WHtKf-0002zM-8c; Mon, 24 Feb 2014 11:04:21 +0000 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: owner@bugs.debian.org From: owner@bugs.debian.org (Debian Bug Tracking System) To: Nathan Scott Subject: Bug#655440: marked as done (libpcp3 package mixes library and configuration files) Message-ID: X-ASG-Orig-Subj: Bug#655440: marked as done (libpcp3 package mixes library and configuration files) References: X-Debian-PR-Message: closed 655440 X-Debian-PR-Package: pcp X-Debian-PR-Source: pcp Date: Mon, 24 Feb 2014 11:04:21 +0000 Content-Type: multipart/mixed; boundary="----------=_1393239861-11467-0" Sender: Debian BTS X-Barracuda-Connect: buxtehude.debian.org[140.211.166.26] X-Barracuda-Start-Time: 1393239866 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145457 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- This is a multi-part message in MIME format... ------------=_1393239861-11467-0 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Your message dated Mon, 24 Feb 2014 11:00:08 +0000 with message-id and subject line Bug#655440: fixed in pcp 3.9.0 has caused the Debian Bug report #655440, regarding libpcp3 package mixes library and configuration files to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) --=20 655440: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D655440 Debian Bug Tracking System Contact owner@bugs.debian.org with problems ------------=_1393239861-11467-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by bugs.debian.org; 11 Jan 2012 06:26:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.1-bugs.debian.org_2005_01_02 (2010-03-16) on busoni.debian.org X-Spam-Level: X-Spam-Status: No, score=-12.0 required=4.0 tests=BAYES_00,FROMDEVELOPER, HAS_PACKAGE,SPF_PASS autolearn=ham version=3.3.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 22; hammy, 132; neutral, 69; spammy, 2. spammytokens:0.956-+--HContent-type:charset, 0.954-+--HContent-type:text hammytokens:0.000-+--soname, 0.000-+--versioned, 0.000-+--Cristau, 0.000-+--cristau, 0.000-+--UD:conf Return-path: Received: from kenny.its.monash.edu.au ([130.194.13.164]) by busoni.debian.org with esmtp (Exim 4.72) (envelope-from ) id 1Rkrdx-0006oh-Ot for submit@bugs.debian.org; Wed, 11 Jan 2012 06:26:41 +0000 Received: from palin.its.monash.edu.au ([130.194.13.83]) by kenny.its.monash.edu.au (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0LXM006QRCGCVE50@kenny.its.monash.edu.au> for submit@bugs.debian.org; Wed, 11 Jan 2012 16:26:36 +1100 (EST) Received: from palin.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 33B54546BC1 for ; Wed, 11 Jan 2012 16:26:36 +1100 (EST) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by palin.its.monash.edu.au (Postfix) with ESMTPS id AE866546BC0 for ; Wed, 11 Jan 2012 16:26:35 +1100 (EST) Received: by mail-pw0-f54.google.com with SMTP id c3so348311pbc.41 for ; Tue, 10 Jan 2012 21:26:35 -0800 (PST) Received: by 10.68.189.131 with SMTP id gi3mr57468947pbc.51.1326259595292; Tue, 10 Jan 2012 21:26:35 -0800 (PST) Received: by 10.68.22.102 with HTTP; Tue, 10 Jan 2012 21:26:35 -0800 (PST) Date: Wed, 11 Jan 2012 16:26:35 +1100 From: Nathan Scott Subject: libpcp3 package mixes library and configuration files Sender: ndsco1@student.monash.edu To: submit@bugs.debian.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 X-Google-Sender-Auth: 6Bzawe3nDO21ec9uUFlrKv89NF4 X-Greylist: delayed 3602 seconds by postgrey-1.32 at busoni; Wed, 11 Jan 2012 06:26:41 UTC Delivered-To: submit@bugs.debian.org Package: pcp Version: 3.5.11 The way libpcp3 is packaged has the potential to cause problems down the track. In particular, the shared library package contains both the (SONAME versioned) library files and configuration files (pcp.conf, and builddefs/buildrules) in the same package. The problem is if/when we move to a libpcp4 package, this will not be able to be installed at the same time as libpcp3 (which is a major advantage of the Debian shared library packaging, when done correctly). This is because /etc/pcp.conf and some other files will conflict between the packages. Discussion with Julien Cristau (jcristau@debian.org) in the context of bug 654616, where further discussion on this topic can be found, identified three potential ways to address the problem, paraphrased as: 1. make libpcp.so not require pcp.conf (and probably move it to pcp package) 2. create a separate package for the configuration files (these are the core config files - i.e. pcp.conf - and also the builddefs/buildrules files needed by the layered -dev development packages). 3. use SONAME-specific file names in libpcp3 for the config files (/etc/pcp3.conf) This obviously needs to be addressed before any libpcp4 can ever exist. Its not on the immediate horizon, but pcpv4 plans are well underway and it might well be needed in the medium term. Best to tackle it sooner rather than later anyway. In #654616 I lay out a preference for option #2 but I'll seed feedback from other interested / knowledgeable parties before going far down any particular path. cheers. -- Nathan ------------=_1393239861-11467-0 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 655440-close) by bugs.debian.org; 24 Feb 2014 11:00:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2-bugs.debian.org_2005_01_02 (2011-06-06) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-12.8 required=4.0 tests=BAYES_00,DIGITS_LETTERS, FOURLA,FROMDEVELOPER,FVGT_m_MULTI_ODD,HAS_BUG_NUMBER,PGPSIGNATURE, RCVD_IN_DNSWL_MED,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 154; hammy, 151; neutral, 226; spammy, 0. spammytokens: hammytokens:0.000-+--HX-Debian:DAK, 0.000-+--H*rp:D*ftp-master.debian.org, 0.000-+--H*MI:franck, 0.000-+--H*m:franck, 0.000-+--Hx-spam-relays-external:sk:franck. Return-path: Received: from franck.debian.org ([138.16.160.12]) from C=NA,ST=NA,L=Ankh Morpork,O=Debian SMTP,OU=Debian SMTP CA,CN=franck.debian.org,EMAIL=hostmaster@franck.debian.org (verified) by buxtehude.debian.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1WHtGe-0002SO-4u for 655440-close@bugs.debian.org; Mon, 24 Feb 2014 11:00:12 +0000 Received: from dak by franck.debian.org with local (Exim 4.80) (envelope-from ) id 1WHtGa-0008JT-1t; Mon, 24 Feb 2014 11:00:08 +0000 From: Nathan Scott To: 655440-close@bugs.debian.org X-DAK: dak process-policy X-Debian: DAK X-Debian-Package: pcp MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Bug#655440: fixed in pcp 3.9.0 Message-Id: Sender: Archive Administrator Date: Mon, 24 Feb 2014 11:00:08 +0000 Source: pcp Source-Version: 3.9.0 We believe that the bug you reported is fixed in the latest version of pcp, which is due to be installed in the Debian FTP archive. A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to 655440@bugs.debian.org, and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Nathan Scott (supplier of updated pcp package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Format: 1.8 Date: Wed, 19 Feb 2014 10:38:40 +1100 Source: pcp Binary: pcp pcp-conf libpcp3-dev libpcp3 libpcp-gui2-dev libpcp-gui2 libpcp-mmv1-dev libpcp-mmv1 libpcp-pmda3-dev libpcp-pmda3 libpcp-trace2-dev libpcp-trace2 libpcp-import1-dev libpcp-import1 python-pcp libpcp-pmda-perl libpcp-import-perl libpcp-logsummary-perl libpcp-mmv-perl pcp-import-sar2pcp pcp-import-mrtg2pcp pcp-import-sheet2pcp pcp-import-iostat2pcp pcp-import-collectl2pcp pcp-testsuite pcp-manager pcp-webapi Architecture: source i386 all Version: 3.9.0 Distribution: unstable Urgency: low Maintainer: PCP Development Team Changed-By: Nathan Scott Description: libpcp-gui2 - Performance Co-Pilot graphical client tools library libpcp-gui2-dev - Performance Co-Pilot graphical client tools library and headers libpcp-import-perl - Performance Co-Pilot log import Perl module libpcp-import1 - Performance Co-Pilot data import library libpcp-import1-dev - Performance Co-Pilot data import library and headers libpcp-logsummary-perl - Performance Co-Pilot historical log summary module libpcp-mmv-perl - Performance Co-Pilot Memory Mapped Value Perl module libpcp-mmv1 - Performance Co-Pilot Memory Mapped Value client library libpcp-mmv1-dev - Performance Co-Pilot Memory Mapped Value library and headers libpcp-pmda-perl - Performance Co-Pilot Domain Agent Perl module libpcp-pmda3 - Performance Co-Pilot Domain Agent library libpcp-pmda3-dev - Performance Co-Pilot Domain Agent library and headers libpcp-trace2 - Performance Co-Pilot application tracing library libpcp-trace2-dev - Performance Co-Pilot application tracing library and headers libpcp3 - Performance Co-Pilot library libpcp3-dev - Performance Co-Pilot library and headers pcp - System level performance monitoring and performance management pcp-conf - Performance Co-Pilot runtime configuration pcp-import-collectl2pcp - Tool for importing data from collectl into PCP archive logs pcp-import-iostat2pcp - Tool for importing data from iostat into PCP archive logs pcp-import-mrtg2pcp - Tool for importing data from MRTG into PCP archive logs pcp-import-sar2pcp - Tool for importing data from sar into PCP archive logs pcp-import-sheet2pcp - Tool for importing data from a spreadsheet into PCP archive logs pcp-manager - Performance Co-Pilot (PCP) manager daemon pcp-testsuite - Performance Co-Pilot (PCP) Test Suite pcp-webapi - Performance Co-Pilot (PCP) web API service python-pcp - Performance Co-Pilot Python PMAPI module Closes: 655440 737340 Changes: pcp (3.9.0) unstable; urgency=low . * New release (full details in CHANGELOG). * Use autotools-dev to update config.{sub,guess} (closes: #737340) * Split libpcp3 library and configuration files (closes: #655440) Checksums-Sha1: 845da697184dc760e452477cc4290ea172b5f37b 2462 pcp_3.9.0.dsc 8eafdd2b5b0e1ae3c07c24b98665fb306c4632d8 5257496 pcp_3.9.0.tar.xz a71102de08f9e16526b5b803a5d23ec5fad234f2 1133528 pcp_3.9.0_i386.deb 9936620d8927e93d93db0bb61d91486cd592c978 14644 pcp-conf_3.9.0_i386.deb def91f7117e57e97612e51101acffe57282f7c81 370590 libpcp3-dev_3.9.0_i386.deb c82b66782af8b2e53a4f935f0c9d604656c31ee1 167624 libpcp3_3.9.0_i386.deb f38399acbe5424c3dbb752c15adbdcac52aaf915 15602 libpcp-gui2-dev_3.9.0_i386.deb 2da393b9fbae67fc2bba699fcf5a202acb2e68a2 14400 libpcp-gui2_3.9.0_i386.deb 878d1cb30dce04c1892ca90f905063126273b1de 18216 libpcp-mmv1-dev_3.9.0_i386.deb b6f51139753c81c5eae5e10b1eb66bab287aefeb 11504 libpcp-mmv1_3.9.0_i386.deb c318543fe9bec8a96e5b842e32542de20c9dce7c 91604 libpcp-pmda3-dev_3.9.0_i386.deb 72d3274b84488b16ffa4da495524cd4fa556464b 34332 libpcp-pmda3_3.9.0_i386.deb e1108c4ac6f3deb9239129194b7a150024ff0a27 25814 libpcp-trace2-dev_3.9.0_i386.deb e7098e4f97ce0aa41dd7d1bdbd5130d8f199b2cd 18298 libpcp-trace2_3.9.0_i386.deb 6d61056f534f1415fc4398c98aaf8831b5e09975 15310 libpcp-import1-dev_3.9.0_i386.deb a79810fa40cf2e2c6acc98deab513720bef2dce6 14802 libpcp-import1_3.9.0_i386.deb 61cd469388f98b17bb963c4a95052e1d4c6ae273 39900 python-pcp_3.9.0_i386.deb eaa3d2b327ceacb175d4e89930e20ad6632089a2 30708 libpcp-pmda-perl_3.9.0_i386.deb fc079bab65d13281278830a3c63c6351de72bddb 15962 libpcp-import-perl_3.9.0_i386.deb 68fa131a0f9c843934eec78c5943509426a1ea1c 10906 libpcp-logsummary-perl_3.9.0_i386.deb e7dfa5e7b94dc6f953eda1e2891dbab3f4c9f775 17220 libpcp-mmv-perl_3.9.0_i386.deb 19e5ea702a35ab15e364b926b537b8a6a6d7262f 16194 pcp-import-sar2pcp_3.9.0_all.deb 226b03b267fa68bb1404d7e4a654534c01cae5bc 10056 pcp-import-mrtg2pcp_3.9.0_all.deb fd786ff986dec688da99dff43bb5198169e8f6fb 19056 pcp-import-sheet2pcp_3.9.0_all.deb dc52e9af89fa456bd5ceda712d5182252203d734 17726 pcp-import-iostat2pcp_3.9.0_all.deb d122de094f41f9260dcc2e1a35e80bcef7d00ae1 22814 pcp-import-collectl2pcp_3.9.0_i386.deb be0b8a9d87d7c6f495f2cecb1d8f45ae448dd494 2214498 pcp-testsuite_3.9.0_i386.deb 23cf4b36b673a0121a76e56c0013cd2eac1b12d4 45968 pcp-manager_3.9.0_i386.deb 303fa05750ea298a4caf080a4fdf9dac09bcbe75 30230 pcp-webapi_3.9.0_i386.deb Checksums-Sha256: 538c4d9979c988bdf1d0acd5bcd5554a92f9a93d9c797f0c198d3267da533bc1 2462 pcp_3.9.0.dsc a450345c8c875a4b16209e1a13bc93a11f652420a69094d0c5b43242428cec38 5257496 pcp_3.9.0.tar.xz e436f1dadeedd554f029be093aa2a6682003bd12821963fde914a61886a3cc11 1133528 pcp_3.9.0_i386.deb 9014c3e6c9a2a4c1c05ff694607787cb7d4e0e872ba584245a50778726ae5a0d 14644 pcp-conf_3.9.0_i386.deb 5a261a72f2b8b92f95d8a21dc8e167f060b34a92e2ae9235ab5051ceb10e073a 370590 libpcp3-dev_3.9.0_i386.deb 32d0c846b006c410d3e12c69de285a950781079c8523628a35e9b85718375973 167624 libpcp3_3.9.0_i386.deb ad14c37cc5023a75ccc6d6ccc5274ee5c86c31d483e448d341acfe50f66a88f7 15602 libpcp-gui2-dev_3.9.0_i386.deb 337e6924a93868fb1d44bb611d06049ca6a6494f1e507e150eb8574390db8911 14400 libpcp-gui2_3.9.0_i386.deb 182bcba8b4185738ed2ef2d3176670c77abbe24521ccbbe9c6318ab4686cc9ef 18216 libpcp-mmv1-dev_3.9.0_i386.deb e5337b3abf4f64d86a242927bb65234c3ae4e3232d59c71000ef6ef996235a83 11504 libpcp-mmv1_3.9.0_i386.deb acfdcf27d921df488715b91f29ab85bd4b89aaca4317f0e519244e977c203666 91604 libpcp-pmda3-dev_3.9.0_i386.deb fee200ac231850ae5486735e504033f45cae993bcdf63347935f5f1a086632b2 34332 libpcp-pmda3_3.9.0_i386.deb d0d62e5ff03916f595038b28ccffb3a874b17b20bb315802faa184e9e9db5672 25814 libpcp-trace2-dev_3.9.0_i386.deb ca3603bc4337e007a1198d5fb6d0629f6739ed07266b4abb16536c51c54d511d 18298 libpcp-trace2_3.9.0_i386.deb ea27fad54db3e030f49b75d8ecd40ce6bed6ed9f9319b97454678cf0faf60c8b 15310 libpcp-import1-dev_3.9.0_i386.deb 6628e3057ab24a6208f761dcc6e4cea222d803004481878ea107588e00a977de 14802 libpcp-import1_3.9.0_i386.deb 0ca5936506dc42c18b710c931b7aa88ace79f2c9e6f47740c2ef8b699068e693 39900 python-pcp_3.9.0_i386.deb 02fdf8f7b986b9602bf9877a2d59db15115560bb023f1ddbf3f8f653b6b22cfa 30708 libpcp-pmda-perl_3.9.0_i386.deb 4977b964523fd647a8c80bedd6657b5df08957c50996259e597aed63a7319767 15962 libpcp-import-perl_3.9.0_i386.deb 96e8830e67dece19e1970d6ef00111caad3f2a87f93e10ce7e6161379a9d9f2f 10906 libpcp-logsummary-perl_3.9.0_i386.deb fe8a07970e6a8306b3a9fd71c6e07af1cdc1eb5d7bc5a7dc77efc315d9c2e69e 17220 libpcp-mmv-perl_3.9.0_i386.deb ab72517046afc9347ce852f4b16af9a0eee09bb909cdf0c911e2db5645c0e895 16194 pcp-import-sar2pcp_3.9.0_all.deb 2403d6d61e702f8aabfd019fa8d1746588cda6c9f441a9827ef7f6be0631c880 10056 pcp-import-mrtg2pcp_3.9.0_all.deb 3daa22f21e02799167a6b99ee8a3d6524b609805936fd3470382ae88431b9f7f 19056 pcp-import-sheet2pcp_3.9.0_all.deb bae5c6e370c27cf8d3cbaf5ae6929706904eb962b8d44525a43265a354235939 17726 pcp-import-iostat2pcp_3.9.0_all.deb ebcc9a2cbc8aeacc19fc34acd12b1cf3ad905219a59524bb1445180d12527da3 22814 pcp-import-collectl2pcp_3.9.0_i386.deb a0323d7d7bc7f0d85580746a5428305ec38c70f8fd6a00fb74c0dcf23a9069ba 2214498 pcp-testsuite_3.9.0_i386.deb 5848f5a4546db298670756db23ab29032e7a8bd93467bf143c447a4eafb01148 45968 pcp-manager_3.9.0_i386.deb abbc555f9a68f25a99bc6165ac62315bfcd0f147659f8eb3df587cb130b69b3d 30230 pcp-webapi_3.9.0_i386.deb Files: f7aa42bd369573cf8d4e2b9377061bfb 2462 utils extra pcp_3.9.0.dsc 7b307671cba12db5d0a07f7cc2b8c673 5257496 utils extra pcp_3.9.0.tar.xz bee93ef250ebe7fd2da942f47e0587bf 1133528 utils extra pcp_3.9.0_i386.deb e17bf3254a55c74fb06554688e8c7a66 14644 libs extra pcp-conf_3.9.0_i386.deb 38ce23e15d530a3a10d2a5833962e8a0 370590 libdevel extra libpcp3-dev_3.9.0_i386.deb aa09329a8140445cb2de38ea75182386 167624 libs extra libpcp3_3.9.0_i386.deb 4886161facffcb1a0d609bd8d8d09e72 15602 libdevel extra libpcp-gui2-dev_3.9.0_i386.deb 1409a5fa672a7e09e7809612c14c61cf 14400 libs extra libpcp-gui2_3.9.0_i386.deb 97f7fec48f237bb39c23c66d2effd13f 18216 libdevel extra libpcp-mmv1-dev_3.9.0_i386.deb 25c11898fb9d36e476e024216ec9a25d 11504 libs extra libpcp-mmv1_3.9.0_i386.deb b16298012d4fa7815e7d1e5cf7fe476f 91604 libdevel extra libpcp-pmda3-dev_3.9.0_i386.deb 26d1294e553822303cb68cb1e1ab62df 34332 libs extra libpcp-pmda3_3.9.0_i386.deb 1a99b010343b246c0f8315e87d1d269a 25814 libdevel extra libpcp-trace2-dev_3.9.0_i386.deb 07ebdc7022c613d9d3445c3a926dfbc7 18298 libs extra libpcp-trace2_3.9.0_i386.deb 5f2ee0b5966926091a09d77435270725 15310 libdevel extra libpcp-import1-dev_3.9.0_i386.deb 3ad15d05b569ab0aa38c1ce2d11191c9 14802 libs extra libpcp-import1_3.9.0_i386.deb c5f7b19de8d24fae0f18e5e98532db27 39900 python extra python-pcp_3.9.0_i386.deb 0f0cff52207652fa66be333517d6fc60 30708 perl extra libpcp-pmda-perl_3.9.0_i386.deb 75034386a942fb24cb03afcc5f0e56a0 15962 perl extra libpcp-import-perl_3.9.0_i386.deb 66f615178ef589aec48ddec03eef8796 10906 perl extra libpcp-logsummary-perl_3.9.0_i386.deb f6903456a674c7124b8c3218ecca970f 17220 perl extra libpcp-mmv-perl_3.9.0_i386.deb 77b0bbe616461f504083a50d2e1ec1e3 16194 utils extra pcp-import-sar2pcp_3.9.0_all.deb e408b60d75e80dd738747502356ab140 10056 utils extra pcp-import-mrtg2pcp_3.9.0_all.deb 3a6e0b119ff25914f0b4a9d0d471904a 19056 utils extra pcp-import-sheet2pcp_3.9.0_all.deb a5abfa7f71f091b8f5af8a30a86b6a7e 17726 utils extra pcp-import-iostat2pcp_3.9.0_all.deb 2426ff81271ee50690a54cbf5aa2cc9d 22814 utils extra pcp-import-collectl2pcp_3.9.0_i386.deb fbe5ac8c5886efd51a8ee820960e6658 2214498 utils extra pcp-testsuite_3.9.0_i386.deb ad44bddd5df562928a93c5d67eb85362 45968 utils extra pcp-manager_3.9.0_i386.deb 515d067e598010b1385330847a2b356c 30230 utils extra pcp-webapi_3.9.0_i386.deb -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlMFWEwACgkQm8fl3HSIa2MbTQCdEIz47AHivZQqyngNQUj6uGwn FnoAoJ2W0MyYx+UFEUb/uhG4CsEakRTc =cxix -----END PGP SIGNATURE----- ------------=_1393239861-11467-0-- From debbugs@buxtehude.debian.org Mon Feb 24 14:03:16 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id C8C577F50 for ; Mon, 24 Feb 2014 14:03:16 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id B0C73304053 for ; Mon, 24 Feb 2014 12:03:13 -0800 (PST) X-ASG-Debug-ID: 1393272190-04cbb00c2a76dc20001-S8gJnT Received: from buxtehude.debian.org (buxtehude.debian.org [140.211.166.26]) by cuda.sgi.com with ESMTP id iCAR86cibPaPqqUR (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 24 Feb 2014 12:03:11 -0800 (PST) X-Barracuda-Envelope-From: debbugs@buxtehude.debian.org X-Barracuda-Apparent-Source-IP: 140.211.166.26 Received: from debbugs by buxtehude.debian.org with local (Exim 4.80) (envelope-from ) id 1WI1k2-0001aj-P9; Mon, 24 Feb 2014 20:03:06 +0000 X-Loop: owner@bugs.debian.org Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) Content-Type: text/plain; charset=utf-8 From: owner@bugs.debian.org (Debian Bug Tracking System) To: Aaron M. Ucko CC: pcp@oss.sgi.com Subject: Processed: unarchiving 719734, found 719734 in 3.9.0 Message-ID: X-ASG-Orig-Subj: Processed: unarchiving 719734, found 719734 in 3.9.0 References: <1393272078-2934-bts-ucko@debian.org> X-Debian-PR-Package: src:pcp X-Debian-PR-Source: pcp X-Debian-PR-Message: transcript X-Loop: owner@bugs.debian.org Date: Mon, 24 Feb 2014 20:03:06 +0000 Sender: Debian BTS X-Barracuda-Connect: buxtehude.debian.org[140.211.166.26] X-Barracuda-Start-Time: 1393272191 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145470 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Processing commands for control@bugs.debian.org: > unarchive 719734 Bug #719734 {Done: Nathan Scott } [src:pcp] pcp: FTBFS:= chown: invalid user: 'pcp:pcp' Unarchived Bug 719734 > found 719734 3.9.0 Bug #719734 {Done: Nathan Scott } [src:pcp] pcp: FTBFS:= chown: invalid user: 'pcp:pcp' Marked as found in versions pcp/3.9.0 and reopened. > thanks Stopping processing here. Please contact me if you need assistance. --=20 719734: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D719734 Debian Bug Tracking System Contact owner@bugs.debian.org with problems From nscott@redhat.com Mon Feb 24 14:34:06 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 5DF0C7F50 for ; Mon, 24 Feb 2014 14:34:06 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id ED8FCAC003 for ; Mon, 24 Feb 2014 12:34:02 -0800 (PST) X-ASG-Debug-ID: 1393274041-04bdf00fc035e4d0001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id 4pzkzis6vNC74xf2 for ; Mon, 24 Feb 2014 12:34:01 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1OKY1Of013476 for ; Mon, 24 Feb 2014 15:34:01 -0500 Date: Mon, 24 Feb 2014 15:34:01 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp@oss.sgi.com Message-ID: <448897840.15141136.1393274041119.JavaMail.zimbra@redhat.com> In-Reply-To: <202255002.15137436.1393273992754.JavaMail.zimbra@redhat.com> Subject: pcp updates: pmlogger, deb packaging tweaks MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: pmlogger, deb packaging tweaks Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: pmlogger, deb packaging tweaks Thread-Index: Jysby8mUREO3N8oAIzyj/1jZbjQ+Wg== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1393274041 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145470 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev build/rpm/fedora.spec | 4 ++-- debian/copyright | 2 +- debian/rules | 4 ++-- qa/src/permslist | 4 ++-- src/pmie/GNUmakefile | 2 +- src/pmlogger/GNUmakefile | 2 +- src/pmmgr/GNUmakefile | 4 ++-- 7 files changed, 11 insertions(+), 11 deletions(-) commit feb6204402caeae45a44741dfc808e6a71c52feb Author: Nathan Scott Date: Tue Feb 25 07:22:05 2014 +1100 Fix some build/packaging issues, particularly Debian related The pmmgr makefile was installing its log directory with the wrong group account (PCP_USER instead of PCP_GROUP) - this is benign by default, since these are very likely to be the same. Make pcp-manager and pcp-webapi builds mimic base pcp in their use of the NO_CHOWN install variable. Update copyright notes in debian packaging re version of LGPL. commit 1b7cda16a3df3e72e9c6cdcb7e3006335627b1f9 Author: Nathan Scott Date: Fri Feb 21 14:59:14 2014 +1100 Revert "Remove world readable bit from access pmie and pmlogger tmpdirs." This reverts commit a06928de388bf82832f7886e401add8929b71ccc. Causing significant QA pain, needs more work. From nscott@redhat.com Mon Feb 24 15:05:34 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id B75D07F50 for ; Mon, 24 Feb 2014 15:05:34 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 91B238F804C for ; Mon, 24 Feb 2014 13:05:31 -0800 (PST) X-ASG-Debug-ID: 1393275929-04bdf00fc9360080001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 3EiBj66FzwShYXmX for ; Mon, 24 Feb 2014 13:05:29 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1OL5Ekw003460; Mon, 24 Feb 2014 16:05:14 -0500 Date: Mon, 24 Feb 2014 16:05:14 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: PCP Mailing List Message-ID: <840678160.15162819.1393275914420.JavaMail.zimbra@redhat.com> In-Reply-To: <530B0279.6080607@internode.on.net> References: <530B0279.6080607@internode.on.net> Subject: Re: [pcp] assorted build errors MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] assorted build errors Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: assorted build errors Thread-Index: MKEzhYHwWm8DEEpnrpSj7ve69IpvPQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1393275929 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145471 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > I'm just trying to resurrect my QA farm and the first 2 machines are Ubun= tu > 12.04 and 13.10 >=20 > The former dies with > =3D=3D dpkg-buildpackage: binary-arch > cp: cannot stat `debian/pcp/etc/init.d/pmwebd': No such file or directory > dh_install: cp -a debian/pcp/etc/init.d/pmwebd debian/pcp-webapi//etc/ini= t.d/ > returned exit code 1 > make: *** [binary-arch] Error 2 > dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit st= atus > 2 I've not come across this one. Ohhhhh, actually - hmm, could this be a hos= t that has no libmicrohttpd-dev available? (although, how did we get past th= e build-depends line in that case?) > The latter dies with > =3D=3D dpkg-buildpackage: binary-arch > chown: invalid user: =E2=80=98pcp:pcp=E2=80=99 > make[1]: *** [install] Error 1 > make: *** [binary-arch] Error 2 > dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit st= atus > 2 >=20 > Anyone else seeing anything similar? This second one is now fixed. cheers. -- Nathan From kenj@internode.on.net Mon Feb 24 16:02:09 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 658087F50 for ; Mon, 24 Feb 2014 16:02:09 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 5008B8F806F for ; Mon, 24 Feb 2014 14:02:03 -0800 (PST) X-ASG-Debug-ID: 1393279317-04cbb00c29774120001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id JAwPXfkh6VPOdlFl for ; Mon, 24 Feb 2014 14:01:57 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQBAGLAC1N20aH1/2dsb2JhbAANTINBg1q7I4MHgTWDGQEBAQQjFUABEAsYAgIFFgsCAgkDAgECAUUGDQEHAQGsXXagPReBKY07B4JvgUkBA64c Received: from ppp118-209-161-245.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.161.245]) by ipmail07.adl2.internode.on.net with ESMTP; 25 Feb 2014 08:31:57 +1030 Message-ID: <530BC149.7060600@internode.on.net> Date: Tue, 25 Feb 2014 09:01:45 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nathan Scott CC: PCP Mailing List Subject: Re: [pcp] assorted build errors References: <530B0279.6080607@internode.on.net> <840678160.15162819.1393275914420.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] assorted build errors In-Reply-To: <840678160.15162819.1393275914420.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1393279317 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145472 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 25/02/14 08:05, Nathan Scott wrote: > > ... >> == dpkg-buildpackage: binary-arch >> cp: cannot stat `debian/pcp/etc/init.d/pmwebd': No such file or directory >> dh_install: cp -a debian/pcp/etc/init.d/pmwebd debian/pcp-webapi//etc/init.d/ >> returned exit code 1 >> make: *** [binary-arch] Error 2 >> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status >> 2 > > I've not come across this one. Ohhhhh, actually - hmm, could this be a host > that has no libmicrohttpd-dev available? (although, how did we get past the > build-depends line in that case?) No, it is installed ... $ dpkg -l | grep libmicrohttpd ii libmicrohttpd-dev 0.4.6-1 library embedding HTTP server functionality (development) ii libmicrohttpd5 0.4.6-1 library embedding HTTP server functionality > ... > This second one is now fixed. Thanks and confirmed. From nscott@redhat.com Mon Feb 24 16:27:52 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id A97437F50 for ; Mon, 24 Feb 2014 16:27:52 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id 1810DAC002 for ; Mon, 24 Feb 2014 14:27:48 -0800 (PST) X-ASG-Debug-ID: 1393280866-04cbb00c2b7757a0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id CAHwLUtLxi1B7KTf for ; Mon, 24 Feb 2014 14:27:46 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1OMRVhu023012; Mon, 24 Feb 2014 17:27:31 -0500 Date: Mon, 24 Feb 2014 17:27:31 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: PCP Mailing List Message-ID: <1207513118.15254816.1393280851768.JavaMail.zimbra@redhat.com> In-Reply-To: <530BC149.7060600@internode.on.net> References: <530B0279.6080607@internode.on.net> <840678160.15162819.1393275914420.JavaMail.zimbra@redhat.com> <530BC149.7060600@internode.on.net> Subject: Re: [pcp] assorted build errors MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] assorted build errors Content-Type: multipart/mixed; boundary="----=_Part_15254814_1731080633.1393280851767" X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: assorted build errors Thread-Index: ngPc7+uApDuUFBT/KgvQ5ID76k5c7Q== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1393280866 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145473 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ------=_Part_15254814_1731080633.1393280851767 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > [...] > No, it is installed ... > > $ dpkg -l | grep libmicrohttpd > ii libmicrohttpd-dev 0.4.6-1 > library embedding HTTP server functionality (development) > ii libmicrohttpd5 0.4.6-1 > library embedding HTTP server functionality > Hmmm. May still be a related issue - configure.in checks for: AC_MSG_CHECKING([for libmicrohttpd > 0.9.9]) ... and switches parts of the build off if that's not found. Is there a more recent libmicrohttpd available on that platform? cheers. -- Nathan ------=_Part_15254814_1731080633.1393280851767 Content-Type: text/x-patch; name=deb-microhttpd.patch Content-Disposition: attachment; filename=deb-microhttpd.patch Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2RlYmlhbi9jb250cm9sIGIvZGViaWFuL2NvbnRyb2wKaW5kZXggNWQ0ODA0 Yy4uMTk4YTc0MiAxMDA2NDQKLS0tIGEvZGViaWFuL2NvbnRyb2wKKysrIGIvZGViaWFuL2NvbnRy b2wKQEAgLTQsNyArNCw3IEBAIFByaW9yaXR5OiBleHRyYQogSG9tZXBhZ2U6IGh0dHA6Ly9vc3Mu c2dpLmNvbS9wcm9qZWN0cy9wY3AKIE1haW50YWluZXI6IFBDUCBEZXZlbG9wbWVudCBUZWFtIDxw Y3BAb3NzLnNnaS5jb20+CiBVcGxvYWRlcnM6IE5hdGhhbiBTY290dCA8bmF0aGFuc0BkZWJpYW4u b3JnPiwgQW5pYmFsIE1vbnNhbHZlIFNhbGF6YXIgPGFuaWJhbEBkZWJpYW4ub3JnPgotQnVpbGQt RGVwZW5kczogYmlzb24sIGZsZXgsIGdhd2ssIHByb2NwcywgcGtnLWNvbmZpZywgZGViaGVscGVy ICg+PSA1KSwgcGVybCAoPj0gNS42KSwgbGlicmVhZGxpbmUtZGV2IHwgbGlicmVhZGxpbmU1LWRl diB8IGxpYnJlYWRsaW5lLWdwbHYyLWRldiwgY2hycGF0aCwgbGliYnNkLWRldiBba2ZyZWVic2Qt YW55XSwgbGlia3ZtLWRldiBba2ZyZWVic2QtYW55XSwgcHl0aG9uLWFsbCwgcHl0aG9uLWFsbC1k ZXYsIGxpYm5zcHI0LWRldiwgbGlibnNzMy1kZXYsIGxpYnNhc2wyLWRldiwgbGlibWljcm9odHRw ZC1kZXYsIGxpYmF2YWhpLWNvbW1vbi1kZXYsIGF1dG90b29scy1kZXYKK0J1aWxkLURlcGVuZHM6 IGJpc29uLCBmbGV4LCBnYXdrLCBwcm9jcHMsIHBrZy1jb25maWcsIGRlYmhlbHBlciAoPj0gNSks IHBlcmwgKD49IDUuNiksIGxpYnJlYWRsaW5lLWRldiB8IGxpYnJlYWRsaW5lNS1kZXYgfCBsaWJy ZWFkbGluZS1ncGx2Mi1kZXYsIGNocnBhdGgsIGxpYmJzZC1kZXYgW2tmcmVlYnNkLWFueV0sIGxp Ymt2bS1kZXYgW2tmcmVlYnNkLWFueV0sIHB5dGhvbi1hbGwsIHB5dGhvbi1hbGwtZGV2LCBsaWJu c3ByNC1kZXYsIGxpYm5zczMtZGV2LCBsaWJzYXNsMi1kZXYsIGxpYm1pY3JvaHR0cGQtZGV2ICg+ PSAwLjkuOSksIGxpYmF2YWhpLWNvbW1vbi1kZXYsIGF1dG90b29scy1kZXYKICNBcmNoaXRlY3R1 cmUtZGVwZW5kZW50IC0tIEJ1aWxkLURlcGVuZHM6IGxpYmlidW1hZC1kZXYsIGxpYmlibWFkLWRl dgogU3RhbmRhcmRzLVZlcnNpb246IDMuOS4zCiBYLVB5dGhvbi1WZXJzaW9uOiA+PSAyLjYK ------=_Part_15254814_1731080633.1393280851767-- From debbugs@buxtehude.debian.org Mon Feb 24 16:36:11 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2AFBC7F50 for ; Mon, 24 Feb 2014 16:36:11 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id E1EC9304053 for ; Mon, 24 Feb 2014 14:36:10 -0800 (PST) X-ASG-Debug-ID: 1393281365-04bdf00fc9364d60001-S8gJnT Received: from buxtehude.debian.org (buxtehude.debian.org [140.211.166.26]) by cuda.sgi.com with ESMTP id 6tsdLCho1n77LVwh (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 24 Feb 2014 14:36:06 -0800 (PST) X-Barracuda-Envelope-From: debbugs@buxtehude.debian.org X-Barracuda-Apparent-Source-IP: 140.211.166.26 Received: from debbugs by buxtehude.debian.org with local (Exim 4.80) (envelope-from ) id 1WI484-0001IH-Ru; Mon, 24 Feb 2014 22:36:04 +0000 X-Loop: owner@bugs.debian.org Subject: Bug#739952: [pcp] Bug#739952: missing license in debian/copyright Reply-To: Nathan Scott , 739952@bugs.debian.org X-ASG-Orig-Subj: Bug#739952: [pcp] Bug#739952: missing license in debian/copyright Resent-From: Nathan Scott Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: PCP Development Team X-Loop: owner@bugs.debian.org Resent-Date: Mon, 24 Feb 2014 22:36:02 +0000 Resent-Message-ID: X-Debian-PR-Message: followup 739952 X-Debian-PR-Package: pcp X-Debian-PR-Keywords: X-Debian-PR-Source: pcp Received: via spool by 739952-submit@bugs.debian.org id=B739952.13932811633855 (code B ref 739952); Mon, 24 Feb 2014 22:36:02 +0000 Received: (at 739952) by bugs.debian.org; 24 Feb 2014 22:32:43 +0000 Received: from mx4-phx2.redhat.com ([209.132.183.25]) by buxtehude.debian.org with esmtp (Exim 4.80) (envelope-from ) id 1WI44o-0000zz-HY for 739952@bugs.debian.org; Mon, 24 Feb 2014 22:32:43 +0000 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1OMWdiN009112; Mon, 24 Feb 2014 17:32:39 -0500 Date: Mon, 24 Feb 2014 17:32:39 -0500 (EST) From: Nathan Scott To: Thorsten Alteholz , 739952@bugs.debian.org Message-ID: <2021518144.15260689.1393281159424.JavaMail.zimbra@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: Bug#739952: missing license in debian/copyright Thread-Index: 23CVJiUnHIan3wA/dGYnaLQQUCssLQ== Resent-Sender: Debian BTS X-Barracuda-Connect: buxtehude.debian.org[140.211.166.26] X-Barracuda-Start-Time: 1393281366 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145473 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Thanks Thorsten, ----- Original Message ----- > [...] > please add the missing MIT and BSD licenses of files in > pcp-3.9.0/src/pmwebapi/jsdemos/* These are dual licensed under the already documented GPL license used for the rest of this package, so I reasoned (possibly incorrectly?) this was covered. > (you should also mention the version of LGPL in debian/copyright) *nod* - thanks, I will update this in the next release. -- Nathan From minnus@buffalo.edu Tue Feb 25 15:20:11 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 359A37F50 for ; Tue, 25 Feb 2014 15:20:11 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay3.corp.sgi.com (Postfix) with ESMTP id B2E80AC001 for ; Tue, 25 Feb 2014 13:20:07 -0800 (PST) X-ASG-Debug-ID: 1393363205-04cbb066e63a1a0001-S8gJnT Received: from mtareserve1.acsu.buffalo.edu (mtareserve6.acsu.buffalo.edu [128.205.6.4]) by cuda.sgi.com with ESMTP id 6tfJl8JnzITALDse for ; Tue, 25 Feb 2014 13:20:05 -0800 (PST) X-Barracuda-Envelope-From: minnus@buffalo.edu X-Barracuda-Apparent-Source-IP: 128.205.6.4 Received: from localmailC.acsu.buffalo.edu (localmailc.acsu.buffalo.edu [128.205.5.204]) by mtareserve1.acsu.buffalo.edu (Postfix) with ESMTP id 7CB6610A7; Tue, 25 Feb 2014 16:20:05 -0500 (EST) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 75B1511150; Tue, 25 Feb 2014 16:20:05 -0500 (EST) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailC.acsu.buffalo.edu (Postfix) with ESMTP id B2B4111149; Tue, 25 Feb 2014 16:20:04 -0500 (EST) Received: from smtp.buffalo.edu (smtp3.acsu.buffalo.edu [128.205.5.226]) by localmailC.acsu.buffalo.edu (Prefixe) with ESMTP id A781C11148; Tue, 25 Feb 2014 16:20:04 -0500 (EST) Received: from gilmour.ccr.buffalo.edu (gilmour.ccr.buffalo.edu [128.205.40.13]) (Authenticated sender: minnus@buffalo.edu) by smtp.buffalo.edu (Postfix) with ESMTPSA id 9C0C8965B; Tue, 25 Feb 2014 16:20:04 -0500 (EST) Message-ID: <530D0904.2090804@buffalo.edu> Date: Tue, 25 Feb 2014 16:20:04 -0500 From: Martins Innus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nathan Scott CC: pcp@oss.sgi.com, Ben Myers , Max Matveev Subject: Re: [pcp] nfsclient pmda References: <52F3A564.4060007@buffalo.edu> <1469416634.21700255.1391728771761.JavaMail.root@redhat.com> <742242243.21951337.1391769716120.JavaMail.root@redhat.com> X-ASG-Orig-Subj: Re: [pcp] nfsclient pmda In-Reply-To: <742242243.21951337.1391769716120.JavaMail.root@redhat.com> Content-Type: multipart/mixed; boundary="------------040304000605070005070806" X-PM-EL-Spam-Prob: : 9% X-Barracuda-Connect: mtareserve6.acsu.buffalo.edu[128.205.6.4] X-Barracuda-Start-Time: 1393363205 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145509 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- This is a multi-part message in MIME format. --------------040304000605070005070806 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Nathan, On 2/7/14 5:41 AM, Nathan Scott wrote: > Hi Martins, > > ----- Original Message ----- >> Nathan, >> Yes that would be great to get it in the tree. We are very interested in >> these metrics and would look at getting it up and running. >> > OK, its merged now and disabled from packaging pending your review, > updating, testing & so on. Good luck, and have fun! Thanks. Got it working with the attached patch. For now I just ignore the statvers. Seems to give sane values on a simple nfs setup. > >>> There have been several advances since that post too - the perl API >>> grew support for the pmdaCache routines that Max talks about there. >>> >>> Also, python became an option for PMDAs in the interim - if someone >>> is keen to pick up those review comments and hack on this further, >>> might be worth considering that aspect too (python, too, can use the >>> pmdaCache APIs). An automated test to exercise the logic would be >>> a welcome addition as well (e.g. qa/553 "Exercise the gluster PMDA" >>> would make a good reference there). >>> >>> So, you guide me - would it be helpful in the tree and not packaged >>> as Max suggested? >>> Is there an example perl pmda that uses pmdaCache that I could look at? I probably don't have the time to rewrite in Python right now, but could hack on the existing perl following Max's suggestions as I have time. Thanks Martins --------------040304000605070005070806 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="nfsclient.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nfsclient.patch" LS0tIHBtZGFuZnNjbGllbnQucGwJMjAxNC0wMi0xMyAxODo0Nzo0MC4wMDAwMDAwMDAgLTA1 MDAKKysrIC92YXIvbGliL3BjcC9wbWRhcy9uZnNjbGllbnQvcG1kYW5mc2NsaWVudC5wbAky MDE0LTAyLTI1IDE1OjU0OjQwLjAwMDAwMDAwMCAtMDUwMApAQCAtNTUsNyArNTUsNyBAQAog CQkJbXkgJG10cHQgPSAkMjsKIAogCQkJIyBpcyBpdCBhbiBuZnMgbW91bnQ/Ci0JCQlpZiAo JGxpbmUgPX4gLy4qbmZzIHN0YXR2ZXJzPTFcLjAkLykgeworCQkJaWYgKCRsaW5lID1+IC8u Km5mcyBzdGF0dmVycz0uKi8pIHsKIAkJCQkkaW5zdGFuY2VzeyRpKyt9ID0gJGV4cG9ydDsg IyBhIG5ldyBpbnN0YW5jZQogCQkJCSRoeyRleHBvcnR9ID0ge307ICMge30gaXMgYW4gYW5v bnltb3VzIGhhc2ggcmVmCiAJCQkJJGh7JGV4cG9ydH0tPnsnbmZzY2xpZW50LmV4cG9ydCd9 ID0gJGV4cG9ydDsK --------------040304000605070005070806-- From minnus@buffalo.edu Tue Feb 25 15:28:44 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 368147F50 for ; Tue, 25 Feb 2014 15:28:44 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id E312A304066 for ; Tue, 25 Feb 2014 13:28:40 -0800 (PST) X-ASG-Debug-ID: 1393363715-04bdf05da93a440001-S8gJnT Received: from mtareserve1.acsu.buffalo.edu (mtareserve6.acsu.buffalo.edu [128.205.6.4]) by cuda.sgi.com with ESMTP id cgZQ6AhujLrZsU0W for ; Tue, 25 Feb 2014 13:28:35 -0800 (PST) X-Barracuda-Envelope-From: minnus@buffalo.edu X-Barracuda-Apparent-Source-IP: 128.205.6.4 Received: from localmailC.acsu.buffalo.edu (localmailc.acsu.buffalo.edu [128.205.5.204]) by mtareserve1.acsu.buffalo.edu (Postfix) with ESMTP id 8E56A12C4 for ; Tue, 25 Feb 2014 16:28:35 -0500 (EST) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8ABCC11FDE for ; Tue, 25 Feb 2014 16:28:35 -0500 (EST) Received: from localmailC.acsu.buffalo.edu (localhost [127.0.0.1]) by localmailC.acsu.buffalo.edu (Postfix) with ESMTP id 0629811FD8 for ; Tue, 25 Feb 2014 16:28:35 -0500 (EST) Received: from smtp.buffalo.edu (smtp2.acsu.buffalo.edu [128.205.5.254]) by localmailC.acsu.buffalo.edu (Prefixe) with ESMTP id 015B111FD7 for ; Tue, 25 Feb 2014 16:28:35 -0500 (EST) Received: from gilmour.ccr.buffalo.edu (gilmour.ccr.buffalo.edu [128.205.40.13]) (Authenticated sender: minnus@buffalo.edu) by smtp.buffalo.edu (Postfix) with ESMTPSA id E5DB1919D for ; Tue, 25 Feb 2014 16:28:34 -0500 (EST) Message-ID: <530D0B02.6080208@buffalo.edu> Date: Tue, 25 Feb 2014 16:28:34 -0500 From: Martins Innus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pmlogger_daily question/patch Content-Type: multipart/mixed; boundary="------------080109020002030706060709" X-ASG-Orig-Subj: pmlogger_daily question/patch X-PM-EL-Spam-Prob: : 8% X-Barracuda-Connect: mtareserve6.acsu.buffalo.edu[128.205.6.4] X-Barracuda-Start-Time: 1393363715 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145509 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- This is a multi-part message in MIME format. --------------080109020002030706060709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, We use the attached patch on pmlogger_daily to prevent daily log merging. We do this so we can use rsync throughout the day to backup the logs and not take a big hit syncing the daily log once a day. Is this something that would be acceptable or is there a better way to do it? Thanks Martins --------------080109020002030706060709 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="domerge.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="domerge.patch" --- ./src/pmlogger/pmlogger_daily.sh 2013-12-05 16:39:00.000000000 -0500 +++ /usr/libexec/pcp/bin/pmlogger_daily 2014-01-07 16:37:21.000000000 -0500 @@ -106,6 +106,7 @@ -c control pmlogger control file -k discard remove archives after "discard" days -m addresses send daily NOTICES entries to email addresses + -M do not run pmlogger_merge -N show-me mode, no operations performed -o (old style) merge logs only from yesterday [default is to merge all possible logs before today] @@ -131,8 +132,9 @@ OFLAG=false TRACE=0 RFLAG=false +DOMERGE=true -while getopts c:k:m:Nors:t:Vx:X:Y:? c +while getopts c:k:m:MNors:t:Vx:X:Y:? c do case $c in @@ -152,6 +154,8 @@ N) SHOWME=true MYARGS="$MYARGS -N" ;; + M) DOMERGE=false + ;; o) OFLAG=true ;; r) RFLAG=true @@ -704,7 +708,7 @@ fi fi rm -f $tmp/skip - if [ ! -s $tmp/list ] + if [ ! -s $tmp/list -o $DOMERGE == 'false' ] then if $VERBOSE then --------------080109020002030706060709-- From nscott@redhat.com Tue Feb 25 15:39:16 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 061317F50 for ; Tue, 25 Feb 2014 15:39:16 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id D75BA8F8071 for ; Tue, 25 Feb 2014 13:39:15 -0800 (PST) X-ASG-Debug-ID: 1393364353-04cb6c567637960001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id GxlASsQL3ArWi8Q1; Tue, 25 Feb 2014 13:39:14 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1PLd6iW020409; Tue, 25 Feb 2014 16:39:06 -0500 Date: Tue, 25 Feb 2014 16:39:06 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Martins Innus Cc: pcp@oss.sgi.com, Ben Myers , Max Matveev Message-ID: <1661706871.16390260.1393364346293.JavaMail.zimbra@redhat.com> In-Reply-To: <530D0904.2090804@buffalo.edu> References: <52F3A564.4060007@buffalo.edu> <1469416634.21700255.1391728771761.JavaMail.root@redhat.com> <742242243.21951337.1391769716120.JavaMail.root@redhat.com> <530D0904.2090804@buffalo.edu> Subject: Re: [pcp] nfsclient pmda MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] nfsclient pmda Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: nfsclient pmda Thread-Index: UZYyLrqiy9RdpOuAmLljI/bjblmm5A== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1393364354 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145509 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > On 2/7/14 5:41 AM, Nathan Scott wrote: > > ----- Original Message ----- > >> Yes that would be great to get it in the tree. We are very interested > >> in these metrics and would look at getting it up and running. > >> > > OK, its merged now and disabled from packaging pending your review, > > updating, testing & so on. Good luck, and have fun! > > Thanks. Got it working with the attached patch. For now I just ignore > the statvers. Seems to give sane values on a simple nfs setup. Good stuff! > Is there an example perl pmda that uses pmdaCache that I could look at? > I probably don't have the time to rewrite in Python right now, but could > hack on the existing perl following Max's suggestions as I have time. Have a look at the src/pmdas/simple/pmdasimple.perl code - this PMDA has both styles. The $color_indom uses the array style and $now_indom uses a hash (under the covers, in PCP::PMDA, the latter translates to pmdaCache use). cheers. -- Nathan From kenj@internode.on.net Tue Feb 25 16:16:40 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 7E88E7F50 for ; Tue, 25 Feb 2014 16:16:40 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 538BB8F806F for ; Tue, 25 Feb 2014 14:16:37 -0800 (PST) X-ASG-Debug-ID: 1393366595-04cbb066e63be40001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id E2s4LDYyz6QiiLRP for ; Tue, 25 Feb 2014 14:16:35 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArJ3AKYVDVN5LAvqPGdsb2JhbABZDoJ4iE+kPZVCAwKBGRcDAQEBATg1giUBAQUIAh4SHC8BAwIGAw4DBAEBKAcZIAoDCQgCBAESCwWHdMhKF41lcgaEMgSPLZNbikRTKA Received: from ppp121-44-11-234.lns20.syd6.internode.on.net (HELO bozohorize) ([121.44.11.234]) by ipmail06.adl6.internode.on.net with ESMTP; 26 Feb 2014 08:46:34 +1030 From: "Ken McDonell" To: "'Martins Innus'" , References: <530D0B02.6080208@buffalo.edu> In-Reply-To: <530D0B02.6080208@buffalo.edu> Subject: RE: [pcp] pmlogger_daily question/patch Date: Wed, 26 Feb 2014 09:16:31 +1100 X-ASG-Orig-Subj: RE: [pcp] pmlogger_daily question/patch Message-ID: <005a01cf3277$3eb3c6e0$bc1b54a0$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQKWiLbGaqQW2arXnQaT5p/igw4+rJk325jQ Content-Language: en-au X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1393366595 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145510 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== Don't think there is a better way, Martins. The requirement has not been raised before (which is why the merge is unconditional), but your use case seems entirely reasonable. I'll take ownership of moving this into the source tree, unless Nathan jumps in ... 8^)> The only (!) issues will be fallout on the other pmlogger_daily tasks when the unmerged archives appear in the archive directories (there is a bunch of pattern matching that goes on here in the selection of files to cull and optionally compress (not a requirement in your case, I expect)) and a man page update and QA coverage and fallout ... so the patch solves the easy 25% .... Thanks. > -----Original Message----- > From: pcp-bounces@oss.sgi.com [mailto:pcp-bounces@oss.sgi.com] On > Behalf Of Martins Innus > Sent: Wednesday, 26 February 2014 8:29 AM > To: pcp@oss.sgi.com > Subject: [pcp] pmlogger_daily question/patch > > Hi, > > We use the attached patch on pmlogger_daily to prevent daily log > merging. We do this so we can use rsync throughout the day to backup the > logs and not take a big hit syncing the daily log once a day. Is this something > that would be acceptable or is there a better way to do it? > > Thanks > > Martins From nscott@redhat.com Tue Feb 25 16:21:31 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 348C97F50 for ; Tue, 25 Feb 2014 16:21:31 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 0B21A304071 for ; Tue, 25 Feb 2014 14:21:27 -0800 (PST) X-ASG-Debug-ID: 1393366886-04bdf05dab3bea0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 9XJTiEAUhkVR11LL for ; Tue, 25 Feb 2014 14:21:26 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1PMLLoU030239; Tue, 25 Feb 2014 17:21:21 -0500 Date: Tue, 25 Feb 2014 17:21:21 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: Martins Innus , pcp@oss.sgi.com Message-ID: <1141601882.16423571.1393366881909.JavaMail.zimbra@redhat.com> In-Reply-To: <005a01cf3277$3eb3c6e0$bc1b54a0$@internode.on.net> References: <530D0B02.6080208@buffalo.edu> <005a01cf3277$3eb3c6e0$bc1b54a0$@internode.on.net> Subject: Re: [pcp] pmlogger_daily question/patch MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pmlogger_daily question/patch Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pmlogger_daily question/patch Thread-Index: AQKWiLbGaqQW2arXnQaT5p/igw4+rJk325jQZmFasa8= X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1393366886 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145511 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > Don't think there is a better way, Martins. The requirement has not been > raised before (which is why the merge is unconditional), but your use case > seems entirely reasonable. > > I'll take ownership of moving this into the source tree, [...] Heh, I was hoping you'd say that :) -- thanks!!! > The only (!) issues will be fallout on the other pmlogger_daily tasks when > the unmerged archives appear in the archive directories (there is a bunch of > pattern matching that goes on here in the selection of files to cull and > optionally compress (not a requirement in your case, I expect)) and a man > page update and QA coverage and fallout ... so the patch solves the easy 25% > .... *nod* cheers. -- Nathan From kenj@internode.on.net Tue Feb 25 16:30:16 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 07E507F50 for ; Tue, 25 Feb 2014 16:30:16 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id E09278F8035 for ; Tue, 25 Feb 2014 14:30:15 -0800 (PST) X-ASG-Debug-ID: 1393367413-04cb6c567539380001-S8gJnT Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id 8yvnG4bKJ7k0hCbN for ; Tue, 25 Feb 2014 14:30:14 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar1MAAEZDVN5LAvqPGdsb2JhbABZgwY7g1qEOqQTlUeBGRcDAQEBATg1giUBAQUIAhkFLiMMAQMCBgMVAQQCIwMCAhkgCgMRAgQTCwWHdKc5oQ8XgSmNJweCb4FJBI8tijuUNyg Received: from ppp121-44-11-234.lns20.syd6.internode.on.net (HELO bozohorize) ([121.44.11.234]) by ipmail06.adl6.internode.on.net with ESMTP; 26 Feb 2014 08:59:48 +1030 From: "Ken McDonell" To: "'Nathan Scott'" Cc: "'PCP Mailing List'" References: <530B0279.6080607@internode.on.net> <840678160.15162819.1393275914420.JavaMail.zimbra@redhat.com> <530BC149.7060600@internode.on.net> <1207513118.15254816.1393280851768.JavaMail.zimbra@redhat.com> In-Reply-To: <1207513118.15254816.1393280851768.JavaMail.zimbra@redhat.com> Subject: RE: [pcp] assorted build errors Date: Wed, 26 Feb 2014 09:29:47 +1100 X-ASG-Orig-Subj: RE: [pcp] assorted build errors Message-ID: <009301cf3279$17f5cc90$47e165b0$@internode.on.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEA6RygRp6pDVYdAsatEtxYyQqoXgITlXR0AXBfORQCZpAGd5wzyuKg Content-Language: en-au X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1393367413 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, THREAD_INDEX X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145511 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header > -----Original Message----- > From: Nathan Scott [mailto:nathans@redhat.com] > Sent: Tuesday, 25 February 2014 9:28 AM > ... > Hmmm. May still be a related issue - configure.in checks for: > AC_MSG_CHECKING([for libmicrohttpd > 0.9.9]) ... and switches parts of = the > build off if that's not found. > Is there a more recent libmicrohttpd available on that platform? Thanks for the patch. But based on inspection (not actually trying the = patch!), this does not appear to be a debian packaging (dependency) = problem, but I have the same issue on 4 or 5 (can't remember) QA hosts = now, so I'm going to have to figure out what the root cause is. For at least one of the QA machines, there is no more recent = libmicrohttpd package available from the standard distro repository, so = I think we need a fix for the unmunged installation case. From nscott@redhat.com Tue Feb 25 23:01:52 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id C19A57F37 for ; Tue, 25 Feb 2014 23:01:52 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 9A29D304077 for ; Tue, 25 Feb 2014 21:01:49 -0800 (PST) X-ASG-Debug-ID: 1393390904-04cbb066e648fb0001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 5tQMcfv0Z9UF6JvQ for ; Tue, 25 Feb 2014 21:01:45 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1Q51eIn032695 for ; Wed, 26 Feb 2014 00:01:40 -0500 Date: Wed, 26 Feb 2014 00:01:40 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp@oss.sgi.com Message-ID: <148968975.16610428.1393390900542.JavaMail.zimbra@redhat.com> In-Reply-To: <243011492.16610353.1393390888751.JavaMail.zimbra@redhat.com> Subject: pcp updates: qa, fche merge MIME-Version: 1.0 X-ASG-Orig-Subj: pcp updates: qa, fche merge Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates: qa, fche merge Thread-Index: qQDq74KKBASvSQiU3lFOvIvXv6TPxQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1393390904 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145520 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/pcp/pcp.git dev man/man1/pmlogger.1 | 11 +++++++++-- man/man1/pmmgr.1 | 3 ++- qa/749 | 15 +++++++++++++-- src/pmlogger/pmnewlog.sh | 8 ++++---- src/pmlogger/src/pmlogger.c | 22 +++++++++++++++------- src/pmmgr/TODO | 3 ++- src/pmmgr/pmmgr.cxx | 36 ++++++++++++++++++++++++++++++------ src/pmmgr/pmmgr.h | 1 + 8 files changed, 76 insertions(+), 23 deletions(-) commit c3ef04e0207470b615f1891395e0f643b78d8480 Author: Nathan Scott Date: Wed Feb 26 15:59:00 2014 +1100 Fix pmnewlog getopts string after pmlogger -y/-z switch commit 2f6780aded0d348adf5b055e94d04b33e5a9eecd Author: Frank Ch. Eigler Date: Wed Feb 26 15:52:49 2014 +1100 pmmgr: avoid super-quick daemon failure-retry loops The '-p N' parameter is also interpreted to limit the rate of retries for any particular daemon's preparation / startup. Without a limit, pmmgr's rapid response to signals / failure has led to tight failure/retry loops, resulting in huge log files and no merriment. commit cfe5ccb345a6a0f43e4b1a0d6d3ea4845b24ab85 Author: Frank Ch. Eigler Date: Fri Feb 21 10:19:51 2014 -0500 pmmgr signal handling: setpgrp Shutting down an entire pmmgr family of processes is tricky, because we use process-group-based signalling to forward SIGTERM to everything we started. But in some cases, pmmgr may not be in a process group of its own, such as if it is started by init scripts, instead of by hand from a shell running on a pty. To make both situations similar, we now run a setpgrp() near initialization, to be sure that pmmgr's own pid can be used (negatively) as a process-group. pmlogger has had a hardcoded conflicting setpgrp inside it, for its normal use as a daemon. However, when invoked by hand, or via pmmgr, it now considers itself in the "foreground", and does not setpgrp away from the inherited one. commit a91aa864dfa81f6904b9249cd567ad94e7ff0043 Author: Frank Ch. Eigler Date: Wed Feb 19 17:21:02 2014 -0500 pmlogger: -z -> -y Nathan noticed that PCPintro(1)'s general reference to -z is the opposite polarity ("use remote time zone") to pmlogger's new -z ("use local time zone"). So why not rename pmlogger's to -y. commit d045bcd12cd738e368271e56a78998cbf66afd5e Author: Frank Ch. Eigler Date: Wed Feb 19 16:23:13 2014 -0500 pmlogger: add -z option for host-local timezone support It is difficult for a pmlogger user to specify an absolute time at which she'd like the process to shut down. That's because the pmlogger -T option is interpreted with the remote PMCD's time zone in mind, which could be an a-priori unknown. This patch adds a -z option, which lets pmlogger interpret -T / etc. in the originating local time zone instead. pmmgr's pmlogmerge-granular mode is updated to use this. commit 9681ff309d09de29fd92942f89b4405164b4d3f2 Author: Nathan Scott Date: Tue Feb 25 10:51:48 2014 +1100 Fix qa/749 when systemtap userspace probes are unavailable Tweak test 749 using Franks suggestion of verifying up to and including the compilation phase (-p4) before going ahead with the complete test. This is to catch missing userspace probe support on some platforms (s390x tripped this in the Red Hat QE environment). From nscott@redhat.com Thu Feb 27 00:15:22 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 723187F3F for ; Thu, 27 Feb 2014 00:15:22 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id 2CEC2304081 for ; Wed, 26 Feb 2014 22:15:18 -0800 (PST) X-ASG-Debug-ID: 1393481716-04bdf05dab8cd30001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id kAwtEuIdwAq0Q7it for ; Wed, 26 Feb 2014 22:15:16 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1R6FG1U012309; Thu, 27 Feb 2014 01:15:16 -0500 Date: Thu, 27 Feb 2014 01:15:15 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Dave Brolley Cc: pcp@oss.sgi.com Message-ID: <1734063835.17483667.1393481715436.JavaMail.zimbra@redhat.com> In-Reply-To: <53075D46.6090807@redhat.com> References: <53075D46.6090807@redhat.com> Subject: Re: [pcp] PCP Updates: pmlogger AF_UNIX socket for normal users; qa version check bump MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] PCP Updates: pmlogger AF_UNIX socket for normal users; qa version check bump Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: PCP Updates: pmlogger AF_UNIX socket for normal users; qa version check bump Thread-Index: vYS8Ui+JvP4tm1cZbMTqyY/SIlOb9g== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1393481716 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145559 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain Hi Dave, Here's that code review... > diff --git a/src/libpcp/src/exports b/src/libpcp/src/exports > index 9b17688..36675b8 100644 > --- a/src/libpcp/src/exports > +++ b/src/libpcp/src/exports > @@ -228,6 +228,8 @@ PCP_3.0 { > __pmLogChkLabel; > __pmLogClose; > __pmLogCreate; > + __pmLogLocalSocketDefault; > + __pmLogLocalSocketUser; > __pmLogFetch; > __pmLogFetchInterp; > __pmLogFindLocalPorts; > @@ -259,6 +261,7 @@ PCP_3.0 { > __pmMapErrno; > __pmMemoryMap; > __pmMemoryUnmap; > + __pmMkdir; > __pmMktime; > __pmMultiThreaded; > __pmNativeConfig; Hmm, we can't just stick these slap bang in the middle here - needs a PCP_3.2 exports section, which inherits from PCP_3.1 now, doesn't it? Stan's time API work will piggyback on this new section, as will the common getopts goo I hope. > diff --git a/src/include/pcp/impl.h b/src/include/pcp/impl.h > index df78f1d..988de0f 100644 > --- a/src/include/pcp/impl.h > +++ b/src/include/pcp/impl.h > @@ -1262,6 +1265,7 @@ extern void __pmConfig(__pmConfigCallback); > extern char *__pmNativePath(char *); > extern int __pmAbsolutePath(char *); > extern int __pmPathSeparator(void); > +extern int __pmMkdir(const char *, mode_t); BTW, looks like pmpost.c could make use of this, removing the mkdir_r (equivalent code) there. Also, see below re naming. > diff --git a/src/libpcp/src/accounts.c b/src/libpcp/src/accounts.c > index 89b967d..8c2eb7b 100644 > --- a/src/libpcp/src/accounts.c > +++ b/src/libpcp/src/accounts.c > > + result = getpwuid(uid); > + snprintf(buf, size, "%s", result ? result->pw_dir : "unknown"); Putting "unknown" as the homedir path seems dodgey - looks like we need some error handling here (return NULL, deal with it in the callers). > diff --git a/src/libpcp/src/logconnect.c b/src/libpcp/src/logconnect.c > index 547eb9a..4e282ca 100644 > --- a/src/libpcp/src/logconnect.c > +++ b/src/libpcp/src/logconnect.c > @@ -62,11 +62,185 @@ __pmLoggerTimeout(void) > } > > /* > - * expect one of pid or port to be 0 ... if port is 0, use > - * hostname+pid to find port, assuming pmcd is running there > + * Return the path to the default PMLOGGER local unix domain socket. > + * Returns a pointer to a static buffer which can be used directly. > + * Return the path regardless of whether unix domain sockets are > + * supported by our build. Other functions can then print reasonable > + * messages if an attempt is made to use one. > + */ > +const char * > +__pmLogLocalSocketDefault(int pid) > +{ > + static char pmlogger_socket[MAXPATHLEN]; > + static char pmlogger_socket_primary[MAXPATHLEN]; Do these need to be here, static? Seems a buffer (and size) could be passed in. Also, not really following why we need both buffers separately. A comment would help, but can they be pushed out to the caller(s) instead. > +/* > + * Common function for attemmpting connections to pmlogger. > + */ > +static int > +connectLogger (int fd, __pmSockAddr *myAddr) whitespace oddity. > + /* Attept the connection. */ typo. > + sts = 0; dead code? (above line, cos...) > + if ((rc = __pmSelectRead(fd+1, &rfds, pstv)) == 1) { > + sts = __pmConnectCheckError(fd); > + } > + else if (rc == 0) { > + sts = ETIMEDOUT; > + } > + else { > + sts = (rc < 0) ? neterror() : EINVAL; > + } > + } > + * Attemmpt connection to pmlogger via a local socket. typo. > +static int > +connectLoggerLocal(const char *local_socket) > +{ > +#if defined(HAVE_STRUCT_SOCKADDR_UN) > + char socket_path[MAXPATHLEN]; > + int fd; > + int sts; > + __pmSockAddr *myAddr; > + > + /* Create a socket */ > + fd = __pmCreateUnixSocket(); > + if (fd < 0) > + return -ECONNREFUSED; > + > + /* Set up the socket address. */ > + myAddr = __pmSockAddrAlloc(); > + if (myAddr == NULL) { > + __pmNotifyErr(LOG_ERR, "__pmConnectLogger: out of memory\n"); > + return -ENOMEM; fd is leaked here. > + /* Attempt to connect */ > + sts = connectLogger(fd, myAddr); > + __pmSockAddrFree(myAddr); > + > + if (sts < 0) > + fd = sts; and there. > +__pmConnectLogger(const char *connectionSpec, int *pid, int *port) > + [...] > + if (fd < 0) { > + if (prefix_len == 5) /* "unix: */ double-quote oddity. > + if (*pid == PM_LOG_ALL_PIDS) { > #ifdef PCP_DEBUG > if (pmDebug & DBG_TRACE_CONTEXT) > - fprintf(stderr, "__pmConnectLogger: __pmLogFindPort -> 1, cannot contact pmcd\n"); pmcd? pmlogger. > #ifdef PCP_DEBUG > - if (pmDebug & DBG_TRACE_CONTEXT) > - fprintf(stderr, "__pmConnectLogger: gethostbyname: %s\n", > - hoststrerror()); > + if (pmDebug & DBG_TRACE_CONTEXT) > + fprintf(stderr, "__pmConnectLogger: __pmLogFindPort -> 1, cannot contact pmcd\n"); ditto. > diff --git a/src/libpcp/src/logportmap.c b/src/libpcp/src/logportmap.c > index 22b1798..1cf463b 100644 > --- a/src/libpcp/src/logportmap.c > +++ b/src/libpcp/src/logportmap.c > @@ -365,6 +358,7 @@ int > __pmLogFindPort(const char *host, int pid, __pmLogPort **lpp) > { > int ctx, oldctx; > + char *ctxhost; > int sts, numval; > int i, j; > int findone = pid != PM_LOG_ALL_PIDS; > @@ -386,9 +380,21 @@ __pmLogFindPort(const char *host, int pid, __pmLogPort **lpp) > return localcon; > > /* note: there may not be a current context */ > + ctx = 0; > oldctx = pmWhichContext(); > > - if ((ctx = pmNewContext(PM_CONTEXT_HOST, host)) < 0) > + /* > + * Enclose ctxhost in [] in case it is an ipv6 address. This prevents > + * the first colon from being taken as a port separator by pmNewContext > + * and does no harm otherwise. > + */ > + ctxhost = malloc(strlen(host) + 2 + 1); > + if (ctxhost == NULL) { > + sts = -ENOMEM; > + goto ctxErr; > + } > + sprintf(ctxhost, "[%s]", host); > + if ((ctx = pmNewContext(PM_CONTEXT_HOST, ctxhost)) < 0) > return ctx; Leaks ctxhost here. > if ((sts = pmLookupName(1, namelist, &pmid)) < 0) > goto ctxErr; ... there ... > @@ -434,6 +440,7 @@ resErr: > ctxErr: > if (oldctx >= 0) > pmUseContext(oldctx); > - pmDestroyContext(ctx); > + if (ctx >= 0) > + pmDestroyContext(ctx); > return sts; > } ... and everywhere. Should ctxhost be an on-stack buffer instead? > diff --git a/src/libpcp/src/secureconnect.c b/src/libpcp/src/secureconnect.c > index 396727e..b44851c 100644 > --- a/src/libpcp/src/secureconnect.c > +++ b/src/libpcp/src/secureconnect.c > @@ -383,7 +358,7 @@ __pmInitCertificates(void) > * not using secure connections (initially everyone) don't > * have to diagnose / put up with spurious errors. > */ > - if (mkpath(dbpath(nssdb, sizeof(nssdb), "sql:"), 0700) < 0) > + if (__pmMkdir(dbpath(nssdb, sizeof(nssdb), "sql:"), 0700) < 0) Hmm, actually, mkpath was quite a descriptive name ... could we go with __pmMakePath for this new interface instead? > + if (address->sockaddr.raw.family == PR_AF_INET || > + address->sockaddr.raw.family == PR_AF_INET6) { > + prStatus = PR_GetHostByAddr(&address->sockaddr, &buffer[0], sizeof(buffer), &he); > #ifdef PCP_DEBUG > - if (pmDebug & DBG_TRACE_DESPERATE) { > - if (prStatus != PR_SUCCESS) { > - fprintf(stderr, "%s:PR_GetHostByAddr(%s) returns %d (%s)\n", __FILE__, __pmSockAddrToString(address), PR_GetError(), PR_ErrorToString(PR_GetError(), PR_LANGUAGE_I_DEFAULT)); > - } > - } > + if (pmDebug & DBG_TRACE_DESPERATE) { > + if (prStatus != PR_SUCCESS) { > + fprintf(stderr, "%s:PR_GetHostByAddr(%s) returns %d (%s)\n", __FILE__, __pmSockAddrToString(address), PR_GetError(), PR_ErrorToString(PR_GetError(), PR_LANGUAGE_I_DEFAULT)); > + } > + } > #endif > + } > + else if (address->sockaddr.raw.family == PR_AF_LOCAL) > + return strdup(address->sockaddr.local.path); > + else { > + __pmNotifyErr(LOG_ERR, > + "%s:__pmGetNameInfo: Invalid address family: %d\n", __FILE__, > + address->sockaddr.raw.family); > + return NULL; > + } > + > name = (prStatus == PR_SUCCESS ? strdup(he.h_name) : NULL); > return name; This code looks slightly wierd to me now, because we conditionally setup "he" early on, then we have a chunk of code that operates in a completely different way (PR_AF_LOCAL), and then we come back to "he" at the end. It would read/flow a little better if we did the af_unix family first, and then the inet/ipv6 - or, perhaps moving the strdup(he.h_name) & prStatus test inside the inet/ipv6 branch would do the trick (could do the Notify without an "else" then). > diff --git a/src/libpcp/src/util.c b/src/libpcp/src/util.c > index e92d22b..5d575b1 100644 > --- a/src/libpcp/src/util.c > +++ b/src/libpcp/src/util.c > @@ -1475,6 +1475,34 @@ dirname(char *name) > } > #endif /* HAVE_DIRNAME */ > > +/* > + * Create a directory, including all of its path components. > + */ > +int > +__pmMkdir(const char *dir, mode_t mode) __pmMakePath ... just rolls off the tongue, doesn't it? ;) > diff --git a/src/pmlc/actions.c b/src/pmlc/actions.c > index 45c60d2..77088eb 100644 > --- a/src/pmlc/actions.c > +++ b/src/pmlc/actions.c > @@ -91,12 +92,17 @@ ConnectPMCD(void) > * if pmcd host is "localhost"-alike then use hostname that > * was used to contact pmlogger, as from here (where pmlc is > * running) "localhost" is likely to connect us to the wrong > - * pmcd or no pmcd at all > + * pmcd or no pmcd at all. What's the "point"? Ahahahah, I crack myself up sometimes. > */ > srchost = strdup(lasthost); > } > else > srchost = strdup(lsp->ls_fqdn); > + > + if (srchost == NULL) { > + sts = -ENOMEM; > + goto done; > + } Looks like error reporting is being done within the above routine? (i.e. do we need a fprintf here, like the other error cases?) > diff --git a/src/pmlogconf/pmlogconf.sh b/src/pmlogconf/pmlogconf.sh > index db98da8..7e10e5d 100755 > --- a/src/pmlogconf/pmlogconf.sh > +++ b/src/pmlogconf/pmlogconf.sh > @@ -11,6 +11,7 @@ > # when the group was added to the configuration file > # delta delta argument for pmlogger "logging ... on delta" clause > # > +# Copyright (c) 2014 Red Hat. > # Copyright (c) 1998,2003 Silicon Graphics, Inc. All Rights Reserved. > # > # This program is free software; you can redistribute it and/or modify it > @@ -485,8 +486,9 @@ End-of-File > # > > [access] > -disallow * : all; > -allow localhost : enquire; > +disallow .* : all; > +disallow :* : all; > +allow local:* : enquire; > End-of-File Hmmm. When I run QA on this code, after an upgrade (so, without the above change), test 023 hangs. I wonder if the above change is being assumed to be in place...? > diff --git a/src/pmlogger/src/ports.c b/src/pmlogger/src/ports.c > index 1f867cd..b3320ee 100644 > --- a/src/pmlogger/src/ports.c > +++ b/src/pmlogger/src/ports.c > [...] > +GetPorts(char *file) > [...] > + /* Now listen on the new socket. */ > + if (sts >= 0) { > + sts = __pmListen(fd, 5); /* Max. of 5 pending connection requests */ > + if (sts == -1) { > + fprintf(stderr, "__pmListen: %s\n", netstrerror()); Do we leak fd here? > + } > + else { > + ctlfds[ctlix] = fd; > + ++socketsCreated; > + } > } (back to top of loop) ... why yes, yes we do. > + return; > } That final return is redundant. > - free(hostName); > } > + if (hostName != NULL) > + free(hostName); Good catch! cheers. -- Nathan From kenj@internode.on.net Thu Feb 27 02:11:35 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 49D157F3F for ; Thu, 27 Feb 2014 02:11:35 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id BAF73AC003 for ; Thu, 27 Feb 2014 00:11:31 -0800 (PST) X-ASG-Debug-ID: 1393488688-04cb6c56778d130001-S8gJnT Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by cuda.sgi.com with ESMTP id cCS8Swm0B2avgKm0 for ; Thu, 27 Feb 2014 00:11:29 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.129 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIYACHyDlN20adJPGdsb2JhbAANTYNBiBS6dgMBAQEBOINZMA0WGAMCAQIBMScGAgEBsByhfxeOcYQhBJlqlDg Received: from ppp118-209-167-73.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.167.73]) by ipmail06.adl2.internode.on.net with ESMTP; 27 Feb 2014 18:41:28 +1030 Message-ID: <530EF335.4080002@internode.on.net> Date: Thu, 27 Feb 2014 19:11:33 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pcp updates - debian packaging Content-Type: text/plain; charset=ISO-8859-1 X-ASG-Orig-Subj: pcp updates - debian packaging Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail06.adl2.internode.on.net[150.101.137.129] X-Barracuda-Start-Time: 1393488688 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145562 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Deal with the pcp-webapi dependency on a minimum revision of libmicrohttpd-dev. Provides a way of including optional packages for Debian-like builds. Changes committed to git://oss.sgi.com/kenj/pcp.git dev configure | 13 + configure.in | 15 + debian/.gitignore | 1 debian/GNUmakefile | 15 + debian/control | 378 ------------------------------------------------- debian/control.master | 369 +++++++++++++++++++++++++++++++++++++++++++++++ debian/control.webapi | 8 + debian/pcp-webapi.dirs | 4 8 files changed, 420 insertions(+), 383 deletions(-) commit aa326cf2074a56483cf09c94139b3cf477dcdaeb Author: Ken McDonell Date: Thu Feb 27 19:06:48 2014 +1100 add debian/control to .gitignore commit 9c970916176e19e714c93bd45f428dd04995295e Author: Ken McDonell Date: Thu Feb 27 09:22:21 2014 +1100 debian packaging - changes for optional packages Recent problems packaging pcp-webapi have highlighted the fact that our Debian packaging does not have a way to include optional packages based on what pieces we're able to build. Splitting debian/control to debian/control.master (the non-optional packages) and debian/control.foo files for each optional pcp-foo package, then adding configure, build and makefile glue to make this all work. Note debian/control needs to exist _very_ early in the Debian packaging workflow, so debian/control is remade at the end of the configure script. commit fe9e3170eda4d45906999d916b4117a300a01d0f Author: Ken McDonell Date: Thu Feb 27 08:24:33 2014 +1100 debian packaging - minor dirs control issue pcp-webapi.dirs contained the wrong directory list ... seems to have been copied from pcp-manager.dirs .. fix to match pcp-webapi package. From wwwrun@oss.sgi.com Thu Feb 27 09:50:12 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE,NO_RELAYS autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: by oss.sgi.com (Postfix, from userid 30) id 5EB0D29DF8; Thu, 27 Feb 2014 09:50:12 -0600 (CST) From: bugzilla-daemon@oss.sgi.com To: pcp@oss.sgi.com Subject: [Bug 1044] pmchart very slow when Overview-panning archive file with lots of records Date: Thu, 27 Feb 2014 15:50:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Classification: Unclassified X-Bugzilla-Product: pcp X-Bugzilla-Component: pcp X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: fche@redhat.com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P5 X-Bugzilla-Assigned-To: fche@redhat.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: multipart/alternative; boundary="1393516212.bbDE641.12446"; charset="us-ascii" X-Bugzilla-URL: http://oss.sgi.com/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 --1393516212.bbDE641.12446 Date: Thu, 27 Feb 2014 09:50:12 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" http://oss.sgi.com/bugzilla/show_bug.cgi?id=1044 --- Comment #6 from Frank Ch. Eigler --- A related problem may exist in pmlogrewrite: siccing it on the larger pmlogextract-merged archives that pmmgr can produce can result in hours of cpu used. -- You are receiving this mail because: You are on the CC list for the bug. --1393516212.bbDE641.12446 Date: Thu, 27 Feb 2014 09:50:12 -0600 MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8"

Comment # 6 on bug 1044 from 
A related problem may exist in pmlogrewrite: siccing it on
the larger pmlogextract-merged archives that pmmgr can produce
can result in hours of cpu used.

You are receiving this mail because:
  • You are on the CC list for the bug.
--1393516212.bbDE641.12446-- From kenj@internode.on.net Thu Feb 27 14:09:31 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 53BC17F3F for ; Thu, 27 Feb 2014 14:09:31 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id F3521AC006 for ; Thu, 27 Feb 2014 12:09:27 -0800 (PST) X-ASG-Debug-ID: 1393531760-04bdf05da9d02c0001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id 6bt6DMDi3CRyf41R for ; Thu, 27 Feb 2014 12:09:21 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBABebD1N20adJ/2dsb2JhbAANTYNBwVuBPYQYMA0WGAMCAQIBWAYCAQGxOaFsF41xgQGEIQSuI4FU Received: from ppp118-209-167-73.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.167.73]) by ipmail07.adl2.internode.on.net with ESMTP; 28 Feb 2014 06:39:13 +1030 Message-ID: <530F9B64.4080505@internode.on.net> Date: Fri, 28 Feb 2014 07:09:08 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: pcp@oss.sgi.com Subject: pcp updates - last piece of debian packaging changes for this round Content-Type: text/plain; charset=ISO-8859-1 X-ASG-Orig-Subj: pcp updates - last piece of debian packaging changes for this round Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1393531760 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145579 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Changes committed to git://oss.sgi.com/kenj/pcp.git dev debian/control.master | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) commit 847526c31d7d4b5e255831cbdd73fd411c6e30c7 Author: Ken McDonell Date: Fri Feb 28 06:46:48 2014 +1100 debian build - remove Build-Depends for libmicrohttpd-dev We handle this in the configure and packaging now ... if the right libmicrohttpd-dev is installed we build the pcp-webapi package, otherwise it is neither built nor packaged. From nscott@redhat.com Thu Feb 27 15:39:17 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 37A417F4E for ; Thu, 27 Feb 2014 15:39:17 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id B7B9FAC006 for ; Thu, 27 Feb 2014 13:39:16 -0800 (PST) X-ASG-Debug-ID: 1393537155-04bdf05dabd7a90001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id maU3rqsFFDGBmVOV for ; Thu, 27 Feb 2014 13:39:15 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1RLdCST007411; Thu, 27 Feb 2014 16:39:12 -0500 Date: Thu, 27 Feb 2014 16:39:12 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: pcp@oss.sgi.com Message-ID: <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> In-Reply-To: <530F9B64.4080505@internode.on.net> References: <530F9B64.4080505@internode.on.net> Subject: Re: [pcp] pcp updates - last piece of debian packaging changes for this round MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pcp updates - last piece of debian packaging changes for this round Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates - last piece of debian packaging changes for this round Thread-Index: ZuQgLRX0QULFAuYHd7CY1ridfBx5uQ== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1393537155 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145581 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Hi Ken, This part does not look like a valid solution - the "official" buildd builds use the build dependencies to populate the build root, so we have a chicken-and-egg situation here. In the end this would result in this code no longer being built even when it should be (in Debian release builds, not our local builds). ----- Original Message ----- > [...] > debian build - remove Build-Depends for libmicrohttpd-dev > > We handle this in the configure and packaging now ... if the right > libmicrohttpd-dev is installed we build the pcp-webapi package, otherwise > it is neither built nor packaged. Are these distros without microhttpd really current? If even RHEL5 has it (which it does) I'm amazed that there are current Debian variants that do not ... ? Can this problem be solved by using more recent versions of these distros? cheers. -- Nathan From kenj@internode.on.net Thu Feb 27 17:40:31 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id C45AE7F3F for ; Thu, 27 Feb 2014 17:40:31 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id A90A330406B for ; Thu, 27 Feb 2014 15:40:31 -0800 (PST) X-ASG-Debug-ID: 1393544425-04cb6c5676d8470001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id NWxyxsRs3pAcBp6r for ; Thu, 27 Feb 2014 15:40:26 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAZAGDMD1N20adJPGdsb2JhbAANTYNBiBS7AQMBAQEBOINZPRYYAwIBAgExGg0IAQGxT6F7jFqGOQSuIw Received: from ppp118-209-167-73.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.167.73]) by ipmail04.adl6.internode.on.net with ESMTP; 28 Feb 2014 10:10:23 +1030 Message-ID: <530FCCED.4000403@internode.on.net> Date: Fri, 28 Feb 2014 10:40:29 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: PCP Mailing List Subject: Another build problem - python bits on Linux Mint 12 Content-Type: text/plain; charset=ISO-8859-1 X-ASG-Orig-Subj: Another build problem - python bits on Linux Mint 12 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1393544426 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145583 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Platform - Linux Mint 12 Lisa PCP used to build just fine. With latest PCP source, build fails == dpkg-buildpackage: build == dpkg-buildpackage: binary-arch warning: install_lib: 'build/lib.linux-x86_64-2.6' does not exist -- no Python modules to install touch: cannot touch `/home/kenj/src/pcp/build/deb/pcp-3.9.1/debian/python-pcp/usr/lib/python2.6/dist-packages/pcp/mmv.py': No such file or directory ... and lots more like this Artifacts are being placed in the python2.7 tree ... $ pwd /home/kenj/src/pcp/build/deb/pcp-3.9.1/debian/python-pcp/usr/lib $ find . -name mmv.py ./python2.7/dist-packages/pcp/mmv.py On this platform, python-all-dev pulls in BOTH python 2.6 and 2.7 $ dpkg -l | grep python.\*-dev ii python-all-dev 2.7.2-7ubuntu2 package depending on all supported Python development packages ii python-dev 2.7.2-7ubuntu2 header files and a static library for Python (default) ii python2.6-dev 2.6.7-4ubuntu1.1 Header files and a static library for Python (v2.6) ii python2.7-dev 2.7.2-5ubuntu1.1 Header files and a static library for Python (v2.7) Can someone who understand how the python build and packaging works please investigate? From kenj@internode.on.net Thu Feb 27 17:42:56 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id ACA6C7F3F for ; Thu, 27 Feb 2014 17:42:56 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 3B567AC001 for ; Thu, 27 Feb 2014 15:42:53 -0800 (PST) X-ASG-Debug-ID: 1393544571-04cb6c5677d8670001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id 3SvfTJB3jx86EifP for ; Thu, 27 Feb 2014 15:42:51 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowZAGDMD1N20adJPGdsb2JhbAANTYtVuwEDAQEBATiDGUA9FhgDAgECATEaDQgBAbFPoWQXkxMEriM Received: from ppp118-209-167-73.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.167.73]) by ipmail04.adl6.internode.on.net with ESMTP; 28 Feb 2014 10:12:50 +1030 Message-ID: <530FCD81.8060004@internode.on.net> Date: Fri, 28 Feb 2014 10:42:57 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: PCP Mailing List Subject: New QA failures Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-ASG-Orig-Subj: New QA failures Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1393544571 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145583 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- [92%] 712 - output mismatch (see 712.out.bad) 1a2,3 > cat: /proc/sys/crypto/fips_enabled: No such file or directory > 712: 35: test: -ne: unexpected operator Check local PMCD is still alive ... PMDA probe: pminfo -h bozo -f sample.milliseconds PMDA probe: pminfo -h bozo -f sampledso.milliseconds PMDA probe: pminfo -h bozo -f simple.numfetch [92%] 713 - output mismatch (see 713.out.bad) 1a2,3 > cat: /proc/sys/crypto/fips_enabled: No such file or directory > 713: 35: test: -ne: unexpected operator Check local PMCD is still alive ... PMDA probe: pminfo -h bozo -f sample.milliseconds PMDA probe: pminfo -h bozo -f sampledso.milliseconds PMDA probe: pminfo -h bozo -f simple.numfetch [92%] 714 - output mismatch (see 714.out.bad) 1a2,3 > cat: /proc/sys/crypto/fips_enabled: No such file or directory > 714: 35: test: -ne: unexpected operator Check local PMCD is still alive ... PMDA probe: pminfo -h bozo -f sample.milliseconds PMDA probe: pminfo -h bozo -f sampledso.milliseconds PMDA probe: pminfo -h bozo -f simple.numfetch Can the owner of these please fix? This is on Xubuntu 13.10. From nscott@redhat.com Thu Feb 27 18:26:59 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 96D387F3F for ; Thu, 27 Feb 2014 18:26:59 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id 793A88F8037 for ; Thu, 27 Feb 2014 16:26:56 -0800 (PST) X-ASG-Debug-ID: 1393547211-04bdf05daae2c90001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id qbcGac7vu3Dn9CzB for ; Thu, 27 Feb 2014 16:26:51 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1S0QlTM021182; Thu, 27 Feb 2014 19:26:47 -0500 Date: Thu, 27 Feb 2014 19:26:47 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: PCP Mailing List Message-ID: <2098686945.18221479.1393547207049.JavaMail.zimbra@redhat.com> In-Reply-To: <530FCD81.8060004@internode.on.net> References: <530FCD81.8060004@internode.on.net> Subject: Re: [pcp] New QA failures MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] New QA failures Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: New QA failures Thread-Index: XG59ekvAlnMjN5nmyyZDwFTWV3l2xw== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1393547211 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145585 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > [92%] 712 - output mismatch (see 712.out.bad) > ... > > cat: /proc/sys/crypto/fips_enabled: No such file or directory > > 714: 35: test: -ne: unexpected operator > Check local PMCD is still alive ... > PMDA probe: pminfo -h bozo -f sample.milliseconds > PMDA probe: pminfo -h bozo -f sampledso.milliseconds > PMDA probe: pminfo -h bozo -f simple.numfetch > > Can the owner of these please fix? > Bleurgh ... I didn't consider that case - this one's mine and is now fixed. cheers. -- Nathan From kenj@internode.on.net Thu Feb 27 18:40:33 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 2EDD17F3F for ; Thu, 27 Feb 2014 18:40:33 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id A9165AC001 for ; Thu, 27 Feb 2014 16:40:32 -0800 (PST) X-ASG-Debug-ID: 1393548029-04cb6c5676dbaf0001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id FRM6cwx5p97jCvYa for ; Thu, 27 Feb 2014 16:40:30 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMZAKHaD1N20adJPGdsb2JhbAANTYcbhDq2SoMJgS4DAQEBATiCWgEBAQQjFUABDAQLGAICBRYLAgIJAwIBAgExFAYNAQcBARexQ3agbBeBKY0sB4JugUkBA64j Received: from ppp118-209-167-73.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.167.73]) by ipmail04.adl6.internode.on.net with ESMTP; 28 Feb 2014 11:09:59 +1030 Message-ID: <530FDAE6.5070308@internode.on.net> Date: Fri, 28 Feb 2014 11:40:06 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nathan Scott CC: pcp@oss.sgi.com Subject: Re: [pcp] pcp updates - last piece of debian packaging changes for this round References: <530F9B64.4080505@internode.on.net> <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pcp updates - last piece of debian packaging changes for this round In-Reply-To: <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1393548029 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145585 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 28/02/14 08:39, Nathan Scott wrote: > Hi Ken, > > This part does not look like a valid solution - the "official" > buildd builds use the build dependencies to populate the build > root, so we have a chicken-and-egg situation here. In the end > this would result in this code no longer being built even when > it should be (in Debian release builds, not our local builds). OK, I'll put it back, but without a version number and let our build/configure magic decide if the version is new enough to build and package pcp-webapi. > ----- Original Message ----- >> [...] >> debian build - remove Build-Depends for libmicrohttpd-dev >> >> We handle this in the configure and packaging now ... if the right >> libmicrohttpd-dev is installed we build the pcp-webapi package, otherwise >> it is neither built nor packaged. > > Are these distros without microhttpd really current? ... Yes ... MOST of the debian-derived ones in my QA farm ... sigh. > ... If even > RHEL5 has it (which it does) I'm amazed that there are current > Debian variants that do not ... ? Can this problem be solved > by using more recent versions of these distros? Er, no. Not that I can see from using the official package repositories. From nscott@redhat.com Thu Feb 27 19:40:51 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id C65C87F3F for ; Thu, 27 Feb 2014 19:40:51 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id B459F8F8033 for ; Thu, 27 Feb 2014 17:40:48 -0800 (PST) X-ASG-Debug-ID: 1393551646-04cbb066e5e1d60001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id flpgxowDAjLNFbIE for ; Thu, 27 Feb 2014 17:40:47 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1S1egUi020755; Thu, 27 Feb 2014 20:40:42 -0500 Date: Thu, 27 Feb 2014 20:40:42 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: pcp@oss.sgi.com Message-ID: <506527158.18237145.1393551642685.JavaMail.zimbra@redhat.com> In-Reply-To: <530FDAE6.5070308@internode.on.net> References: <530F9B64.4080505@internode.on.net> <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> <530FDAE6.5070308@internode.on.net> Subject: Re: [pcp] pcp updates - last piece of debian packaging changes for this round MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pcp updates - last piece of debian packaging changes for this round Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates - last piece of debian packaging changes for this round Thread-Index: 85zsoG6OuVtP8v6oeVsKanJL6je6cQ== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1393551646 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145586 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > > Are these distros without microhttpd really current? ... > > Yes ... MOST of the debian-derived ones in my QA farm ... sigh. > [...] > Er, no. Not that I can see from using the official package repositories. I don't "get" how this can be, unless these distros are actively removing packages (which defeats alot of the point of using debian/ubuntu); a search on packages.debian.org shows all stable releases (even "oldstable" - now many many years old), have *some* form of libmicrohttpd ... https://packages.debian.org/search?keywords=libmicrohttpd&searchon=names&suite=oldstable§ion=all https://packages.debian.org/search?keywords=libmicrohttpd&searchon=names&suite=stable§ion=all So, how can this be possible? It doesn't make sense that they would remove packages like this - perhaps there is a "libdevel" section elsewhere for these distributions thats not in the default /etc/apt/sources.list? The current "stable" Debian release has the needed bits, and Debian has always been notoriously slow between stable releases. Perhaps we are testing the lunatic fringe a bit here - are there any Ubuntu or Debian releases in the QA farm that lack needed support? AFAICT, there should not be any. cheers. -- Nathan From kenj@internode.on.net Thu Feb 27 20:35:49 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 2426A7F3F for ; Thu, 27 Feb 2014 20:35:49 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay2.corp.sgi.com (Postfix) with ESMTP id E3E4C304070 for ; Thu, 27 Feb 2014 18:35:48 -0800 (PST) X-ASG-Debug-ID: 1393554943-04bdf05da9e9cb0001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id bjHdAGuHNO6KU5RZ for ; Thu, 27 Feb 2014 18:35:43 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkRAJP1D1N20adJPGdsb2JhbAANTYNBg1q+DYErAwEBAQE4gloBAQEDASMVQAEFBwQLGAICBRYLAgIJAwIBAgExFAYNAQcBAYdtFalkdqBqF4EpjSwHgm6BSQEDmWqUOQ Received: from ppp118-209-167-73.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.167.73]) by ipmail04.adl6.internode.on.net with ESMTP; 28 Feb 2014 13:05:42 +1030 Message-ID: <530FF605.2000809@internode.on.net> Date: Fri, 28 Feb 2014 13:35:49 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nathan Scott CC: pcp@oss.sgi.com Subject: Re: [pcp] pcp updates - last piece of debian packaging changes for this round References: <530F9B64.4080505@internode.on.net> <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> <530FDAE6.5070308@internode.on.net> <506527158.18237145.1393551642685.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] pcp updates - last piece of debian packaging changes for this round In-Reply-To: <506527158.18237145.1393551642685.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1393554943 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145588 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 28/02/14 12:40, Nathan Scott wrote: > > > ----- Original Message ----- >>> Are these distros without microhttpd really current? ... >> >> Yes ... MOST of the debian-derived ones in my QA farm ... sigh. >> [...] >> Er, no. Not that I can see from using the official package repositories. > > I don't "get" how this can be, unless these distros are actively removing > packages (which defeats alot of the point of using debian/ubuntu); a search > on packages.debian.org shows all stable releases (even "oldstable" - now > many many years old), have *some* form of libmicrohttpd ... > https://packages.debian.org/search?keywords=libmicrohttpd&searchon=names&suite=oldstable§ion=all > https://packages.debian.org/search?keywords=libmicrohttpd&searchon=names&suite=stable§ion=all So far, they all have _some_ form libmicrohttpd ... but the pcp-webapi code _depends_ on functionality that is not present in the older versions of the library (the PCP code will not compile!), and the revision the pcp code has been written to is not available in the older distros ... e.g the versions in oldstable debian probably because the developers of libmicrohttpd follow the open source view (unlike the sgi irix 6.5 view) that breaking the API/ABI is fine and to hell with backwards compatibility, which I'm guessing prevents backporting to older distros and leaves them stuck with older versions of the library > So, how can this be possible? It doesn't make sense that they would remove > packages like this - perhaps there is a "libdevel" section elsewhere for > these distributions thats not in the default /etc/apt/sources.list? The > current "stable" Debian release has the needed bits, and Debian has always > been notoriously slow between stable releases. > > Perhaps we are testing the lunatic fringe a bit here - are there any Ubuntu > or Debian releases in the QA farm that lack needed support? AFAICT, there > should not be any. I don't think we (er, I mean I) are/am on the lunatic fringe here ... we're more like innocent by-standers at the edge of the lunatic fringe ... 8^)> From fche@redhat.com Thu Feb 27 21:03:20 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 312BD7F3F for ; Thu, 27 Feb 2014 21:03:20 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id A72C4AC003 for ; Thu, 27 Feb 2014 19:03:19 -0800 (PST) X-ASG-Debug-ID: 1393556598-04bdf05da9eb5b0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id z9p1VIYUfYSENISK for ; Thu, 27 Feb 2014 19:03:18 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1S33GH5000970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Feb 2014 22:03:16 -0500 Received: from fche.csb (vpn-236-250.phx2.redhat.com [10.3.236.250]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1S33Fsr013573; Thu, 27 Feb 2014 22:03:15 -0500 Received: by fche.csb (Postfix, from userid 2569) id 2E44758508; Thu, 27 Feb 2014 22:03:15 -0500 (EST) To: Ken McDonell Cc: Nathan Scott , pcp@oss.sgi.com Subject: Re: pcp updates - last piece of debian packaging changes for this round References: <530F9B64.4080505@internode.on.net> <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> <530FDAE6.5070308@internode.on.net> <506527158.18237145.1393551642685.JavaMail.zimbra@redhat.com> <530FF605.2000809@internode.on.net> X-ASG-Orig-Subj: Re: pcp updates - last piece of debian packaging changes for this round From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 27 Feb 2014 22:03:15 -0500 In-Reply-To: <530FF605.2000809@internode.on.net> (Ken McDonell's message of "Fri, 28 Feb 2014 13:35:49 +1100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1393556598 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Ken McDonell writes: > [...] > > probably because the developers of libmicrohttpd follow the open > source view (unlike the sgi irix 6.5 view) that breaking the API/ABI > is fine and to hell with backwards compatibility, which I'm guessing > prevents backporting to older distros and leaves them stuck with older > versions of the library > I really don't get the impression that this is the case with libmicrohttpd. While they don't go to the full ABI-compatibility sort of efforts related to symbol versioning etc., I am not aware of any API breakage over the time. Instead of those folks, you might consider poking the debian packagers in question to see if they had considered moving to a newer version, and if not why. For that matter, why do they ship only pcp 3.3.3, or systemtap 1.2 for oldstable. - FChE From nscott@redhat.com Thu Feb 27 21:03:23 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 863197F52 for ; Thu, 27 Feb 2014 21:03:23 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay2.corp.sgi.com (Postfix) with ESMTP id 75FDA304043 for ; Thu, 27 Feb 2014 19:03:20 -0800 (PST) X-ASG-Debug-ID: 1393556595-04cbb066e7e5f30001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id gAowaHtQvYO2ZJof for ; Thu, 27 Feb 2014 19:03:16 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1S33Cx2002163; Thu, 27 Feb 2014 22:03:12 -0500 Date: Thu, 27 Feb 2014 22:03:12 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: Ken McDonell Cc: pcp@oss.sgi.com Message-ID: <1180352175.18258965.1393556591992.JavaMail.zimbra@redhat.com> In-Reply-To: <530FF605.2000809@internode.on.net> References: <530F9B64.4080505@internode.on.net> <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> <530FDAE6.5070308@internode.on.net> <506527158.18237145.1393551642685.JavaMail.zimbra@redhat.com> <530FF605.2000809@internode.on.net> Subject: Re: [pcp] pcp updates - last piece of debian packaging changes for this round MIME-Version: 1.0 X-ASG-Orig-Subj: Re: [pcp] pcp updates - last piece of debian packaging changes for this round Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates - last piece of debian packaging changes for this round Thread-Index: o7I1U4uOrSBG9tccj1JCSnhhDUAGUQ== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1393556595 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145589 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... ----- Original Message ----- > So far, they all have _some_ form libmicrohttpd ... but the pcp-webapi > code _depends_ on functionality that is not present in the older > versions of the library (the PCP code will not compile!), and the Ah right - OK, that makes more sense to me now - thanks. > revision the pcp code has been written to is not available in the older > distros ... e.g the versions in oldstable debian *nod* > > probably because the developers of libmicrohttpd follow the open source > view (unlike the sgi irix 6.5 view) that breaking the API/ABI is fine > and to hell with backwards compatibility, which I'm guessing prevents > backporting to older distros and leaves them stuck with older versions > of the library > Not sure that's what it is. As I see it, the problem is we've used new parts of the API in pmwebd. So *we* are the ones who have said to hell with backwards compatibility in doing so (no doubt totally oblivious to the impact of these decisions on each other at the time). From looking in the header, we prefer MHD_create_response_from_buffer over MHD_create_response_from_data (which is still present, but marked as deprecated in the header). Could we possibly support either API? (e.g. perhaps the configure.in could check for the new routine, and if not present, emulate it using the old interface? Frank?). > I don't think we (er, I mean I) are/am on the lunatic fringe here ... > we're more like innocent by-standers at the edge of the lunatic fringe > ... 8^)> :) cheers. -- Nathan From fche@redhat.com Thu Feb 27 21:12:02 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 253207F3F for ; Thu, 27 Feb 2014 21:12:02 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 051DE8F8039 for ; Thu, 27 Feb 2014 19:12:01 -0800 (PST) X-ASG-Debug-ID: 1393557117-04cb6c5676e3600001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id xTJy0UTn8UHLo35v for ; Thu, 27 Feb 2014 19:11:58 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1S3Bt0Q011503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Feb 2014 22:11:55 -0500 Received: from fche.csb (vpn-236-250.phx2.redhat.com [10.3.236.250]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1S3Bs5u029600; Thu, 27 Feb 2014 22:11:54 -0500 Received: by fche.csb (Postfix, from userid 2569) id 0994058508; Thu, 27 Feb 2014 22:11:53 -0500 (EST) To: Nathan Scott Cc: Ken McDonell , pcp@oss.sgi.com Subject: Re: pcp updates - last piece of debian packaging changes for this round References: <530F9B64.4080505@internode.on.net> <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> <530FDAE6.5070308@internode.on.net> <506527158.18237145.1393551642685.JavaMail.zimbra@redhat.com> <530FF605.2000809@internode.on.net> <1180352175.18258965.1393556591992.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: pcp updates - last piece of debian packaging changes for this round From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 27 Feb 2014 22:11:53 -0500 In-Reply-To: <1180352175.18258965.1393556591992.JavaMail.zimbra@redhat.com> (Nathan Scott's message of "Thu, 27 Feb 2014 22:03:12 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1393557117 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 nathans wrote: > [...] Not sure that's what it is. As I see it, the problem is > we've used new parts of the API in pmwebd. So *we* are the ones who > have said to hell with backwards compatibility in doing so [...] Backward compatibility does not mean basing one's new work on ancient code bases. (We don't limit ourselves to the UNIX v5 API either.) It means approximately that once we start working, we stay working, with particular kinds of future environmental changes. > From looking in the header, we prefer > MHD_create_response_from_buffer over MHD_create_response_from_data > (which is still present, but marked as deprecated in the header). > Could we possibly support either API? [...] I don't know, maybe. Or we could declare that debian oldstable is too old to build pmwebd, and give that a separate .deb .dsc file, so it doesn't even try. - FChE From nscott@redhat.com Thu Feb 27 21:13:02 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 8FE0B7F52 for ; Thu, 27 Feb 2014 21:13:02 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 70B07304043 for ; Thu, 27 Feb 2014 19:13:02 -0800 (PST) X-ASG-Debug-ID: 1393557180-04cb6c5677e3710001-S8gJnT Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id aQuOfX2v0BOnojHI for ; Thu, 27 Feb 2014 19:13:00 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.24 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1S3Cugr017102; Thu, 27 Feb 2014 22:12:56 -0500 Date: Thu, 27 Feb 2014 22:12:56 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: Ken McDonell , pcp@oss.sgi.com Message-ID: <739161368.18260012.1393557176552.JavaMail.zimbra@redhat.com> In-Reply-To: References: <530F9B64.4080505@internode.on.net> <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> <530FDAE6.5070308@internode.on.net> <506527158.18237145.1393551642685.JavaMail.zimbra@redhat.com> <530FF605.2000809@internode.on.net> Subject: Re: pcp updates - last piece of debian packaging changes for this round MIME-Version: 1.0 X-ASG-Orig-Subj: Re: pcp updates - last piece of debian packaging changes for this round Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates - last piece of debian packaging changes for this round Thread-Index: +02UOnnK2qspXBe8n9a1gL6NSVzPJQ== X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1393557180 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145589 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > Ken McDonell writes: > > > [...] > > > > probably because the developers of libmicrohttpd follow the open > > source view (unlike the sgi irix 6.5 view) that breaking the API/ABI > > is fine and to hell with backwards compatibility, which I'm guessing > > prevents backporting to older distros and leaves them stuck with older > > versions of the library > > > > I really don't get the impression that this is the case with > libmicrohttpd. While they don't go to the full ABI-compatibility sort > of efforts related to symbol versioning etc., I am not aware of any > API breakage over the time. *nod* > Instead of those folks, you might consider poking the debian packagers > in question to see if they had considered moving to a newer version, > and if not why. For that matter, why do they ship only pcp 3.3.3, or > systemtap 1.2 for oldstable. This isn't a Debian problem - Debian has long since moved on, and there are many newer versions of Debian since this one. However, these older platforms are still actively being used (evident from the fact we are having this discussion :). Asking developers to release stable versions more quickly doesn't help here (consider how far we might get trying to get a RHEL4 microhttpd update, for example). As a distributed, cross-platform toolkit it is actively in our interests to support as many actively used platforms as we possibly can & evidently some of these platforms (which Ken is telling us are still needed) are on this older microhttpd, so it seems we need to find a way to support it. cheers. -- Nathan From nscott@redhat.com Thu Feb 27 21:24:20 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 321B97F3F for ; Thu, 27 Feb 2014 21:24:20 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay1.corp.sgi.com (Postfix) with ESMTP id E80F18F8037 for ; Thu, 27 Feb 2014 19:24:19 -0800 (PST) X-ASG-Debug-ID: 1393557858-04bdf05da9ec670001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id 8aNhzBITUJ17xKmD for ; Thu, 27 Feb 2014 19:24:18 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1S3OFNT005939; Thu, 27 Feb 2014 22:24:15 -0500 Date: Thu, 27 Feb 2014 22:24:15 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: "Frank Ch. Eigler" Cc: Ken McDonell , pcp@oss.sgi.com Message-ID: <1156485848.18262880.1393557855271.JavaMail.zimbra@redhat.com> In-Reply-To: References: <530F9B64.4080505@internode.on.net> <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> <530FDAE6.5070308@internode.on.net> <506527158.18237145.1393551642685.JavaMail.zimbra@redhat.com> <530FF605.2000809@internode.on.net> <1180352175.18258965.1393556591992.JavaMail.zimbra@redhat.com> Subject: Re: pcp updates - last piece of debian packaging changes for this round MIME-Version: 1.0 X-ASG-Orig-Subj: Re: pcp updates - last piece of debian packaging changes for this round Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.12] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp updates - last piece of debian packaging changes for this round Thread-Index: dqoaNCdObLL3c2E5UmHioZTQfvrRZA== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1393557858 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.03 X-Barracuda-Spam-Status: No, SCORE=0.03 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO, BSF_SC0_SA_TO_FROM_DOMAIN_MATCH, THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145590 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.01 BSF_SC0_SA_TO_FROM_DOMAIN_MATCH Sender Domain Matches Recipient Domain ----- Original Message ----- > > From looking in the header, we prefer > > MHD_create_response_from_buffer over MHD_create_response_from_data > > (which is still present, but marked as deprecated in the header). > > Could we possibly support either API? [...] > > I don't know, maybe. > > Or we could declare that debian oldstable is too old to build pmwebd, > and give that a separate .deb .dsc file, so it doesn't even try. *nod* - there are many possible ways to tackle this. Conditionally doing the packaging is what was being tried but its proving problematic (and it is obviously not ideal for people on older platforms), so alternatives are being sought. cheers. -- Nathan From kenj@internode.on.net Thu Feb 27 21:56:04 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 933867F3F for ; Thu, 27 Feb 2014 21:56:04 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 713188F8035 for ; Thu, 27 Feb 2014 19:56:03 -0800 (PST) X-ASG-Debug-ID: 1393559760-04cb6c5677e5530001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id dSl5vzQ0WcQapgkj for ; Thu, 27 Feb 2014 19:56:01 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMZAGcIEFN20adJPGdsb2JhbAANTYcbhDq2SoMJgSoDAQEBATiCWgEBAQQjFUABDAQLGAICBRYLAgIJAwIBAgExFAYBDAEHAQEXsUV2oGwXgSmNLAeCboFJAQOUTZlW Received: from ppp118-209-167-73.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.167.73]) by ipmail04.adl6.internode.on.net with ESMTP; 28 Feb 2014 14:25:59 +1030 Message-ID: <531008D6.3040908@internode.on.net> Date: Fri, 28 Feb 2014 14:56:06 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nathan Scott , "Frank Ch. Eigler" CC: pcp@oss.sgi.com Subject: Re: pcp updates - last piece of debian packaging changes for this round References: <530F9B64.4080505@internode.on.net> <722030351.18148411.1393537152651.JavaMail.zimbra@redhat.com> <530FDAE6.5070308@internode.on.net> <506527158.18237145.1393551642685.JavaMail.zimbra@redhat.com> <530FF605.2000809@internode.on.net> <1180352175.18258965.1393556591992.JavaMail.zimbra@redhat.com> <1156485848.18262880.1393557855271.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: pcp updates - last piece of debian packaging changes for this round In-Reply-To: <1156485848.18262880.1393557855271.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1393559761 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145590 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- On 28/02/14 14:24, Nathan Scott wrote: > > > ----- Original Message ----- >>> From looking in the header, we prefer >>> MHD_create_response_from_buffer over MHD_create_response_from_data >>> (which is still present, but marked as deprecated in the header). >>> Could we possibly support either API? [...] >> >> I don't know, maybe. >> >> Or we could declare that debian oldstable is too old to build pmwebd, >> and give that a separate .deb .dsc file, so it doesn't even try. > > *nod* - there are many possible ways to tackle this. Conditionally doing > the packaging is what was being tried but its proving problematic (and it > is obviously not ideal for people on older platforms), so alternatives > are being sought. I was not looking to start a religious war ... My take on a "good" philosophy to guide development across multiple environments is ... try the following in order until you find an acceptable solution 1. use universally available services 2. use conditional/alternative code to support different service flavours 3. declare that some components will not be built for, or will work in a degraded mode in, some (usually older) environments What is not acceptable is breaking the build+packaging process. What we have now for pcp-webapi is 3. ... this clearly working for me across all platforms (this is a variant on Frank's second suggestion). Frank's first suggestion is 1. (or maybe 2.) from the list above and involves more work that I don't think is justified. I don't think there is disagreement here if Nathan is OK with my half-reversion of the debian/control.master change to put back the build dependency but without an open revision range. From kenj@internode.on.net Thu Feb 27 22:46:02 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id E49947F3F for ; Thu, 27 Feb 2014 22:46:01 -0600 (CST) Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by relay3.corp.sgi.com (Postfix) with ESMTP id 7FF31AC003 for ; Thu, 27 Feb 2014 20:46:01 -0800 (PST) X-ASG-Debug-ID: 1393562756-04bdf05da9efed0001-S8gJnT Received: from ipmail04.adl6.internode.on.net (ipmail04.adl6.internode.on.net [150.101.137.141]) by cuda.sgi.com with ESMTP id mwxGoSAW40ilzlFn for ; Thu, 27 Feb 2014 20:45:56 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.141 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av01AEkUEFN20adJPGdsb2JhbAANTYtVuVMBgSsDAQEBATiDWT0WGAMCAQIBMRoNCAEBsUyhXxeTEwSuIw Received: from ppp118-209-167-73.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.167.73]) by ipmail04.adl6.internode.on.net with ESMTP; 28 Feb 2014 15:15:30 +1030 Message-ID: <53101471.4000200@internode.on.net> Date: Fri, 28 Feb 2014 15:45:37 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: PCP Mailing List Subject: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) Content-Type: text/plain; charset=ISO-8859-1 X-ASG-Orig-Subj: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail04.adl6.internode.on.net[150.101.137.141] X-Barracuda-Start-Time: 1393562756 X-Barracuda-URL: http://192.48.157.11:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145591 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- This is Fedora release 17 (Beefy Miracle) all up to date on an PentiumPro (32-bit) VM Makepkgs dies with the (totally unhelpful) ... == Packaging pcp, log is in /home/kenj/src/pcp/Logs/pcp Packaging failed, see log in /home/kenj/src/pcp/Logs/pcp gmake[2]: Leaving directory `/home/kenj/src/pcp/pcp-3.9.1' error: Bad exit status from /var/tmp/rpm-tmp.LSjVmI (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.LSjVmI (%build) make[1]: *** [pack_pcp] Error 1 make[1]: Leaving directory `/home/kenj/src/pcp/build/rpm' make: *** [pack_pcp] Error 2 Digging into Logs/pcp the death roll goes like this ... === pmmgr === g++ -O2 -g -march=i386 -mtune=i686 -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all -D_FORTIFY_SOURCE=2 -Wall -O2 -g -DPCP_DEBUG -DPCP_VERSION=\"3.9.1\" -I./src/include -I./src/include/pcp -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all -D_FORTIFY_SOURCE=2 -Wall -O2 -g -DPCP_DEBUG -DPCP_VERSION=\"3.9.1\" -I../src/include -I../src/include/pcp -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all -D_FORTIFY_SOURCE=2 -fPIE -Wall -O2 -g -DPCP_DEBUG -DPCP_VERSION=\"3.9.1\" -I../../src/include -I../../src/include/pcp -O2 -g -march=i386 -mtune=i686 -O2 -g -march=i386 -mtune=i686 -c pmmgr.cxx -o pmmgr.o g++ -O2 -g -march=i386 -mtune=i686 -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all -D_FORTIFY_SOURCE=2 -Wall -O2 -g -DPCP_DEBUG -DPCP_VERSION=\"3.9.1\" -I./src/include -I./src/include/pcp -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all -D_FORTIFY_SOURCE=2 -Wall -O2 -g -DPCP_DEBUG -DPCP_VERSION=\"3.9.1\" -I../src/include -I../src/include/pcp -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all -D_FORTIFY_SOURCE=2 -fPIE -Wall -O2 -g -DPCP_DEBUG -DPCP_VERSION=\"3.9.1\" -I../../src/include -I../../src/include/pcp -O2 -g -march=i386 -mtune=i686 -o pmmgr -Wall -L../../src/libpcp/src -L../../src/libpcp_pmda/src -rdynamic -pie -Wl,-z,relro -Wl,-z,now pmmgr.o -lpcp -lpthread pmmgr.o: In function `__exchange_and_add': /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:48: undefined reference to `__atomic_fetch_add_4' collect2: error: ld returned 1 exit status gmake[4]: *** [pmmgr] Error 1 gmake[3]: *** [default_pcp] Error 2 gmake[3]: Leaving directory `/home/kenj/src/pcp/pcp-3.9.1/src' gmake[2]: *** [default_pcp] Error 2 gmake[2]: Leaving directory `/home/kenj/src/pcp/pcp-3.9.1' error: Bad exit status from /var/tmp/rpm-tmp.LSjVmI (%build) From nscott@redhat.com Fri Feb 28 00:13:37 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id 66A7E7F3F for ; Fri, 28 Feb 2014 00:13:37 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay1.corp.sgi.com (Postfix) with ESMTP id 5D28C8F8037 for ; Thu, 27 Feb 2014 22:13:34 -0800 (PST) X-ASG-Debug-ID: 1393568009-04cb6c5677eba70001-S8gJnT Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by cuda.sgi.com with ESMTP id uxKjbD3sZ7yvJqL4 for ; Thu, 27 Feb 2014 22:13:30 -0800 (PST) X-Barracuda-Envelope-From: nscott@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.25 Received: from zmail20.collab.prod.int.phx2.redhat.com (zmail20.collab.prod.int.phx2.redhat.com [10.5.83.23]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1S6DTAH032546 for ; Fri, 28 Feb 2014 01:13:29 -0500 Date: Fri, 28 Feb 2014 01:13:29 -0500 (EST) From: Nathan Scott Reply-To: Nathan Scott To: pcp@oss.sgi.com Message-ID: <1466087478.18292952.1393568009079.JavaMail.zimbra@redhat.com> In-Reply-To: <402863.18292609.1393567869246.JavaMail.zimbra@redhat.com> Subject: pcp-gui updates: pmchart preferences (wip) MIME-Version: 1.0 X-ASG-Orig-Subj: pcp-gui updates: pmchart preferences (wip) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.11] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF17 (Linux)/8.0.6_GA_5922) Thread-Topic: pcp-gui updates: pmchart preferences (wip) Thread-Index: GJNcH7EREuio8zoNI9oGb7Hq/WcXbA== X-Barracuda-Connect: mx4-phx2.redhat.com[209.132.183.25] X-Barracuda-Start-Time: 1393568009 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.02 X-Barracuda-Spam-Status: No, SCORE=0.02 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=THREAD_INDEX, THREAD_TOPIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145593 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 THREAD_INDEX thread-index: AcO7Y8iR61tzADqsRmmc5wNiFHEOig== 0.01 THREAD_TOPIC Thread-Topic: ...(Japanese Subject)... Changes committed to git://oss.sgi.com/nathans/pcp-gui.git dev src/chart/hostdialog.cpp | 14 + src/chart/hostdialog.h | 1 src/chart/main.cpp | 34 ++- src/chart/main.h | 13 + src/chart/settingsdialog.cpp | 229 ++++++++++++++++++++-- src/chart/settingsdialog.h | 18 + src/chart/settingsdialog.ui | 445 +++++++++++++++++++++++++++++++++++++++++-- 7 files changed, 710 insertions(+), 44 deletions(-) commit f2e674d3b7f8c989b067c1b4d809a6653a652edf Author: Nathan Scott Date: Fri Feb 28 17:08:37 2014 +1100 Work on pmchart Preferences for saved hosts and default font Work in progress - Saved Hosts is almost done, default font tab has a ways to go still. Fedora bugs 1069943 and 1069947. From fche@redhat.com Fri Feb 28 05:52:49 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 853977F3F for ; Fri, 28 Feb 2014 05:52:49 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 6D44B304071 for ; Fri, 28 Feb 2014 03:52:46 -0800 (PST) X-ASG-Debug-ID: 1393588361-04cb6c5677fbdf0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id UiebASCX906xXZt2 for ; Fri, 28 Feb 2014 03:52:42 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1SBqRbd025371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Feb 2014 06:52:27 -0500 Received: from fche.csb (vpn-236-250.phx2.redhat.com [10.3.236.250]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s1SBqQaC026917; Fri, 28 Feb 2014 06:52:26 -0500 Received: by fche.csb (Postfix, from userid 2569) id D53D05853E; Fri, 28 Feb 2014 06:52:25 -0500 (EST) To: Ken McDonell Cc: PCP Mailing List Subject: Re: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) References: <53101471.4000200@internode.on.net> X-ASG-Orig-Subj: Re: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) From: fche@redhat.com (Frank Ch. Eigler) Date: Fri, 28 Feb 2014 06:52:25 -0500 In-Reply-To: <53101471.4000200@internode.on.net> (Ken McDonell's message of "Fri, 28 Feb 2014 15:45:37 +1100") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1393588362 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Ken McDonell writes: > [...] > === pmmgr === > g++ -O2 -g -march=i386 -mtune=i686 -[...] > pmmgr.o: In function `__exchange_and_add': > /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:48: undefined reference to `__atomic_fetch_add_4' > [...] This one is an interesting issue. It turns out gcc for -march=i386 cannot compile c++ code via normal system headers. (e.g. [1], [2]) That's normally fine since people don't generally build -march=i386 binaries any more -- 32-bit Fedora uses -march=i686, for which the c++config.h file's "#define _GLIBCXX_ATOMIC_BUILTINS 1" is fine. What brings out i386 in the PCP builds is the joint effort of our top level configure.in: dnl Remove 4th name component, if present, from target, target_os, dnl build and build_os. Squash all x86 cpus into one LCD form - i386 [...] target_cpu=`echo $target_cpu | sed '[s/i[3-6]86/i386/]' | sed '[s/powerpc/ppc/]'` and build/rpm/GNUmakefile: eval $(RPMPROG) -ba $$DEFS \ --target $(TARGET_CPU)-$(TARGET_VENDOR)-$(TARGET_OS) \ --clean $(SPEC) Can someone explain why we do either of these and override distro defaults? If this is unchangeable, it may be possible to add autoconf-based LLDLIBS=-latomic that may result in linkable binaries. However, running the resulting binaries on an actual i386 (<< i686) hardware may well fail with SIGILL. [1] https://bugzilla.redhat.com/show_bug.cgi?id=455712 [2] http://stackoverflow.com/questions/5560882/glibcxx-atomic-builtins-not-defined-in-gcc-4-4-5 - FChE From fche@redhat.com Fri Feb 28 10:55:02 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id CBF087F3F for ; Fri, 28 Feb 2014 10:55:02 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id 478D6AC007 for ; Fri, 28 Feb 2014 08:54:59 -0800 (PST) X-ASG-Debug-ID: 1393606498-04cb6c567710fbf0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id cdkLjDG9kAp4ZQ2m for ; Fri, 28 Feb 2014 08:54:58 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1SGstFk003343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Feb 2014 11:54:55 -0500 Received: from fche.csb (vpn-236-250.phx2.redhat.com [10.3.236.250]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1SGssQp006349; Fri, 28 Feb 2014 11:54:55 -0500 Received: by fche.csb (Postfix, from userid 2569) id 23CC5589F7; Fri, 28 Feb 2014 11:54:53 -0500 (EST) To: Ken McDonell Cc: pcp@oss.sgi.com Subject: Re: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) References: <53101471.4000200@internode.on.net> X-ASG-Orig-Subj: Re: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) From: fche@redhat.com (Frank Ch. Eigler) Date: Fri, 28 Feb 2014 11:54:53 -0500 In-Reply-To: (Frank Ch. Eigler's message of "Fri, 28 Feb 2014 06:52:25 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1393606498 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 I wrote: > [...] > Can someone explain why we do either of these and override distro defaults? > > If this is unchangeable, it may be possible to add autoconf-based > LLDLIBS=-latomic that may result in linkable binaries. [...] On pcpfans.git, the fche/i686 branch has two commits for this problem. The first adds -latomic if it's available (but isn't on Fedora 17 due to gcc <= 4.7). The second drops the rpmbuild --target=FOO override. Now Makepkgs, manual CFLAGS...=-march=i386 builds all work. I do not have X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id 562197F3F for ; Fri, 28 Feb 2014 16:27:42 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id 43C7B304032 for ; Fri, 28 Feb 2014 14:27:39 -0800 (PST) X-ASG-Debug-ID: 1393626445-04cb6c56751303f0001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id K5rEzv1WtZrVb7bU for ; Fri, 28 Feb 2014 14:27:26 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAPgMEVN20adJ/2dsb2JhbAANTMIrgwyBK4MZAQEBAwE4QAEFCwsYCRYPCQMCAQIBRQYNAQcBAYdtqgqhZReOVQeENwEDriY Received: from ppp118-209-167-73.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.167.73]) by ipmail07.adl2.internode.on.net with ESMTP; 01 Mar 2014 08:57:25 +1030 Message-ID: <53110D4A.4090704@internode.on.net> Date: Sat, 01 Mar 2014 09:27:22 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: PCP Mailing List Subject: Re: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) References: <53101471.4000200@internode.on.net> X-ASG-Orig-Subj: Re: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1393626446 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Barracuda-BRTS-Status: 1 X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145615 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Thanks for the analysis Frank. On 28/02/14 22:52, Frank Ch. Eigler wrote: > > ... > What brings out i386 in the PCP builds is the joint effort of our > top level configure.in: > > dnl Remove 4th name component, if present, from target, target_os, > dnl build and build_os. Squash all x86 cpus into one LCD form - i386 > [...] > target_cpu=`echo $target_cpu | sed '[s/i[3-6]86/i386/]' | sed '[s/powerpc/ppc/]'` > > and build/rpm/GNUmakefile: > > eval $(RPMPROG) -ba $$DEFS \ > --target $(TARGET_CPU)-$(TARGET_VENDOR)-$(TARGET_OS) \ > --clean $(SPEC) > > Can someone explain why we do either of these and override distro defaults? I cannot ... and I would think that newbie rpm packagers might have done this wrong from the early days of making rpms. > If this is unchangeable, it may be possible to add autoconf-based > LLDLIBS=-latomic that may result in linkable binaries. However, > running the resulting binaries on an actual i386 (<< i686) hardware > may well fail with SIGILL. Hmm ... I doubt that it is unchangeable, so we should follow standard practice here (whatever that might be). The SIGILL is a concern. This means (I think) that we either (a) declare PCP is no longer supported on i386, i486 and i586, or (b) change the build to not include pmmgr in the rpms on these platforms (b) seems a better choice to me, but that may not be the consensus. Of course there are non-rpm builds for old 32-bit platforms that have not run across this problem, so I'm not sure if that is due to a different gcc version, or different gcc flags, or the SIGILL problem is either a non-problem or lurking undetected (I don't think any pmmgr QA has been run on these platforms ... I'm struggling to get the build and package working again on my QA farm, actually running QA is a yet to be crossed bridge). From kenj@internode.on.net Fri Feb 28 17:02:29 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (Postfix) with ESMTP id 4FCEF7F3F for ; Fri, 28 Feb 2014 17:02:29 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay3.corp.sgi.com (Postfix) with ESMTP id B90BAAC00A for ; Fri, 28 Feb 2014 15:02:25 -0800 (PST) X-ASG-Debug-ID: 1393628543-04cb6c5677133170001-S8gJnT Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [150.101.137.131]) by cuda.sgi.com with ESMTP id JHas0vKS0G8UVxjI for ; Fri, 28 Feb 2014 15:02:23 -0800 (PST) X-Barracuda-Envelope-From: kenj@internode.on.net X-Barracuda-Apparent-Source-IP: 150.101.137.131 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAAMVEVN20adJ/2dsb2JhbAANTMItgwyBKoMZAQEBBHgBEAsYCRYPCQMCAQIBRQYNAQcBAbF0oVwXjgQBARwzB4Q3AQOuJoFd Received: from ppp118-209-167-73.lns20.mel6.internode.on.net (HELO [192.168.1.100]) ([118.209.167.73]) by ipmail07.adl2.internode.on.net with ESMTP; 01 Mar 2014 09:32:23 +1030 Message-ID: <5311157B.9010004@internode.on.net> Date: Sat, 01 Mar 2014 10:02:19 +1100 From: Ken McDonell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Frank Ch. Eigler" CC: pcp@oss.sgi.com Subject: Re: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) References: <53101471.4000200@internode.on.net> X-ASG-Orig-Subj: Re: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: ipmail07.adl2.internode.on.net[150.101.137.131] X-Barracuda-Start-Time: 1393628543 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.7 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.145616 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header On 01/03/14 03:54, Frank Ch. Eigler wrote: > ... > On pcpfans.git, the fche/i686 branch has two commits for this problem. > The first adds -latomic if it's available (but isn't on Fedora 17 due > to gcc <= 4.7). The second drops the rpmbuild --target=FOO override. > Now Makepkgs, manual CFLAGS...=-march=i386 builds all work. I do not > have (All this is moot as to normal Fedora/EPEL builds, since those use > neither Makepkgs, nor rpmbuild --target=FOO overrides.) Well it is kind of relevant for anyone wanting to rebuild PCP from source on this platform combination. I am happy to have my option (a) or option (b) discussion from my previous mail, especially as this would waste less of Frank's time ... 8^)> From fche@redhat.com Fri Feb 28 17:18:09 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (Postfix) with ESMTP id A16437F3F for ; Fri, 28 Feb 2014 17:18:09 -0600 (CST) Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by relay1.corp.sgi.com (Postfix) with ESMTP id 8302C8F8037 for ; Fri, 28 Feb 2014 15:18:06 -0800 (PST) X-ASG-Debug-ID: 1393629484-04cbb066e4138d10001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id OdBhmuXIDDOMprpG for ; Fri, 28 Feb 2014 15:18:05 -0800 (PST) X-Barracuda-Envelope-From: fche@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1SNI0bg010116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Feb 2014 18:18:00 -0500 Received: from fche.csb (vpn-236-250.phx2.redhat.com [10.3.236.250]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1SNI00t020906; Fri, 28 Feb 2014 18:18:00 -0500 Received: by fche.csb (Postfix, from userid 2569) id 8BC54584E3; Fri, 28 Feb 2014 18:17:59 -0500 (EST) Date: Fri, 28 Feb 2014 18:17:59 -0500 From: "Frank Ch. Eigler" To: Ken McDonell Cc: pcp@oss.sgi.com Subject: Re: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) Message-ID: <20140228231759.GA18123@redhat.com> X-ASG-Orig-Subj: Re: pmmgr build failure on 32-bit Fedora release 17 (Beefy Miracle) References: <53101471.4000200@internode.on.net> <5311157B.9010004@internode.on.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5311157B.9010004@internode.on.net> User-Agent: Mutt/1.4.2.2i X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1393629485 X-Barracuda-URL: http://192.48.176.25:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Hi - On Sat, Mar 01, 2014 at 10:02:19AM +1100, Ken McDonell wrote: > [...] > g++ -O2 -g -march=i386 -mtune=i686 -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all -D_FORTIFY_SOURCE=2 -Wall -O2 -g -DPCP_DEBUG -DPCP_VERSION=\"3.9.1\" -I./src/include -I./src/include/pcp -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all -D_FORTIFY_SOURCE=2 -Wall -O2 -g -DPCP_DEBUG -DPCP_VERSION=\"3.9.1\" -I../src/include -I../src/include/pcp -fPIC -fno-strict-aliasing -D_GNU_SOURCE -fstack-protector-all -D_FORTIFY_SOURCE=2 -fPIE -Wall -O2 -g -DPCP_DEBUG -DPCP_VERSION=\"3.9.1\" -I../../src/include -I../../src/include/pcp -O2 -g -march=i386 -mtune=i686 -o pmmgr -Wall -L../../src/libpcp/src -L../../src/libpcp_pmda/src -rdynamic -pie -Wl,-z,relro -Wl,-z,now pmmgr.o -lpcp -lpthread > pmmgr.o: In function `__exchange_and_add': > /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:48: undefined reference to `__atomic_fetch_add_4' Right, this is the gcc <= 4.7 case, where a -latomic did not exist, so i686 libstdc++ genuinely couldn't be used with -march=i386. But where is the -march=i386 stuff coming from in your tree now? That CFLAGS strangely duplicative & wrong. (There are some -march=i386 stragglers in various GNUlocaldefs.32, but those aren't near pmmgr.) > > (All this is moot as to normal Fedora/EPEL builds, since those use > > neither Makepkgs, nor rpmbuild --target=FOO overrides.) > > Well it is kind of relevant for anyone wanting to rebuild PCP from > source on this platform combination. Even that should be working now, if the platform combination you are referring to is fedora-17 (which by the way is orphaned), i686, invoking it all via a Makepkgs in a clean directory, with those two fche/i686 patches. - FChE From scox@redhat.com Fri Feb 28 17:38:05 2014 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham version=3.3.1 X-Original-To: pcp@oss.sgi.com Delivered-To: pcp@oss.sgi.com Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (Postfix) with ESMTP id D391F7F3F for ; Fri, 28 Feb 2014 17:38:05 -0600 (CST) Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by relay2.corp.sgi.com (Postfix) with ESMTP id C4781304059 for ; Fri, 28 Feb 2014 15:38:02 -0800 (PST) X-ASG-Debug-ID: 1393630680-04cb6c56781356c0001-S8gJnT Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 5TGo5TAJLFw6aX9H for ; Fri, 28 Feb 2014 15:38:01 -0800 (PST) X-Barracuda-Envelope-From: scox@redhat.com X-Barracuda-Apparent-Source-IP: 209.132.183.28 X-ASG-Whitelist: Client Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s1SNc0eV008798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Feb 2014 18:38:00 -0500 Received: from [10.10.50.188] (vpn-50-188.rdu2.redhat.com [10.10.50.188]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s1SNbx5L003971; Fri, 28 Feb 2014 18:37:59 -0500 Message-ID: <53111DD7.60405@redhat.com> Date: Fri, 28 Feb 2014 18:37:59 -0500 From: Stan Cox User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Nathan Scott CC: PCP Subject: Re: [pcp] datetime enhancements References: <53042BF5.5070704@redhat.com> <2061040535.14512907.1393224703952.JavaMail.zimbra@redhat.com> X-ASG-Orig-Subj: Re: [pcp] datetime enhancements In-Reply-To: <2061040535.14512907.1393224703952.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1393630681 X-Barracuda-URL: http://192.48.176.15:80/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at sgi.com X-Barracuda-BRTS-Status: 1 Made the suggested changes to commit 1ba3f1fcc98964b Here is a summary of the changes: This code was imported so most of these changes are to bring the code into the pcp family. If you do add in the new __pmParseTime (impl.h/exports), as discussed below - and I think you probably should now - a new pmparsetime.3 man page would be a welcome addition (see pmparsectime.3 for a template). There seems to already be one diff --git a/qa/group b/qa/group index 06a1f08..eca61fe 100644 --- a/qa/group +++ b/qa/group @@ -889,6 +889,7 @@ avahi +751 libpcp local oss (there is a "git merge" conflict here with other recent test additions - just FYI, in case you do a git pull to update to current pcp dev code) Moved to 752 +#include +#include +#include It will make life easier to remove all those headers and just include pmapi.h (and probably impl.h too, depending on other questions below). pmapi.h indirectly gets config.h which has platform-specific details. Included pmapi.h and impl. +int __pmParseTime( + const char *string, /* string to be parsed */ + struct timeval *logStart, /* start of log or current time */ + struct timeval *logEnd, /* end of log or tv_sec == INT_MAX */ + /* assumes sizeof(t_time) == sizeof(int) */ + struct timeval *rslt, /* if parsed ok, result filled in */ + char **errMsg); /* error message, please free */ Er, wha? That's not going to fly; this symbol would need to be added to the exports file in libpcp. Do we want this directly callable via client tools? (maybe? dunno) If so, updates needed to exports and to impl.h -- if not, this test needs to call the API that calls this internal API. We do need to update exports file for other things planned for this next release, so its probably for the best to simply add it there I guess, then testing is simpler too. That does make me realise however, that there is no test coverage of the non-double-underscore API interfaces that will usually be used to access this functionality. A second test program (or perhaps a command line option for this one) could exercise that. That should check that examples of the existing syntax continue to be parsed in addition to the extended syntax. I suppose the "existing parsing is still working" is already tested, but we need to make sure the new parsing is indeed working from the non-double-underscore API - that latter part is all we really need still. Added test for pmParseTimeWindow. +int +main () +{ IIRC, this main() definition may cause compiler warnings on some platforms. Adding some getopts handling for the above issue will of course resolve this. Added proper main declaration + set_tm (NULL, &tmtmp, &tmstart, 0, 19, 11, 45); + tmtmp_str = asctime(&tmtmp); + char *tmtmp_c = strchr (tmtmp_str, '\n'); + *tmtmp_c = ' '; + __pmParseTime (tmtmp_str, &tvstart, &tvend, &tvrslt, &errmsg); + localtime_r (&tvrslt.tv_sec, &tmrslt); // time_t => tm Hmm, is this not timezone sensitive? (will this test pass no matter where it is run?) I added TZ=gmt to 752 invocation of test + int sfx; + for (sfx = 0; sfx < (sizeof(strftime_fmt) / sizeof(void*)); sfx++) { + int len = strftime (buffer, sizeof (buffer), strftime_fmt[sfx], &tmtmp); + if (len != 0) Inconsistency with braces? (on the "for" vs "if" lines - pick one and preferably the same as rest of pcp). Actually, the entire source file code style differs to all other qa/src programs. Will 'indent -linux -nce -i4' diff --git a/src/libpcp/src/GNUmakefile b/src/libpcp/src/GNUmakefile index 176079b..4a19e4b 100644 --- a/src/libpcp/src/GNUmakefile +++ b/src/libpcp/src/GNUmakefile @@ -58,6 +58,11 @@ LSRCFILES += accounts.c LLDLIBS += -lpsapi endif +CFILES += gettime.c xmalloc.c getdate.c Add directly into the original CFILES list. We've also added new headers here, so HFILES needs updating for the new headers. YFILES needs to be extended to include getdate.y - see pmie makefile for example. Added CFILES and HFILES +.y.c: + $(YACC) $< + /bin/mv y.tab.c `basename $< .y`.c See pmie makefile again - e.g. no hard-coded paths to binaries. Remove reference y.tab.c reference diff --git a/src/libpcp/src/check-statics b/src/libpcp/src/check-statics index bc30905..050c9bd 100755 --- a/src/libpcp/src/check-statics +++ b/src/libpcp/src/check-statics @@ -181,6 +181,26 @@ fetchlocal.o b splitmax.[0-9]* # single-threaded PM_SCOPE_DSO_PMDA fetch.o freeresult.o +getdate.o + d dst_table + d meridian_table + d military_table + d month_and_day_table + b RELATIVE_TIME_0 + d relative_time_table + d time_units_table + d time_zone_table + d universal_time_zone_table + r yycheck + r yydefact + r yydefgoto + r yypact + r yypgoto + r yyr1 + r yyr2 + r yytable + r yytranslate +gettime.o hash.o Comments need to be added to each of these explaining why/how they are safe in a multi-threaded environment. Everything ending in _table looks like it is a "const static" (readonly & hence safe). However all the yacc symbols are highly suspect and need comments and probably code audit to add missing locking. getdate.y has %pure-parser which bison says: Alternatively, you can generate a pure, reentrant parser. The Bison declaration `%define api.pure' says that you want the parser to be reentrant. The staticsall seem to be static const I also found the build failed for me in the check-statics phase - I had some unexpected symbols - yyval_default.[0-9]* in getdate.o and also some strange C.[0-9][0-9].[0-9]* symbol that I could not trace. Do you know what that might be? A regex as wide-open as C.* in check-statics would not be ideal, so I'd really least like to find out what this symbol is. I will check this on a RHEL release diff --git a/src/libpcp/src/getdate.c b/src/libpcp/src/getdate.c new file mode 100644 index 0000000..448657e --- /dev/null +++ b/src/libpcp/src/getdate.c This file is generated and should not be committed to the git repo. Remove from CFILES in Makefile too - check out pmie makefile for an example. Removed from repo +static char * +get_tz (char tzbuf[TZBUFSIZE]) + char *tz = getenv ("TZ"); Ah - this doesn't take into account the current timezone, in the stack that libpcp provides. See pmNewZone and pmUseZone. The TZ= support from the parser is gone in lieu of pcp -Z support + tmp = localtime (&now->tv_sec); pmLocaltime? pmLocaltime it is + if (strncmp (p, "TZ=\"", 4) == 0) Hmm, suspiscious for above reasons. +#if HAVE_STRUCT_TM_TM_ZONE We have no configure support for this. +#if HAVE_TZNAME We have no configure support for this. +# ifndef tzname + extern char *tzname[]; +# endif We unconditionally access this over in tz.c so the ifdef appears unnecessary for all platforms PCP has ever supported. + for (i = 0; i < 2; i++) + { + pc.local_time_zone_table[i].name = tzname[i]; Oh we keep pointers to it - can tzname ever change? I would punt that it can (see tz.c, which calls tzset - hmm, why is there no tzset in this new code??) + if (setenv ("TZ", tz1buf, 1) != 0) + goto fail; This is unlikely to play well with the existing timezone stacking in tz.c. +#ifdef HAVE_TM_GMTOFF We have no configure support for this. + done: + if (tz_was_altered) + ok &= (tz0 ? setenv ("TZ", tz0, 1) : unsetenv ("TZ")) == 0; Hmmm. Interesting, maybe this can be made to play nice after all. We do still need to take into account the existing zone setting - a QA test exercising use of pmNewZone & pmUseZone in conjunction with this new (internal) API seems warranted. The TZ= support from the parser is gone in lieu of pcp -Z support diff --git a/src/libpcp/src/getdate.h b/src/libpcp/src/getdate.h new file mode 100644 index 0000000..142231e --- /dev/null +++ b/src/libpcp/src/getdate.h @@ -0,0 +1,23 @@ +/* Parse a string into an internal time stamp. + + Copyright (C) 1995, 1997, 1998, 2003, 2004, 2007 Free Software + Foundation, Inc. + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2, or (at your option) + any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software Foundation, + Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. */ + +#include +#include + +bool get_date (struct timespec *, char const *, struct timespec const *); get_date function needs _PCP_HIDDEN annotation. This header should probably be rolled into internal.h. The use of bool as an error handling mechanism is different to the way the rest of libpcp works, so I'd advise not keeping that aspect either. _PCP_HIDDEN added. get_date.h removed --- /dev/null +++ b/src/libpcp/src/getdate.y @@ -0,0 +1,1520 @@ [...] + nanosecond-resolution time stamps, and in October 2004 to support + TZ strings in dates. */ We should verify if this latter feature functions with (or breaks) timezone stacking in libpcp. The TZ= support from the parser is gone in lieu of pcp -Z support +/* FIXME: Check for arithmetic overflow in all cases, not just + some of them. */ Eek. +// #include Mhmm. We need to sort out configuration by auditing the code, and adding to our configure checks, not just commenting the header out. SCOX removing TZ_ removed the configury + +/* Since the code of getdate.y is not included in the Emacs executable + itself, there is no need to #define static in this file. Even if + the code were included in the Emacs executable, it probably + wouldn't do any harm to #undef it here; this will only cause + problems if we try to write to a static variable, which I don't + think this code needs to do. */ +#ifdef emacs +# undef static +#endif The above can certainly go. Gone pecan This entire file has a different coding style to the rest of libpcp, not surprisingly. We need to decide whether to tradeoff consistency with the ability to make direct comparisons to new versions of the source code -- how often is this code updated? (upstream, I mean) I suspect we should embrace the existing code and make it our own - the header comments suggest few updates. These changes are a first crack at this +#if HAVE_COMPOUND_LITERALS We have no configure support for this. SCOX removing TZ_ removed the configury +/* We want a reentrant parser, even if the TZ manipulation and the calls to (Ah, good to hear!) + localtime and gmtime are not reentrant. */ Rest of libpcp uses the pcp lock to provide these guarantees - this code will need to be audited to check interactions there, and whether it is circumventing the existing locking. At first glance, it appears to be broken in this regard. Switched to pmLocalTime and gmtime_r, which is in POSIX + } + else + { This coding style is really jarring when reading it, to me at least - should be made consistent with the rest of the PCP code base. The use of whitespace inconsistently also is problematic (different whitespace in conditionals, function calls, etc). I'll run it through indent as mentioned above +static table const * +lookup_zone (parser_control const *pc, char const *name) +{ + table const *tp; + + for (tp = universal_time_zone_table; tp->name; tp++) + if (strcmp (name, tp->name) == 0) + return tp; + + /* Try local zone abbreviations before those in time_zone_table, as + the local ones are more likely to be right. */ + for (tp = pc->local_time_zone_table; tp->name; tp++) + if (strcmp (name, tp->name) == 0) + return tp; + + for (tp = time_zone_table; tp->name; tp++) + if (strcmp (name, tp->name) == 0) + return tp; + + return NULL; +} The above timezone table continues to make me nervous. Surely this needs to interact with the timezone code in tz.c in some way? So my understanding is pmParseTimeWindow is time zone agnostic and the time zone activities are handled in pmTimeStateSetup. Since the TZ= handling is now stripped out of the extended datetime support, this should be resolved +/* A reasonable upper bound for the size of ordinary TZ strings. + Use heap allocation if TZ's length exceeds this. */ +enum { TZBUFSIZE = 100 }; + +/* Return a copy of TZ, stored in TZBUF if it fits, and heap-allocated + otherwise. */ +static char * +get_tz (char tzbuf[TZBUFSIZE]) +{ + char *tz = getenv ("TZ"); + if (tz) + { + size_t tzsize = strlen (tz) + 1; + tz = (tzsize <= TZBUFSIZE + ? memcpy (tzbuf, tz, tzsize) + : xmemdup (tz, tzsize)); + } + return tz; +} Same comments as above. gone +#else +#if HAVE_TZNAME + { +# ifndef tzname + extern char *tzname[]; +# endif Same comments as earlier. gone +#if TEST + +int +main (int ac, char **av) +{ + char buff[BUFSIZ]; + + printf ("Enter date, or blank line to exit.\n\t> "); + fflush (stdout); + + buff[BUFSIZ - 1] = '\0'; + while (fgets (buff, BUFSIZ - 1, stdin) && buff[0]) + { + struct timespec d; + struct tm const *tm; + if (! get_date (&d, buff, NULL)) + printf ("Bad format - couldn't convert.\n"); + else if (! (tm = localtime (&d.tv_sec))) + { + long int sec = d.tv_sec; + printf ("localtime (%ld) failed\n", sec); + } + else + { + int ns = d.tv_nsec; + printf ("%04ld-%02d-%02d %02d:%02d:%02d.%09d\n", + tm->tm_year + 1900L, tm->tm_mon + 1, tm->tm_mday, + tm->tm_hour, tm->tm_min, tm->tm_sec, ns); + } + printf ("\t> "); + fflush (stdout); + } + return 0; +} +#endif /* TEST */ Is there actual test data that the authors of this code used with this test program? It would be good to pull that into our tests as well, in the same way we have pulled in the code. There is a test, one program, but it calls get_date directly, maybe I can glean some additional tests from it diff --git a/src/libpcp/src/gettime.c b/src/libpcp/src/gettime.c new file mode 100644 index 0000000..70bb5de --- /dev/null +++ b/src/libpcp/src/gettime.c @@ -0,0 +1,49 @@ [...] +// #include (same issue discussed earlier) +/* Get the system time into *TS. */ + +void +gettime (struct timespec *ts) +{ +#if HAVE_NANOTIME + nanotime (ts); +#else We have no configure check for this. nanotime doesn't appear to exist in Linux headers? As mentioned below, just use tv_usec +# if defined CLOCK_REALTIME Nor this. +[...] && HAVE_CLOCK_GETTIME Nor this. Removing TZ_ removed these + struct timeval tv; + gettimeofday (&tv, NULL); + ts->tv_sec = tv.tv_sec; + ts->tv_nsec = tv.tv_usec * 1000; The accuracy of gettimeofday tends to be accepted as plenty for the sorts of problems PCP is used to tackle. Just use tv_usec diff --git a/src/libpcp/src/rtime.c b/src/libpcp/src/rtime.c index 086981b..26f8ccb 100644 --- a/src/libpcp/src/rtime.c +++ b/src/libpcp/src/rtime.c @@ -1,5 +1,5 @@ /* - * Copyright (c) 1995 Silicon Graphics, Inc. All Rights Reserved. + * Copyright (c) 1995, 2014 Silicon Graphics, Inc. All Rights Reserved. Thank you, emacs automatic Copyright mechanism * This library is free software; you can redistribute it and/or modify it * under the terms of the GNU Lesser General Public License as published @@ -14,6 +14,7 @@ #include #include +#include #include "pmapi.h" #include "impl.h" [ Not needed? ... ] $ grep string.h /usr/include/pcp/*h /usr/include/pcp/pmapi.h:#include string.h include is gone @@ -519,6 +520,74 @@ __pmConvertTime( + +/* + * Used by xmalloc/xrealloc/xcalloc which are called by get_date, the datetime parser + */ + +void +xalloc_die (void) +{ + // error (exit_failure, 0, "%s", _("memory exhausted")); + abort (); +} + Not really appropriate error handling for a library. A __pmNoMem call would be more appropriate than xalloc_die too - but will need more context - I'd imagine date string parsing should never cause program exit - a graphical tool like pmchart might be calling it with an interactively-user-supplied string, for example. Changed to use malloc and friends int /* 0 -> ok, -1 -> error */ __pmParseTime( const char *string, /* string to be parsed */ @@ -533,7 +602,7 @@ __pmParseTime( struct timeval start; struct timeval end; struct timeval tval; - + int get_date (struct timespec *, char const *, struct timespec const *); No inline extern function definitions. This is already in a header, use that instead (should be internal.h by the time we're done). Moved to internal.h @@ -542,33 +611,62 @@ __pmParseTime( /* ctime string */ if (parseChar(&scan, '@')) { - if (__pmParseCtime(scan, &tm, errMsg) < 0) - return -1; - tm.tm_wday = NO_OFFSET; - __pmConvertTime(&tm, &start, rslt); + if (__pmParseCtime(scan, &tm, errMsg) >= 0) { + tm.tm_wday = NO_OFFSET; + __pmConvertTime(&tm, &start, rslt); + return 0; + } } (is there a memory leak on errMsg here) errMsg is passed in from the caller + /* datetime is not a pcp defined one, so drop down into the glib get_date case */ + int status = -1; + int rel_type = have_relative_date (scan); + struct timespec tsrslt; + struct timespec *tsrsltp = &tsrslt; IIRC, this (locals declared in the middle of a function) was reported as not working under some compiler versions recently - perhaps take this to a separate function? It seems logically connected so I put it in braces. Not opposed to moving dcls to the top but my personal preference is dcls near uses + if (parseChar(&scan, '@')) + rel_type = NO_OFFSET; + + if (rel_type == NO_OFFSET) + status = get_date (tsrsltp, scan, NULL); + else if (rel_type == NEG_OFFSET && end.tv_sec < INT_MAX) { + struct timespec tsend; + struct timespec *tsendp = &tsend; + TIMEVAL_TO_TIMESPEC (&end, tsendp); + status = get_date (tsrsltp, scan, &tsend); We're mixing up different code styles now - PCP style and glib style (4 space indents vs extra whitespace). indent get_date returns a bool doesn't it? This is the sort of bug I was half wondering might happen. Remove the use of bool would be best I think. Changed to return int Oh, whooah - are we guaranteed that an errMsg string will be correctly initialised for all failing cases? Might be OK, on reflection - if the strategy is just that we provide more passing cases (which AIUI is what we're doing), and pass out the earlier error string. Yeah, that's OK. I think. We definitely leak errMsg though - in all newly added passing cases, we leak the earlier error messages. An additional free right near the end, before "return 0;" should do the trick. That should be the caller's responsibility; right? Hmm I passed in an allocated buffer in the test. Fixed that and freed on error. diff --git a/src/libpcp/src/setenv.h b/src/libpcp/src/setenv.h new file mode 100644 index 0000000..92e7bba --- /dev/null +++ b/src/libpcp/src/setenv.h @@ -0,0 +1,54 @@ +#if HAVE_SETENV || HAVE_UNSETENV Its luck of the draw as to whether these will be defined correctly, if we don't pull in our config.h first here. (success would depend on the order of #includes at any/all places including this header) That said, everywhere else that modifies the environment (see tz.c, in particular) in libpcp uses putenv and provides locking. This is gone diff --git a/src/libpcp/src/timespec.h b/src/libpcp/src/timespec.h new file mode 100644 index 0000000..cce2d66 --- /dev/null +++ b/src/libpcp/src/timespec.h @@ -0,0 +1,37 @@ +#if ! defined TIMESPEC_H +# define TIMESPEC_H + +# include + +/* Return negative, zero, positive if A < B, A == B, A > B, respectively. + Assume the nanosecond components are in range, or close to it. */ +static inline int +timespec_cmp (struct timespec a, struct timespec b) +{ + return (a.tv_sec < b.tv_sec ? -1 + : a.tv_sec > b.tv_sec ? 1 + : a.tv_nsec - b.tv_nsec); +} +void gettime (struct timespec *); (Open code use of gettimeofday like everywhere else in libpcp, remove gettime use - or, make everywhere else use it if it has value to us? I recommend the former option) Used gettimeofday +int settime (struct timespec const *); (unused - remove) So, could just move that inline call into internal.h, and remove the new header entirely. Gone diff --git a/src/libpcp/src/xalloc.h b/src/libpcp/src/xalloc.h new file mode 100644 index 0000000..0c6d8dc --- /dev/null +++ b/src/libpcp/src/xalloc.h @@ -0,0 +1,271 @@ +/* xalloc.h -- malloc with out-of-memory checking This entire header needs to be removed. Its not appropriate to abort() on memory allocation error in a library, nor to introduce special, different handling of memory allocation just for this new code. Fortunately, there's almost nothing using these interfaces, so conversion to usual libpcp memory allocation failure handling should be straightforward. In fact, most of the routines and defines in this new header are completely unused anyway. 6t5 diff --git a/src/libpcp/src/xmalloc.c b/src/libpcp/src/xmalloc.c --- /dev/null +++ b/src/libpcp/src/xmalloc.c @@ -0,0 +1,123 @@ Likewise, remove this file entirely please. Done Changed to use malloc and friends