On 13/07/13 06:44, Frank Ch. Eigler wrote:
nathans wrote:
[...]
this server process would not need to run pmlogconf/pmieconf, I think.
Considering kenj's problems, I believe that running pm*conf from the
cron FOO_check.sh is not a good idea after all...
I agree. It would seem to be prudent to separate the initial config
file generation based on the local environment to something that is done
once post-install, and possibly could be redone later by hand if
required (e.g. if the local environment changes without a PCP
install/upgrade).
Overall, the _check scripts don't seem to be a very good fit for
robust and rapid management of pmlogger/pmie lifecycles. It seems
like we'd need a baby init(8) or systemd(8).
This is a new (and important I agree) use case that probably warrants
some new engineering thought and execution, rather than trying to weld
something onto the 10+ year old cron-script framework.
(While I was learning about this part, I was also struck by the
perhaps heavy-handed way in which pmlogger_daily* / pmlognew work.
Every day, they track, snare, and shoot down pmloggers, move/compress
files, create some new configuration for them, then restart pmloggers.
In the mean time, event or performance data can get lost... Please
let's fix this, e.g., to be based on signals to long-lived pmloggers.)
There are a number of cans of worms here ... each archive is a complete
unit, so when you "switch" to a new day, all the meta data needs to be
rewritten ... the simplest way to do this is to start a new pmlogger
instance. It is unclear how much state an old pmlogger can really carry
forward into a new archive instance. I think we should carry this topic
forward into a discussion thread of its own.
|