Forum OpenACS Development: Strange output of munin.tcl

Request notifications

Posted by Michael Aram on
If point my browser to e.g., I see four lines, with currently this data
max.value 40
current.value 10
busy.value -1
nrthreads.value 49
If I do a "view source" in the browser, the newlines seem to disappear, but this is not the problem (but may help in the analysis). The strange thing is, that for some reason, if I try to fetch this page via curl or wget, I always only get the latest key-value pair, i.e. in this case nrthreads.value 49. See below an example:
curl -is
HTTP/1.1 200 OK
Server: NaviServer/4.99.16d10
Date: Wed, 25 Oct 2017 08:23:07 GMT
Strict-Transport-Security: max-age=31536000
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin
Set-Cookie: ad_session_id="2710947214%2c0%2c0%2c1508919787%20{669%201508920987%20B0194E1280160B1BEAEF7C5811922C542385C690}"; Expires=Fri, 01-Jan-2035 01:00:00 GMT; Path=/; Secure; Discard; HttpOnly
Content-Type: text/plain; charset=utf-8
Content-Length: 62
Connection: keep-alive

nrthreads.value 4
If I intercept the transmission using mitmproxy, the "raw response" is rendered correclty (all four lines). If I switch to hex mode, it seems as if the newlines were CR. At least, if I read this correctly:
0000000000 6d 61 78 2e 76 61 6c 75 65 20 34 30 0d 63 75 72   max.value 40.cur
0000000010 72 65 6e 74 2e 76 61 6c 75 65 20 31 30 0d 62 75   rent.value 10.bu
0000000020 73 79 2e 76 61 6c 75 65 20 2d 31 0d 6e 72 74 68   sy.value -1.nrth
0000000030 72 65 61 64 73 2e 76 61 6c 75 65 20 34 39         reads.value 49
So, what does this mean? Are the command-line clients overly picky? Or should it be 0A or 0D0A instead of 0D, to be valid? Is some misconfiguration the culprit? Any ideas? IMHO, there must be at least something wrong on "our" side, if curl and wget arent able to display the first 3 "lines" of the response, right?
Posted by Gustaf Neumann on
When the lines are terminated with CR only, most terminals print the lines over each other, which means, when they print a CR, the cursor jumps to the beginning of the same line. So, you probably did not get "the latest key-value pair", but all, but you could only see the in the terminal the latest.

All munin versions i know of work fine with the output of the script. Was your question just just out of curiosity, or did you actually observed an issue? For debugging of munin output, one should use "munin-run PLUGIN_NAME".

Nevertheless, i have changed in git end-line termination to CRLF, it seems, that everything continues to work.

Posted by Michael Aram on
Thank you for the clarification, this makes sense.

I did not observe a "real issue", I simply wanted to double-check the output of the munin endpoint using the command line. I am aware of munin-run, however, I sometimes perform direct invocations for testing as well.

I think your change is an improvement, even if not strictly necessary, thank you!