(RADIATOR) recommended method to "event notify" radiator to a restart/reread

[Phil Freed]

The question was -- how to force a reload of Radiator when the config file 
or config DB changes.

I like and use the SSH method recommended by Stefan.  But there are times 
when you want someone who doesn't have adequate permissions to start/stop 
Radiator to be able to signal a reload.  A web server process is probably 
the most common example of this.  Here are some tricks you can use:

1)  If a particular file exists in a particular directory, I will reload 
the server.  That means that a reload can even be triggered via ftp or 
scp.  A simple cron script will do the job:

    FILE=/var/tmp/reload.now
    if [ -f $FILE ]; then

       # keep a record of restarts, if you like
       mv $FILE $FILE.`date '+%y%m%d-%H%M%S'`

       # Check the config file integrity, then....
       pkill -HUP radiator
    fi

(For more notes about pkill, see the script below.)  This


2)  A cron script that watches the relevant configuration files, and 
automatically signals Radiator.  With a little more tweaking (I wanted to 
keep this script simple), you could change this script to only send the 
signal if the changes are more than (say) 60 minutes old.  Or, it could 
just send a reminder email.

This script is long -- but it's mostly documentation.  And you can use it 
to monitor for changes in any files for any purpose.


#!/sbin/sh
#
# radhup.sh -- send HUP signal to radiator if any files have changed
#
# This script will see if any files have been changed since the last time
# it was run.  It does this by:
#   1) creating flag file each time the script is run
#   2) checking to see if any files are newer than the
#      flag file that was created the last time the script was run
#
# If you want to monitor a DB for changes (as opposed to flat files), you
# will something slightly fancier, though the priniciple is the same.  Just
# keep a timestamp-of-last-change on each record, and create some
# special flag records to indicate the time of last review (or time of last
# restart).
#
#
# If you want to force a restart, run this script with a "-f" flag
#
#
# This script should work under ksh, bash, or sh.  If you are using
# an old shell, you may need to redefine TEST as noted below.
#

# Created by Phil Freed
#
# Modification history
# 2004-07-09 ptf  Initial revision
#

##########################################################################

###
#
# Location of the flag files
#
FLAGFILE=/var/tmp/radreset.flag
TEMPFLAG=$FLAGFILE.tmp

###
#
# Did user specify "-f" ?
#
FORCE=no
[ "$1" = -f ] && FORCE=yes

###
#
# List of files to check
#
FILES="/usr/local/etc/someinclude.inc /etc/radiator.conf /some/other/file"


###
#
# On many Unix boxes, there's a util called pkill which lets you
# send signals to a process by its name.  If you don't have this,
# you'll want to define PIDFILE here.
#
# PIDFILE=/where/is/my/radiator/pidfile


###
#
# Many systems have a test executable that is smarter than the
# test built into their shell.  If you get something like
#    test: unknown operator -nt
# when you run this script, change the line below to something like
#    TEST=/usr/bin/test
#
TEST=test


###
#
# Just in case this is the first time we have run this script:
#
[ ! -f $FLAGFILE ] && touch $FLAGFILE


#################################################################
#################################################################
#
# Now to get down to business.
#

##
#
# 1) Force a reload?
#
RELOAD=no
[ $FORCE = yes ] && RELOAD=yes


##
#
# 2) create a flag file.  We do this at the beginning instead of the end, to
#     ensure that we don't miss any changes that might be made while the
#     script is running.
#
touch $TEMPFLAG

##
#
# 3) Anything changed since the last time?
#
for f in $FILES
do
   $TEST $f -nt $FLAGFILE && RELOAD=yes
done


##
#
# 4) Save the new flag file for the next time we run
#
mv $TEMPFLAG $FLAGFILE


##
#
# Finally -- this is the purpose of the whole script.
#
# If you don't have pkill on your system (or the equivalent),
# you can build it in the shell.  (You'll probably find examples
# in your init.d directory).  Or, you can just use the classic
#   kill -HUP `cat /where/is/my/pidfile`
#
# You could also send an email notification that radius needs to be
# restarted:
#
# if [ $FORCE = no ]; then
#   # send mail unless the user is running this script manually with "-f"
#   echo Do it now | mail -s "Restart radiator" radadmin at mydomain.com
# fi
#

if [ $RELOAD = yes ]; then
    # Just in case the file is being written while the script is running --
    # we pause a bit to allow the write to finish.
    sleep 2

    # Check the config file integrity, then:
    pkill -HUP radiator
fi




At 06:49 PM 7/7/2004, Hugh Irvine wrote:

>Hello Tariq -
>
>Interesting question - can anyone else on the list offer any suggestions?
>
>And in answer to your question, no there is no configuration file watching 
>in Radiator.
>
>regards
>
>Hugh
>
>
>On 7 Jul 2004, at 20:50, Tariq Rashid wrote:
>
>>
>>hi - i'm sire many of you have come across this issue before, and its not
>>unique to radiator either.
>>
>>the radius clients can be kept in the radius.cfg file (as <Client, 1.2.3.4>
>>for example) or in a database, and i'm sure they can be kept in other
>>locations too ...
>>
>>however, when an external system updates this list, either by rewritring the
>>radius.cfg file, or updating an included file, or by adding entries to or
>>removing entries from an sqlclientlist database ... a running radiator does
>>not take account of the changes until the radiator server instances if
>>restarted or sent a -HUP signal.
>>
>>is there a recommended way to do this from remote locations? that is, these
>>event notification originate on different machines to those which are
>>actually running the server instances.
>>
>>i want to avoid additional custom written "event notification and restart"
>>software as it adds points of weakness into an otherwise solid system, and
>>also requires additional support. (its is for this reason that i want to
>>avoid external sql databases too, as that requires additional support and a
>>more complex set of failure points)
>>
>>a not-so-good solution is to perhaps ask radiator to restart/reHUP
>>periodically. i don't think there is a "file-watching" mechanism in
>>radiator?
>>
>>tariq

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.