v1.2.5, Wed Dec 4 04:54:23 UTC 1996
Oops. Let's not try to write the pid file unless one was specified.
v1.2.4, Wed Dec 4 01:19:35 UTC 1996
Added pid file option (-f, specify only once) and a simple option
parsing loop. The pid file is created just before the parent process
settles down to wait for child process completion, and is deleted
during signal handling.
If the open or close of the pid file is unsuccessful, we raise
SIGHUP, which hopefully will kill the children as well.
v1.1.6, Thu Aug 1 04:36:39 UTC 1996
Lots of cleanup. Added a verbose option (-v, only valid as first
v1.1.0, Wed Jul 31 16:28:01 UTC 1996
Running the monitor process as a child and running the execvp()
under the parent process did not seem to allow us to properly keep
track of terminations. It was my thought originally we wouldn't
need to, just kill things when the parent died. But, what if the
parent starts up another child? The whole point of using a new
process group was to allow us to kill
*everything* when time's up, but not kill anything *before*.
So, now we're using a more conventional setup. We're the mama. One
of those horrid mamas in the B movies who turns into an axe
murderer. If we get our timeout alarm, we kill all our children
(everyone in the process group). Meanwhile, we sit around doing
waitpid() on the process group, looping until all our children are
dead and we get an ECHILD. Then we make double-sure by killing
everyone all over again. We'll probably get life with no
possibility of parole.
Yes, I need to add stderr messages and better parsing, but not for
now, I'm way too busy. :)
Meanwhile, my persistent problem (piping to a file from a stopafter-
initiated exec worked, piping to a program did not) appears to have
been due to my neglecting to include the include for <string.h>.
GCC 2.7.2 quietly resolves the library reference without providing
the headers for the functions, letting the parameters default to
(int) or some such. I know I put -Wall in that source. Thank FSF
for that bit of silliness.
Hopefully the remaining buglets are sorted out, if not there'll be
another release as soon as I try to use the program for something
and can't. You can hasten this process by emailing any problem
reports to me at:
In fact, you could even write to tell me how much you enjoyed the
program. If you ask nicely, I'll give you an address where you can
send me money. :)