Bug 497847 - need send_nsca & nsca to be customized to send/receive packets larger than default
Summary: need send_nsca & nsca to be customized to send/receive packets larger than d...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: nsca
Version: el5
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Wart
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: ActualBug
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-27 14:42 UTC by Daniel Virely
Modified: 2017-04-06 10:38 UTC (History)
3 users (show)

Fixed In Version: 2.7.2-7.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-06 10:38:15 UTC


Attachments (Terms of Use)
Increase max plugin output size (323 bytes, patch)
2009-07-17 14:18 UTC, Xavier Bachelot
no flags Details | Diff

Description Daniel Virely 2009-04-27 14:42:37 UTC
When send-nsca send packats, message are truncated to a size ~ 525 chars.

We have the version of Nagios nagios-2.12-5.el5   that has been released with a correction on the size of the service_message struct (8376 bytes)

Is it possible to update the send_nsca and nsca functions in order to be able to exchange larger messages than the one authorized with default settings  and to manage coherency with the nagios extended msg processing?



 
thanks
Best Regards
Daniel



in nagios.log
[1240836794] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;toto;squid;0;c'est cool | ysquid.version=2.6 cache.req_hit_ratio=1.2 cache.req_mem_hit_ratio=100.0 cache.req_disk_hit_ratio=0.0 cache.mean_object_size=70.91 squid.ds_size=177744 cache.store_entries=13115 cache.total_mem_objects=1904 cache.hot_objects=1903 cache.on_disk_objects=12996 squid.fd_percent=0.036 client_http.requests=1.369999 client_http.hits=0.016667 client_http.errors=0.1240836793 client_http.kbytes_in=0.800000 client_http.kbytes_out=98.586618 client_http.all_median_svc_time=0.070143 client_http.miss_median_


expected message to be sent:

localhost       squid   0       c'est cool | ysquid.version=2.6 cache.req_hit_ratio=1.2 cache.req_mem_hit_ratio=100.0 cache.req_disk_hit_ratio=0.0 cache.mean_object_size=70.91 squid.ds_size=177744 cache.store_entries=13115 cache.total_mem_objects=1904 cache.hot_objects=1903 cache.on_disk_objects=12996 squid.fd_percent=0.036 client_http.requests=1.369999 client_http.hits=0.016667 client_http.errors=0.1240843298 client_http.kbytes_in=0.800000 client_http.kbytes_out=98.586618 client_http.all_median_svc_time=0.070143 client_http.miss_median_svc_time=0.070143 client_http.nm_median_svc_time=0.000000 client_http.nh_median_svc_time=0.000000 client_http.hit_median_svc_time=0.000000 server_http.requests=1.339999 server_http.errors=0.000000 server_http.kbytes_in=98.279952 server_http.kbytes_out=0.903333 squid.page_faults=0.000000 cache.swap_outs=1.299999 cache.swap_ins=0.026667 squid.abortedreq=0.000000 squid.cpu_percent=0.389274 cache.cachedir0.store_dir_max_size=1024000 cache.cachedir0.store_dir_size=921532 cache.cachedir0.max_obj_age=360 cache.max_obj_age=360 parent_servers.tomcat1

Comment 1 Daniel Virely 2009-07-16 07:18:07 UTC
hello

any update on this request please ?

thanks by advance

Rgds
Daniel

Comment 2 Xavier Bachelot 2009-07-17 14:18:34 UTC
Created attachment 354153 [details]
Increase max plugin output size

Comment 3 Xavier Bachelot 2009-07-17 14:20:28 UTC
This is related to https://bugzilla.redhat.com/show_bug.cgi?id=469198, where the max output size increase was backported from nagios cvs.

Attached patch increase the max size to 8192 in nsca, to match what's in nagios.

Wart, are you ok with the patch ?

Comment 4 Wart 2009-07-19 17:20:29 UTC
This looks fine to me.  Go ahead and commit it to CVS and rebuild.

Comment 5 Fedora Update System 2009-07-20 21:29:28 UTC
nsca-2.7.2-7.el4 has been submitted as an update for Fedora EPEL 4.
http://admin.fedoraproject.org/updates/nsca-2.7.2-7.el4

Comment 6 Fedora Update System 2009-07-20 21:30:36 UTC
nsca-2.7.2-7.el5 has been submitted as an update for Fedora EPEL 5.
http://admin.fedoraproject.org/updates/nsca-2.7.2-7.el5

Comment 7 Fedora Update System 2009-07-21 20:48:57 UTC
nsca-2.7.2-7.el4 has been pushed to the Fedora EPEL 4 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nsca'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-4/FEDORA-EPEL-2009-0094

Comment 8 Fedora Update System 2009-07-21 20:49:13 UTC
nsca-2.7.2-7.el5 has been pushed to the Fedora EPEL 5 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nsca'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/EL-5/FEDORA-EPEL-2009-0108

Comment 9 Fedora Update System 2009-08-05 17:20:33 UTC
nsca-2.7.2-7.el4 has been pushed to the Fedora EPEL 4 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 10 Fedora Update System 2009-08-05 17:21:54 UTC
nsca-2.7.2-7.el5 has been pushed to the Fedora EPEL 5 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 11 Thomas Rast 2009-08-12 12:39:51 UTC
I just had a rather interesting expedition through TFS, and it turns out send_nsca and nsca always work on a static packet whose size is determined at compile time. They send/receive this packet in full, even if most of it is garbage, and compute the CRC32 over the whole of this packet.

This boils down to
1. this patch causes a lot of network traffic for people who don't need it
and more importantly
2. if client and server were compiled with a different MAX_PLUGINOUTPUT_LENGTH, they won't be able to cooperate because the CRC32 will always be wrong

Blame upstream for (2), but IMVHO this variable cannot be changed. Not unilaterally at least, and definitely not without warning everyone in the changelog that their setup just so happened to become incompatible with every other distribution's nagios.

Comment 12 Daniel Virely 2009-08-12 12:55:39 UTC
Hello


Can packets sent over the network, be limited to the "useful length" and CRC calculated on that length? ( MAX_PLUGINOUTPUT_LENGTH would be only the max exchangeable size) so that using the new version on the nagios side, would be transparent  of older agents?


The use of metrics collection in the nagios & send_nsca environnent rapidly reach the max size of the send-nsca packets exchanged over the network. The side effect of the limitation is that there is no return code when packets are truncated when size exceeds 525 char.



Thanks
Kind Regards

Daniel

Comment 13 Thomas Rast 2009-08-12 13:38:12 UTC
I *think* it should be possible to always pad the packet (and probably it would be better to use nulls instead of garbage so we don't give away old memory) to the 525 bytes used on older versions, but allow a larger transmission. That way, if the packet is shorter it's still compatible and will be truncated as before; if it's longer it'll still be cut off.

Of course I haven't stared at the code long enough to figure out whether it's possible to determine packet length simply by reading until data is exhausted. If it's not, we'd need some kind of way to include a length field that doesn't break compatibility.

BTW, I just noticed that nagios.org's 3.x changelog says they did some changes to the MAX_PLUGINOUTPUT_LENGTH too. So either they have a better solution, or they don't care much about compatibility either. (The 2.x changelogs aren't online so I can't check when they started doing that.)

Comment 14 Xavier Bachelot 2009-08-28 10:43:30 UTC
Upstream bug report : http://tracker.nagios.org/view.php?id=78

I think the best to do for now is to revert the patch and push a new version. Wart, Daniel, Thomas, what do you think ?

Comment 15 Wart 2009-09-03 15:50:06 UTC
I agree.  Let's remove the patch and rebuild.   The original premise of this bug report, that the increased message size is compatible with the latest Nagios in epel5, was incorrect.

If Nagios for epel5 ever really changes to support the larger size, then we can come back to this patch.

Comment 16 Fedora End Of Life 2017-04-06 10:38:15 UTC
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5
is no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora
or Fedora EPEL, please feel free to reopen this bug against that version. If
you are unable to reopen this bug, please file a new report against the current
release. If you experience problems, please add a comment to this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.