Nagios/NRPE VMS client run errors on Integrity with SSL 1.4

[Denzil Briggs]

Hi all,

I seem to have problems building the Nagios VMS client on IA64 with VMS 8.3-1H1 to which I have found the odd other post about with similar problems but with no solution that I can find. We managed to get check_nrpe working by converting the image from Alpha using AEST and creating file copies of the images SYS$COMMON:[SYSLIB]SSL$LIBSSL_SHR32.EXE to SYS$COMMON:[SYSLIB]SSL$LIBSSL_SHR32_AV.EXE and SYS$COMMON:[SYSLIB]SSL$LIBCRYPTO_SHR32.EXE to SYS$COMMON:[SYSLIB]SSL$LIBCRYPTO_SHR32_AV.EXE.

This worked fine with SSL 1.3, however, we now have a site which has updated to SSL 1.4 and converting the AXP image build under SSL 1.4 seems to cause the checks to fail about 35% of the time with "CHECK_NRPE: Received 0 bytes from daemon. Check the remote server logs for error messages." and runs and returns successfully the remainder (about 65%) of the time. This is just running the check while logged onto the VMS server.

Using the rebuild and recompiled version still on Integrity fails with the

0: INFO: SSL/TLS initialized. All network traffic will be encrypted.
20: Connection from 172.18.3.180 port 17694735
20: Host address checks out ok
20: Handling the connection...
20: Host is asking for command 'check_test' to be run...
20: Running command: @nrpe$scripts:check_test.com
%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=0000FFFF00000000, PC=FFFFFFFF84C22A70, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image module routine line rel PC abs PC
DECC$SHR C$STRLEN strlen 3694 0000000000000180 FFFFFFFF84C22A70
DECC$SHR C$TXDOPRINT convert_spec 42870 000000000000BED2 FFFFFFFF84D70A02
DECC$SHR C$TXDOPRINT decc$$txdoprint
43482 000000000000D772 FFFFFFFF84D722A2
DECC$SHR C$TXDOPRINT sprintf 43827 0000000000012282 FFFFFFFF84D76DB2
nrpe_aux CUSTOM syslog 1866 0000000000000132 0000000000036542
nrpe_aux NRPE_AUX handle_connection 60231 0000000000002D92 0000000000032D92
nrpe_aux NRPE_AUX wait_for_connections
60039 0000000000002282 0000000000032282
nrpe_aux NRPE_AUX main 59720 0000000000000CA2 0000000000030CA2
nrpe_aux NRPE_AUX __main 59616 0000000000000232 0000000000030232
0 FFFFFFFF80BB0F72 FFFFFFFF80BB0F72
DCL 0 000000000006BAF2 000000007AB8FAF2
%TRACE-I-END, end of TRACE stack dump

Any ideas?? Like I mentioned, AEST of the AXP image compiled and linked with SSL 1.3 works.

Any help would be much appreciated.

Thanks and regards,
Denzil

[Hoff · Accepted solution]

Google is your friend.

http://h30499.www3.hp.com/t5/Networking/Nagios-NRPE-agent-on-IA64-VMS-8-31h1/m-p/4703662#M9498

[Denzil Briggs]

Thanks Hoff for the reply. I had already checked out that link prior to posting but I wasn't getting anything conclusive from it. I will go back and re-check it to see if I missed anything.

It's interesting how the AEST version of it fails about 1/3 of the time though.

Cheers
Denzil

[Hoff]

You don't seem particularly inclined to debugging this case yourself (and for whatever reason that might be), so your options are limited to requesting debugging help within your organization and from outside, or paying for debugging help, convincing HP to debug this on your behalf and/or to add support NRPE, or switching to a different implementation or different monitor.

For testing purposes, I'd definitely keep SSL shut off.

As for debugging this yourself...

The sprintf call somewhere around here:

nrpe_aux CUSTOM syslog 1866 0000000000000132 0000000000036542

is the immediate trigger. The proximate cause will require some digging in the source code.

Based solely on the stackdump, the trigger could be an uninitialized structure pointer.

And if you want to pursue this here, you'll want to identify which of the NRPE ports you're working with; the source URL and the version. (I see several that are available, as well as some bug reports of crashes in this general area of various of the ports.)

[Denzil Briggs]

Thanks again Hoff. Will look into that. Just wanted to see if anyone had come across the same symptoms in the few months since the post you highlighted.

Cheers