Hi Ken,
----- Original Message -----
> On 06/07/13 14:03, Ken McDonell wrote:
> >...
> > Anyway, the real issue here is commit dc62541 that added pmlogconf to
> > pmlogger_check.sh ...
>
> Upon further investigation it appears that my initial analysis was not
> quite correct,
It still seems incorrect - from "apparently" onward, below.
Which version of PCP did you upgrade from? Do you happen
to have timestamps/contents of the affected files still, by
any chance?
> although the end result of a radically changed pmlogger
> configuration remains the same.
Given some of the things now being suggested as a result of
this, I'd really like to understand what actually happened
here ...
> foo n n PCP_LOG_DIR/pmlogger/foo -c ./config.foo
>
> In my setup, config.foo was in $PCP_SYSCONF_DIR/pmlogger.
OK, with you so far.
> So when the new pmlogger_check needs to start a pmlogger, and apparently
> only checks in $PCP_LOG_DIR/pmlogger/foo sees there is no config.foo and
> so it creates one using pmlogconf with all the default values.
That last sentence cannot be correct.
> Rather than clobbering my config.foo as I had assumed, pmlogger_check
> has installed a new config.foo that pmlogger uses in lieu of my
> customized one.
AIUI, you are suggesting pmlogconf created a new configuration
file in PCP_LOG_DIR/pmlogger/foo/config.foo? I find that very
hard to believe. It certainly does not match my own testing &
observations, nor does it match what the code does at line 695
of pmlogger_check.sh.
Given other follow-up mail, could the reverse of what you wrote
above have happened (no PCP_SYSCONF_DIR file initially)? Or,
could you be a victim of the PCP_VAR_DIR/pmlogger/config ->
PCP_SYSCONF_DIR transition? (if so, this issue would have had
nothing to do with the pmlogconf changes at all!).
Either way, we need to get to the bottom of this. There's alot
of misunderstanding / misinformation on this event now - if any
decisions are going to be made based on what happened here, they
need to be well-informed decisions.
Thanks!
--
Nathan
|