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 ssh monitor
Votes:
0
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 :)
Votes:
0
Bummer..... was hoping not to have to do that.... :-( if only the response could be exteded to a max of 5 mins....
Votes:
0
No way of optimizing it? What does it actually do?
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.
Votes:
0
ok, so here's how I overcame my problem...
- the actual tripwire --check take anywhere from 1-5 minutes to run.
- I split my script into 2 parts.
- 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 :)
Votes:
0
@sammiam if you like, you could create a seperate script post for your work - maybe it'll help other customers as well :)
Votes:
0
Thanks... now that I know how to designate script snippets... I'll keep that in mind.. thanks again.
Add comment