On 03/06/2014 03:32 AM, Nathan Scott wrote:
* For this case where the response is "Unable to connect: ...
Connection refused", the loop should exit immediately.
That doesn't sound right - did you mean "Permission denied"? We expect
to get connection refused (i.e. pmlogger is not yet listening) for some
time, for pmlogger processes logging far-away hosts in particular.
At the end of the day, none of this is acceptable behaviour for someone
upgrading a perfectly working system of course. We can also expect that
some people will continue to use existing configuration files - we can't
assume any change there (via pmlogconf), it needs to Just Work (and it'd
be preferable to improve security for those folks with unchanged configs
too, but that may not be possible & that's fine). There are people who
generate or otherwise supply pmlogger config files of their own crafting
- e.g. predating pmlogconf - those environments need to continue working
after the upgrade.
You were right, there was a bug lurking.
When __pmConnectLogger() uses local:[path] to connect, it is supposed to
try unix:[path] followed localhost. This was working ok for the case
when connection via unix: could not be established. However when the
connection was established but terminated due to insufficient access
control permissions, __pmConnectLogger() did not go on to try connecting
as "localhost".
This caused a problem for installations using the old access controls
disallow * : all;
allow localhost : enquire;
The first clause disallows unix:* and the allowed connection as
"localhost" was never attempted.
There was also a bug which caused "connection refused" to be returned in
this situation. As a result, pmlogger_check looped in a futile attempt
to make a connection that would never be accepted.
Dave
Dave
|