Changes committed to git://oss.sgi.com/kenj/pcp.git dev
build/GNUlocaldefs.in | 11 ++--
configure | 2
configure.in | 2
qa/admin/check-vm | 1
src/pmevent/doargs.c | 12 +++--
src/pmie/src/pmie.c | 11 +++-
src/pmie/src/pragmatics.c | 10 +++-
src/pmlogger/pmnewlog.sh | 104 +++++++++++++++++++++++++++++++-------------
src/pmlogger/src/pmlogger.c | 5 ++
src/pmstat/pmstat.c | 12 +++--
10 files changed, 122 insertions(+), 48 deletions(-)
commit 0abf69a2f309792ce0f3d1544cb263c690bf95e7
Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Fri Mar 14 09:17:35 2014 +1100
pmlogger_daily - fix problem with pmproxy connections
If the pmlogger control file contains a "host" of the form
"pmcd_host@some_pmproxy_host", then pmlogger_check works as
expected, but pmlogger_daily fails to restart the new pmlogger each
night, leaving it to pmlogger_check to fix the next time it runs.
The problem was really in pmnewlog ... this commit fixes it.
commit ff30d53b7b554e485439e8864dfb4906aec3a724
Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Fri Mar 14 09:16:38 2014 +1100
qa/admin/check-vm - need python-ctypes for some builds
commit bf36baa90e3ebea5ef7441c263c8673f3c8bc902
Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Thu Mar 13 15:36:37 2014 +1100
improved error handling - pmGetContextHostName() usage
In a drive-by code review, I spotted a use of pmGetContextHostName()
with poor error handling ... an error here returns an empty string
which may be OK, but when it is not, we should die right there,
not hope vainly that some latter check will detect this and report
something that is not obviously related.
Checked all the code and found several dodgey uses in a similar
vein, so hardened 'em all up.
commit c49b8b1002c4f6c41cd90b1936290965e741ddd5
Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Thu Mar 13 15:09:29 2014 +1100
configure changes - retire TARGET_VENDOR, TARGET_CPU, BUILD_VENDOR, ...
Retire TARGET_VENDOR, TARGET_CPU, BUILD_VENDOR, BUILD_CPU and
BUILD_OS from the PCP build infrastructre as they are no longer
used.
Also stop modifying $build_cpu and $vendor_cpu in configure
... this seems unnecessary and maybe even dangerous.
|