Trapping a kill command sent to a script and using it to send an EOF to a subprocess before killing

I originally had a script written in pure shell that I used to parse logs in real time and create a pipe delimited file that only contained errors. It worked but it was using a lot of memory (still not clear on why). I originally got around this by writing a wrapper for the script that ran on cron and periodically killed the script and started a new instance. This worked for a while, but was still too heavy. So, I rewrote the parsing logic in awk instead of shell and the memory and CPU utilization dropped completely.

So now, I have this script running, but every 15 minutes the cronjob kills it and starts a new instance. What I want to do now is have my awk section of the script building out arrays, and when the cron kicks in, it sends an EOF to the awk so it can dump it's info into a separate file before it's killed and a new instance is started. Below is my code. What I want to do is add blocks to the awk section that creates arrays, and then add an end block to it that dumps the values from those arrays into a file. So, I need to trap the kill command and then have it send an EOF to awk, then kill the script and start a new instance.

#!/bin/bash
######################################################
# Program:      logGen.sh
# Date Created: 22 Aug 2012
# Description:  parses the manager log in real time into daily error files
# Date Updated: 27 Nov 2013
#		|_moved all data parsing logic to awk instead of shell
#		|_Need to analyze memory/CPU usage and consider changing
#		|_restart frequency in cron
# Developer:    Redacted (Senior Support Engineer)
######################################################
#Prefix for pid file
pidPrefix="logGen"
#output direcory
outDir="/opt/Redacted/logs/allerrors/"
#Simple function to see if running on primary
checkPrime ()
{
  if /sbin/ifconfig eth0:0|/bin/grep -wq inet;then isPrime=1;else isPrime=0;fi
}


#function to kill previous instances of this script
killScript ()
{
  /usr/bin/find /var/run -name "${pidPrefix}.*.pid" |while read pidFile;do
    if [[  "${pidFile}" != "/var/run/${pidPrefix}.${$}.pid" ]];then
      /bin/kill -- -$(/bin/cat ${pidFile})
      /bin/rm ${pidFile}
    fi
  done
}


#Check to see if primary
#If so, kill any previous instance and start log parsing
#If not, just kill leftover running processes

checkPrime
if [[ "${isPrime}" -eq 1 ]];then
  echo "$$" > /var/run/${pidPrefix}.$$.pid
  killScript
  tail -F -n0 /opt/Fabrix.TV/logs/manager_proxy.log|awk -v dir=$outDir '{OFS="|"}
{
  if ($3 == "E")
  {
    file="allerrors."$1".log"
    gsub("/",".",file)
    if ($9 ~ /@/)
      print $1,$2,$8,$9,substr($0, index($0,$10)) >> dir file
    else {if ($8 !~ /@/)
      print $1,$2,$7,"NULL",substr($0, index($0,$8)) >> dir file
    }
    fflush(stdout);
  }
}'
else
  killScript
  exit 0
fi

You need a source of active subprocesses. ptree is available in Solaris, for example.
Linux has /proc/[pid]/ppid. pstree uses this to draw ascii "graphics".

So what OS?

The bash trap statement you want: a function + two trap statements

zap()  # some method of getting all active children/grandchildren, etc. Assume a file
{
    # turn off trap
    trap - SIGTERM 
    # kill the kids
    me=$$
    while read pid
    do
        if [ $$ -ne  $pid ] ; then   # if active kill the process
           kill -0 $pid && kill $pid
        fi
   done < a_file_with_childrens_pids
}

# enable zap
trap ' zap ' SIGTERM

Bash kill builtin also supports using jobs, so you can use the jobs command to list active children - if they do not have descendants.

Notice there is a very small possibility of a race condition when several SIGTERM (default signal for kill) signals are received at once. In that case zap() will not complete.

You need a way to enumerate children. You can remember their pids in an array or a file or some other object maybe.
If one of the children is "extinct", you did not rembmer that, and the pid is being used by some hapless process - then you have problems. Another race condition. Especially if this stuff runs as root. On linux or solaris you can evaluate the correctness of the pid by querying proc or getting the uid. - maybe like what exe is the potential kid running. If root is running zap() and you run, be sure to keep a tight handle on current active descendant processes. Or you could clobber your own payroll job.