Closed llange closed 2 years ago
A pull request would be perfect. I cannot think of a regression if it's simply not possible right now. I guess livestatus would be a good place to fix this, since livestatus simply passes the commands to the query handler. And if i read #144 correctly, then the query handler is capable of multiline output.
Yes I confirm that the query handler does accept multiline output:
echo -e '@command run [$(date +%s)] PROCESS_SERVICE_CHECK_RESULT;HOST;SERVICE;0;FirstLine_SecondLine\nLine2\nLine3\0' | socat - UNIX-CONNECT:/var/lib/naemon/naemon.qh
[1656618897.153289] [016.2] [pid=5942] Parsing check output...
[1656618897.153292] [016.2] [pid=5942] Short Output: FirstLine_SecondLine
[1656618897.153294] [016.2] [pid=5942] Long Output: Line2\nLine3
[1656618897.153297] [016.2] [pid=5942] Perf Data: NULL
OK so I'll dive into livestatus code and try to make it work ; and will update with a PR then.
Thanks for the merge, I'm closing the issue then.
While migrating from a Nagios 3.x to a Naemon 1.3, I just discovered a change in behaviour regarding the handline of passive checks results with multiple lines in their output.
In previous Nagios + Livestatus setup, I was able to submit a passive check result with multiple lines of long service output. To do so, I needed to escape the newlines (as Livestatus is a line-oriented protocol, it stops processing a line after the newline
\n
character).Now since using Naemon, I find that this is not possible anymore, i.e. the whole output is captured in SERVICEOUTPUT as a whole.
Examples
No LONGSERVICEOUTPUT
Command
Debug log
Incorrectly parsed LONGSERVICEOUTPUT
Command
Incorrect debug log
Expected debug log
Impossible to send unescaped
\n
(As Livestatus is line-oriented, a real
\n
character is taken as a line separator, thus does not land in the raw plugin output)I found a similar issue #144 but with no real progress on it.
I believe it could be related to the fact that
parse_check_output()
has been modified between Nagios 3.x and Nagios 4.x / Naemon, and that it now expects real (unescaped)\n
characters.What would be the preferred way to patch for this ? I'm willing to fix it, but before rushing I'd like to have feedback on the appropriate way to deal with it - and test for regressions.
Thanks.