Ken McDonell

@andreasgerstmayr Do you have any idea if the non-threadsafe behaviour is above or below libpcp on the callstack?

@myllynen I'm experimenting with a change to pmlogger that will defer writing the label records and the preamble (which is a synthetic pmResult) until the first real pmResult is seen,...

@goodwinos I don't think there is a problem here. A relative pathname for the config file in /var/log/pcp/pmlogger/somehost is perfectly normal (. is where pmlogger looks first to find the...

@natoscott Basically LGTM. My only questions (that I can't resolve from the diffs) are: 1. Is the state of the auxiliary data (and in particular the hashed indom data) is...

I see some of my issues above have been addressed in the first commit (I was only looking at the second commit) ... proper review will be done shortly.

I don't think it was an oversight ... another example of the uneasy truce between pcp and systemd ... these other loggers are not directly controlled by systemd and they...

Mea culpa @andreasgerstmayr ... I did not look closely enough. $PCP_SYSCONFIG_DIR has nothing to do with systemd. So I revise my vote and I'm +1 with @natoscott.

Some progress, it appears the "error sending connection" messagesin pmlogger.log have a reason (this is new diags with -Dpdu in libpcp's pdu.c) ... ``` __pmXmitPDU: socket _pmSend() result -1 !=...

And the first "problem" is a non-problem I believe, as just ahead of the pmlc call in pmlogger_check, there is this snippet ``` [ -z "$PMLOGGER_REQUEST_TIMEOUT" ] && export PMLOGGER_REQUEST_TIMEOUT=2...

OK, I think I understand what's happening now. The environment setting PMLOGGER_REQUEST_TIMEOUT=2 **is** in play. pmlogger_check is running pmlc repeatedly, each one tries a connect to pmlogger, but if pmlogger...