-
Notifications
You must be signed in to change notification settings - Fork 442
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
command pipe corruption writing to nagios.cmd #35
Comments
Proper attribution: The above comment was originally posted by @box293 http://support.nagios.com/forum/viewtopic.php?f=7&t=31900&start=10#p132182 |
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:
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. |
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? |
You understand correctly. |
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. |
Sounds good to me. I'm closing this issue. |
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:
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
The text was updated successfully, but these errors were encountered: