I think the most interesting information is in the cmk-update-agent.log in my first post, but the cmk-update-agent plugin is a 64bit binary with an integrated python environment. I have no idea how i can debug this.
I have performed a tcpdump on the site hosting machine while performing a manual run of cmk-update-agent on the affected host.
I see, that the request is delivered by the systemwide apache2 service via “Transfer-Encoding: chunked”, which means, there is no Content-Length header set:
But when I go further and examine the HTTP request from the system-wide apache to the OMD site instance apache, the request is been delivered with a content length correctly:
When Apache decides to switch to gzip encoding, it also uses Transfer-Encoding: chunked to deliver the response as it compresses by chunks and directly sends it to the client (in this case, the cmk-update-agent script).
As a workaround I have disabled compression for the vhost-definition that serves all OMD sites:
# CheckMK
SetEnv no-gzip dont-vary
Include /omd/apache/*.conf
With this, the error does not popup anymore.
But in general, cmk-update-agent should not rely on the Content-Length header, as it can be missing in case of chunked encoding.
FYI, I found the issue, as we have a NGINX Rev Proxy in between the host and CMK, it was doing the gziping of head info.
So this said, I guess it is confirmed that the gzip of chunked encoded data causes the agent to mark the python-request as bad content, ie the error “Content Length”.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.