Description of problem: Upgrade of nsca-client from 2.9.2-8 to 2.10.0-1 stopped client communication to nsca server 2.9.2. Version-Release number of selected component (if applicable): Name : nsca-client Version : 2.10.0 Release : 1.fc31 Architecture : x86_64 Size : 74 k Source : nsca-2.10.0-1.fc31.src.rpm Repository : @System From repo : updates Summary : Client application for sending updates to a nsca server URL : http://www.nagios.org/ License : GPLv2+ Description : Client application for sending updates to a nsca server. How reproducible: dnf update when nsca-client 2.9.2-8 is installed, 2.10.0-1 will be installed. Attempt to send data to nsca server, get: 0 data packet(s) sent to host successfully. Steps to Reproduce: 1. 2. 3. Actual results: 0 data packet(s) sent to host successfully. Expected results: 1 data packet(s) sent to host successfully. Additional info: No configuration change involved. Just a pkg update with expectation that things should continue to work. I had to downgrade nsca-client back to 2.9.2-8 in order to be able to continue to monitor passively from this host (Fedora Server 31). The nsca server is 2.9.2 on Ubuntu.
If there are troubleshooting steps to run, I'm willing to do so, at present I don't know what else to do, there was nothing in logs indicating a problem, only that output from the commandline.
This is really curious, I don't see what could be causing this and I cannot reproduce locally (I used an F32 box, with the nsca 2.10 and nsca-client 2.9) Could you try to reproduce such a setup with only Fedora to rule out the Ubuntu nsca server ? Do you have access to the nsca server logs ?
You have it reversed, the nsca server is 2.9.2, nsca-client was 2.10.0. nsca/nsca-client 2.10 are not available as pkgs for ubuntu 18.04, which is what our nagios server is running. From syslog on the nsca server: <30>Apr 29 21:35:08 nagios nsca[3977]: Handling the connection... <31>Apr 29 21:35:08 nagios nsca[3977]: Connection from 192.168.15.20 port 58343 <30>Apr 29 21:35:08 nagios nsca[3975]: Handling the connection... <31>Apr 29 21:35:08 nagios nsca[3975]: Connection from 192.168.15.20 port 57831 <30>Apr 29 21:35:08 nagios nsca[3976]: Handling the connection... <31>Apr 29 21:35:08 nagios nsca[3976]: Connection from 192.168.15.20 port 58087 I can try and install nsca 2.9.2 server on a F31 installation and see if nsca-client 2.10.0 will talk to it.
You're right, I did it the wrong way, sorry about that... I did the test again with a 2.9.2 nsca server and a 2.10.0 nsca client. If I feed valid input to send_nsca, it works. $ echo -e 'localhost\ttest\t0\tOK\n' | sudo send_nsca -H localhost 1 data packet(s) sent to host successfully. If I feed an invalid input, it doesn't. $ echo -e 'This is invalid' | sudo send_nsca -H localhost 0 data packet(s) sent to host successfully. The corresponding (redacted) logs with nsca server in debug mode are: - Valid packet (the error about the command file is expected, this box is not running nagios) nsca[26767]: Connection from 127.0.0.1 port 33423 nsca[26767]: Handling the connection... nsca[26767]: Time difference in packet: 0 seconds for host localhost nsca[26767]: SERVICE CHECK -> Host Name: 'localhost', Service Description: 'test', Return Code: '0', Output: 'OK' nsca[26767]: Attempting to write to nagios command pipe nsca[26767]: Command file '/var/spool/nagios/cmd/nagios.cmd' does not exist, attempting to use alternate dump file '/var/spool/nagios/cmd/nsca.dump' for output nsca[26767]: End of connection... - Invalid packet nsca[26739]: Connection from 127.0.0.1 port 28815 nsca[26739]: Handling the connection... nsca[26739]: End of connection... Could that be something in what you feed to send_nsca that works with 2.9.2 but doesn't with 2.10.0 ?
Successful sends from 2.9.2 look like the above in logs. Fails show as: May 4 17:01:23 nagios nsca[15306]: Connection from 192.168.15.7 port 31928 May 4 17:01:23 nagios nsca[15306]: Handling the connection... May 4 17:01:24 nagios nsca[15306]: End of connection... Example data: echo "localhost,0,Host UP at $(date)"|/usr/sbin/send_nsca -H 192.168.15.28 -d ',' Ok, found something new...with 2.10 the delim char works using -d 0x2C instead of -d ',' 2.10: [delim] = Delimiter to use when parsing input (defaults to a tab). Honors hex formatted values, e.g. 0x09. 2.9.2: [delim] = Delimiter to use when parsing input (defaults to a tab) Variations of -d, -d ' -d',' all fail..only hex values now work? Thats a pretty significant difference. Checking Changelog: 2.10 - 2020-04-02 Changed release date to ISO format (yyyy-mm-dd) (John Frickson) Add --quiet mode to send_nsca (Timo Juhani Lindfors) Add --ds to specify block delimiters (for sending multiple checks at once) in send_nsca (Nate Rini) Add legacy_2_7_mode (for sending to nsca 2.7.x) to send_nsca (Adrian Freihofer, Xavier Bachelot) Add foreground mode (Nate Rini) Send errors to stderr, where they belong (Bas Couwenberg / Sean Finney) Fix crashes on ECONNABORTED (Craig Leres) Fix potential buffer overflow (Bas Couwenberg) Spelling fixes (Josh Soref, Lajos Veres, Bas Couwenberg) Removed escape newlines so that long output works (Bryan Heden) No mention...
I filed issue at github https://github.com/NagiosEnterprises/nsca/issues/44 requesting changing the documentation to note REQUIRED use of HEX instead of "honoring" as its current documentation states. This can be closed as its not a bug, but a change in argument usage. Short of Nagios team fixing the documentation, maybe your team can update any documentation? Thanks for your time and troubleshooting help.
Here's the scratch build I wrote about in the upstream bug: https://koji.fedoraproject.org/koji/taskinfo?taskID=44115409
The previous comment was a bit short on details... The scratch build is nsca 2.10.0 with an added patch that drops support for hex formatted delimiters and thus restores the previous behaviour. https://github.com/xavierba/nsca/commit/8ca02b67dc015b81c4d32eff6491346a13b3728f
rpm -qa|grep nsca nsca-client-2.10.0-2.fc31.x86_64 echo "localhost,0,Host UP at now"|/usr/sbin/send_nsca -H 192.168.15.28 -d ',' 1 data packet(s) sent to host successfully. echo "localhost,0,Host UP at now"|/usr/sbin/send_nsca -H 192.168.15.28 -d 0x2c 0 data packet(s) sent to host successfully. Revert seems to be working. ########################## The CHANGELOG for 2.10 mentions "Send errors to stderr, where they belong (Bas Couwenberg / Sean Finney)" Return status for the command that results with "0 data packet(s) sent to host successfully." is 0. Is that intentional, if so do I need to file a separate bug report? root@daw3:~# echo "localhost,0,Host UP at now"|/usr/sbin/send_nsca -H 192.168.15.28 -d 0x2c 0 data packet(s) sent to host successfully. root@daw3:~# echo $? 0
Thanks for testing. I'll make a real build for all supported releases asap. And yes, it looks like you may have found another bug, although with way less damage potential than the first one. Please file it upstream.
FEDORA-2020-5136a26843 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-5136a26843
FEDORA-2020-be02512922 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-be02512922
FEDORA-EPEL-2020-55ca7ea1da has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-55ca7ea1da
FEDORA-EPEL-2020-a359910824 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a359910824
FEDORA-EPEL-2020-fc472cc3f4 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fc472cc3f4
FEDORA-2020-267df5d597 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-267df5d597
(In reply to Xavier Bachelot from comment #10) > Thanks for testing. I'll make a real build for all supported releases asap. > > And yes, it looks like you may have found another bug, although with way > less damage potential than the first one. Please file it upstream. Filed as https://github.com/NagiosEnterprises/nsca/issues/45 Thanks
FEDORA-2020-267df5d597 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-267df5d597` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-267df5d597 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-5136a26843 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-5136a26843` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-5136a26843 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-fc472cc3f4 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-fc472cc3f4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-be02512922 has been pushed to the Fedora 30 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-be02512922` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-be02512922 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-55ca7ea1da has been pushed to the Fedora EPEL 6 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-55ca7ea1da See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2020-a359910824 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-a359910824 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-5136a26843 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-267df5d597 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-be02512922 has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-fc472cc3f4 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-55ca7ea1da has been pushed to the Fedora EPEL 6 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2020-a359910824 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report.