Changes committed to git://oss.sgi.com/kenj/pcp.git dev
qa/366 | 48 +++++++++++++++++++++++++++++++++++++----
qa/366.darwin.1 | 18 ---------------
qa/366.darwin.2 | 24 --------------------
qa/366.linux.1 | 12 ----------
qa/366.linux.2 | 18 ---------------
qa/366.solaris.1 | 12 ----------
qa/366.solaris.2 | 18 ---------------
src/pmie/pmie_check.sh | 6 ++++-
src/pmie/pmie_daily.sh | 6 ++++-
src/pmlogger/pmlogger_check.sh | 10 +++++---
src/pmlogger/pmlogger_daily.sh | 6 ++++-
11 files changed, 66 insertions(+), 112 deletions(-)
commit c7467f70376b8987ccd686436f7ef2937c3ec840
Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Sat Sep 7 06:38:20 2013 +1000
qa/366 - some re-engineering
Provide a more robust way of dealing with pmlogconf evolutionary
changes and platform dependencies.
commit 623240bd764f8cb8e0803507cd349ee0bb272b4e
Author: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Sat Sep 7 06:30:32 2013 +1000
pmie/pmlogger control scripts - bad pmproxy handling
Same problem in the "check" and "daily" scripts for pmlogger and
pmie, namely if the control file contains a host accessed via
explicit pmproxy, e.g. realhost@proxyhost then badness happens.
Specifically, the scripts fail to recognize that the corresponding
pmie or pmlogger is running, so by default they will start a
new one every time the check script runs. For pmlogger, at the
end of the day the daily script will combine all of the archives
(with the same data logged from 1 to 48 times!), remove all the
component archive files _and_ leave all the pmlogger instances
running _and_ start another one.
And yes, this did happen in a real production environment!
|