command pipe corruption writing to nagios.cmd

[emerchantc]

What I found was, if you didn't submit he command with a "\n" at the end then it wouldn't work but was "appended/kept in the buffer" and then later when a correct command was issued the previous kept information was also submitted.

You can see the location of "\n" in the following example:

now_epoch=$(eval date +%s); printf "[$now_epoch] ADD_HOST_COMMENT;centos03;1;nagiosadmin;This host does funny stuff\n" > /usr/local/nagios/var/rw/nagios.cmd

I think it would be prudent to clear out the contents of the buf variable in command_input_handler after each process_external_command1 run. It's certainly not ideal to have corruption pop up at all, but I don't see any reason to keep bogus commands around in that variable to (possibly) be executed later.

see http://support.nagios.com/forum/viewtopic.php?f=7&t=31900

[tmcnag]

Proper attribution: The above comment was originally posted by @box293

http://support.nagios.com/forum/viewtopic.php?f=7&t=31900&start=10#p132182

[jfrickson]

The left over cruft at the end of the command buffer doesn't matter. The actual data passed to process_external_command1 is null-terminated by replacing the newline character with a null. So it's just cosmetic in the debug log.

Unless I can be guaranteed that there will never be a '[' character in the command data, there is no good way to separate multiple commands that have been concatenated because of missing newlines. I could look for a '[' followed by ten digits followed by a ']' (i.e. a timestamp) and assume that's the start of a new command. Would it be better to:

1. Process one or more commands late and possibly have a false positive split a single command into two parts, and take a little more processing time, or

2. Process multiple concatenated commands as one command if there's missing newlines

Option 2 (the way it is now) would be the result of an improperly formatted command on the user's part. Option 1 would involve us potentially rejecting a valid command.

[box293]

So if I understand what you are saying, a command submitted without a /n sits in the buffer. If more commands without a /n are received they will be appended to the buffer. Eventually a correct command comes along with a /n. At this point, the entire buffer, including the last command with the /n is processed ... however the entire buffer string is targeted at the host defined in the first command in the buffer and all the other commands never get targeted to the remaining correct hosts?

[jfrickson]

You understand correctly.

[box293]

I don't think there is any real fix for this that I can think of. If a command is submitted without a new line then it's an invalid command. It's just that the side affect is that it sits in the buffer until a correctly defined command comes along.

[jfrickson]

Sounds good to me. I'm closing this issue.