What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

custom ssh monitor

Votes:

0

We have a custom script for our unix servers (tripwire) that we run every 6 hours. Unfortunately the scripts takes about 3 minutes to completely run. The problem is with the shell timeout, I can only enter a max of 60 seconds... we need to be able to increase this for this particular monitor to a minimum of 2 minutes... HELP !!!

custom-monitor shell timeout

Created on Mar 26, 2015 7:02:59 PM



8 Replies

Votes:

0

Nope, doesn't work. Even when modifying the configuration manually with an editor, PRTG will overwrite it. You could ouput the results to a text file and run it via cronjob. Just use PRTG to check the result of the text file with a different script :)

Created on Mar 27, 2015 2:34:56 PM by  Stephan Linke [Paessler Support]



Votes:

0

Bummer..... was hoping not to have to do that.... :-( if only the response could be exteded to a max of 5 mins....

Created on Mar 27, 2015 2:39:22 PM



Votes:

0

No way of optimizing it? What does it actually do?

Created on Mar 27, 2015 2:59:51 PM by  Stephan Linke [Paessler Support]



Votes:

0

Unfortunately I've tried all the unix tricks.... ie nice -20, bindprocess, etc... I'm working on a workaround... and that will work... the actual program itself is "tripwire --check" which performs a system check on all configured binaries, directories, etc on a unix server, and reports if there are any violations, so depending on how many files/directories, etc have been configured, I've seen this puppy run for as long as 4 minutes.... my workaround will work, I'll publish it once I've completed it.

Created on Mar 27, 2015 3:02:48 PM



Votes:

0

ok, so here's how I overcame my problem...

  1. the actual tripwire --check take anywhere from 1-5 minutes to run.
  2. I split my script into 2 parts.
  3. The first script simply reads the saved value from the last time that
    tripwire --check was run, and reports those results back to prtg. If it has been more than 6 hours since the last tripwire --check was run, it also kicks off a "nohup" background script that performs the tripwire --check, which also updates the saved value for the next iteration of PRTG running script # 1.

Here's script 1 - that is custom run from PRTG:

$ cat tripwire.ksh

#!/bin/ksh
#
# this will run the tripwire --check, and look for "No violations."  if not found, then it will
# raise an alert
#
rm /etc/tripwire/report/* 2>/dev/null

# OK, since PRTG expects a response back within 60 seconds, and the actual tripwire check mostlikely
# will take longer than this to run... do this script this way as a work around:
#
#  read the variable /tmp/tripwire.results, which contains the timestame of the last time
#  that tripwire check ran.  If the check has not run for 6 hours;
#
#   1) go ahead and fire up the check process as a nohup and background process.
#   2) send the last results value.
#   3) the next cycle of this script will then read the updated value from the check, and
#      report this back to PRTG
#
#  so, regardless of the frequency at which PRTG calls this monitor, the value from tripwire
#  being updaes is solely controled by the value that DSECS is compared to.  Currently this
#  is set to every 6 hours.   NOTE: for testing purposes, this script can be run with any
#  value given to arg 1.  If there is a value, then it will force this script to kick off the
#  background running of tripwire for updating the value.

if [ ! -e /tmp/tripwire.results ]
then
   SECS=`date "+%s"`
   print "$SECS 0:0:OK" > /tmp/tripwire.results
fi

CSECS=`date "+%s"`
read SECS VALUE < /tmp/tripwire.results

# see if it's been longer than 6 hours since the last tripwire check run

let DSECS=$CSECS-$SECS

# 21600 = 6 hours , so if it has been more than 6 hours, run the tripewire in background
#                   via the nohup operation, go ahead and post to PRTG the last value
#                   the next iteration of this monitor will pick up the updated value
#                   and post that to PRTG

if [[ $DSECS -gt 21600 || "$1" != "" ]]
then
   # we need to fire up the check process in background
   nohup /var/prtg/scripts/tripwire.check.ksh >/dev/null 2>&1 &
fi
print "$VALUE"
exit 0

Here's script # 2
$ cat tripwire.check.ksh

#!/bin/ksh

# this will run the tripwire check, and post results in /tmp/tripwire.results
# format of the contents of the results file is:
#   seconds x:x:nn
#
#  seconds is the elapsed seconds from epoch
#
#  x:x:x:nn   is the required string posted to PRTG
#   this program will post one of the two:
#
#   0:0:OK      -   means that no violations were found
#   2:2:VIOLATION - means that violations wer found and that an alert needs to be raised
#

rm /etc/tripwire/report/* /tmp/PRTG.tripwire.report 2>/dev/null
readstart=0
/opt/freeware/sbin/tripwire --check | while read line
do
   if [ $readstart -eq 0 ]
   then
      rsvp=`print "$line" | grep "Object Summary:"`
      if [ "$rsvp" != "" ]
      then
         readstart=1
      fi
   else
      print "$line" >> /tmp/PRTG.tripwire.report
   fi
done
#
# now look for the string "No violations."
#
violations=`grep "No violations." /tmp/PRTG.tripwire.report`
timestamp=`date "+%s"`
if [ "$violations" != "" ]
then
   print "$timestamp 0:0:OK" > /tmp/tripwire.results
else
   print "$timestamp 2:2:VIOLATIONS" > /tmp/tripwire.results
fi
exit 0

Created on Mar 27, 2015 6:55:19 PM

Last change on Mar 30, 2015 2:20:35 PM by  Stephan Linke [Paessler Support]



Votes:

0

Thanks for posting your solution to this! Tripwire might indeed take a while to run.
Glad that it works now.

P.S.: I've edited your post so it's displayed properly. If you like,
have a look at the various markup options :)

Created on Mar 30, 2015 2:22:19 PM by  Stephan Linke [Paessler Support]



Votes:

0

@sammiam if you like, you could create a seperate script post for your work - maybe it'll help other customers as well :)

Created on Mar 30, 2015 2:27:48 PM by  Stephan Linke [Paessler Support]



Votes:

0

Thanks... now that I know how to designate script snippets... I'll keep that in mind.. thanks again.

Created on Mar 30, 2015 2:53:44 PM




Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.