Xymon Mailing List Archive search

how to learn what is crashing my rrd handler?

list John Thurston
Tue, 02 Sep 2014 09:25:54 -0800
Message-Id: <user-b800395e7b11@xymon.invalid>

On 8/27/2014 4:08 PM, Jeremy Laidman wrote:
On 28 August 2014 05:10, John Thurston <user-ce4d79d99bab@xymon.invalid
<mailto:user-ce4d79d99bab@xymon.invalid>> wrote:

    And I think the thing which ran off the end of the string was the
    debug process :p I'm still looking at source (and my C is very, very
    bad), but I suspect the debug print process is choking on the
    absence of an attribute in the procols.cfg

The "Sendtext" line has only the date string, so that's probably the
data that caused the crash.  I'm guessing you haven't re-defined the
protocols.cfg entry for [telnet], so I'm struggling to imagine where the
bad data could have come from.  But perhaps worth removing the "telnet"
test for that host and see if the crashing stops.
The telnet test is defined for only one host (out of 600) in my hosts.cfg, and it is never the host identified in the remnants of the crash.

It looks like (with 4.3.17), in debug mode, lines 324-340 of netservices.c dump the currently defined service list. They correctly send the contents of the service list for:
  ftp
  ftps
  ssh
  ssh1
  ssh2
and they print the name for:
  telent
and then they die when they are asked to print the Sendtext for "telnet"

My protocols.cfg contains:
[ssh|ssh1|ssh2]
   send "SSH-2.0-OpenSSH_4.1\r\n"
   expect "SSH"
   options banner
   port 22

[telnet]
   options banner,telnet
   port 23
There is no "send" attribute defined. I don't think there has ever been such an attribute defined. The files in the source directories (~/xymon-4.3.17/xymonnet/protocols.cfg) do not contain a "send" attribute. The "send" attribute is defined for most, but not all of the other protocols in the file.

Has anyone running 4.3.17 successfully run their rrd_data handler in debug mode? I don't think it can do it.

This looks to me like a code defect, wherein the dump_tcp_services function is not checking for a null string prior to finding its length and passing the information to dbgprintf. I'm just a lowly sysadmin whose last exposure to C was more than 25 years ago. Can someone with some C experience confirm or deny my hypothesis?

-- 
    Do things because you should, not just because you can.

John Thurston    XXX-XXX-XXXX
user-ce4d79d99bab@xymon.invalid
Enterprise Technology Services
Department of Administration
State of Alaska