I'm having difficulty with output from a custom SSH script that I'm running on a Linux machine. The script outputs a time value - NTP offset in microseconds - as a number (1, 2, 15, 26, etc.). I'd like to capture that number and graph it. The script is written in perl, however I run it in bash for PRTG as:
#!/bin/bash
OFFSET="$(perl GetNTPoffset.pl)"
echo "0:${OFFSET}:OK"
I've also tried it without the quotes
#!/bin/bash
OFFSET="$(perl GetNTPoffset.pl)"
echo 0:${OFFSET}:OK
If I log into the Linux machine with the PRTG user account, navigate to the /var/prtg/scripts folder and run ./GetNRPoffset.sh I get a return like 0:17:OK. It's this '17' value that I'd like to graph.
This seems to fit within what PRTG is looking for returncode:value:message, however in PRTG however, I get error P129: "Either the script was not runable, or the output could not be parsed (:OK)" It doesn't seem to matter what comes after the last colon (the 'message') - whatever it is generates an error.
Any suggestions?
Article Comments
I believe that the script on the Linux device is running properly. I can shell into it (using PuTTY) as the user the PRTG user and run the script. I get an output of 0:<the value I want>:OK . From what I've read in the documentation, this is the correct formatting for the echo response - returncode:value:message.
The error from PRTG says that it can't parse the 'OK' part of the response. If I alter the script to return 0:<value>:ABC123, then within 60 seconds, PRTG says it can't parse 'ABC123'. So, I'm confident that the script is running, and the output is being picked up by PRTG. The problem seems to be that it doesn't like or understand the third part of the script output.
I tried altering the script to output 0:<value> (leaving the message part off) and got an PE132 error 'response not well formed'. When I try simply echoing the value that I'm after, then the error is 'Received empty SSH response'.
Script is running, output is in the format stated in the documentation, but PRTG isn't liking it for some reason.
Jun, 2018 - Permalink
May I ask what shell is running on the target host? Could be an encoding issue...
Kind regards,
Stephan Linke, Tech Support Team
Jun, 2018 - Permalink
Running it in bash. The target hose is a Raspberry Pi with a GPS board serving as my NTP server. The GPS is going in and out of sync, and I'm trying to plot the microsecond offset to see when this is happening and for how long, and if those to factors relate to anything else. I'm using this script in Perl to get the clock offset:
$ntp_str = `ntpq -c rv $ARGV[0]`; # execute "ntpq -c rv <node>"
$val = (split(/\,/,$ntp_str))[20]; # get the offset string
$val =~ s/offset=//i; # remove the "offset="
$val = int (1000 * $val); # convert to microseconds
$nval = $val; # prepare the negative value
if ($val < 0){
$nval = -$nval; # make the value positive
$val = 0; # ensure zero return for the positive
} else {
$nval = 0; # ensure zero return for the negative
}
print "$val\n"; # output
However, I'm aware that PRTG can't/won't run a perl script, so I use this shell script to execute the perl one, and produce the three values in the output line:
#!/bin/bash
OFFSET="$(perl GetNTPoffset.pl)"
echo "0:${OFFSET}:OK"
Is mentioned, I'm pretty sure that PRTG is able to execute the script, as any value I put in the third segment of the output line (as in replace the 'OK' with some other text) shows up verbatim in the error code on my PRTG server.
I appreciate your efforts in diagnosing this.
Jun, 2018 - Permalink
Using the HTTP Push Data Advanced sensor might be a bit more purposeful here. You basically run the script in cron and send the output to PRTG (so PRTG is not doing the executional part). The standard version of the sensor, which only has one channel) might already be sufficient.
Kind regards,
Stephan Linke, Tech Support Team
Jun, 2018 - Permalink
Did you already try the privilege elevation in the SSH Credentials section of the device? Using Run the command as another user using 'sudo' (with password) might work. Don't forget to add the corresponding user below when activating this setting.
Kind regards,
Stephan Linke, Tech Support Team
Jun, 2018 - Permalink