First of all, I'd like to say thanks to Michael Barton for always
seeming to have the answer when I need it :D Secondly, I've put a
modified version of the code chunk he included w/ his last email, but
instead of raising a signal upon a default value in the switch statement
for fork(), I put a function I wrote for calling a shell script I wrote
that would grab the pid of the mud process, attach gdb to it, force it
to write a core dump and then print some of the frame info and save all
of that to a text file and put a symbolic link to it for crash.last (as
well as create a core.last link for the most recent core), and then
create a note and send the contents of crash.last to implementers in the
mud... all of that works fine, the problem I have is the same I was
having before I put in that fork statement (although the forking of the
process does seem a cleaner way of doing it, so thanks for the idea
:D)... for some reason, it seems that the startup script is interfering
w/ the system call to gdb... if, from the shell, I manually run my
'gdbstuff' script, which attaches to the mud process, grabs its commands
from a command file, and sets up the symbolic links to the latest core
and crash text file, it works fine... but if I let the mud make the
system call to do the same (system call consists of only
system("./gdbstuff");), then the process hangs for some reason and never
exits gdb... but if I kill the startup script, then gdb exits
gracefully, the mud copyover's, and I have a new note waiting w/ the
contents of the crash.last file... I don't want to have to run the mud
without the startup script, and this worked fine on the original server
I put it in on, just seems to not want to work right on this one :D I've
been hunting around for the last hour for a perl script I saw a while
back that would check the mud process periodically and either start it
up if it wasn't running, or reboot it if I wasn't responding, like if it
got stuck in an infinite loop or something, but I've had no luck finding
it... I figure running something like that would work ok tho, and would
be willing to do that in place of the standard startup script... so any
info on A) why the startup script could be interfering w/ the system
call to gdb, or B) where that perl script is for doing periodic checks
of the mud status... I would appreciate it :D I even thought about
adding a fork in to call the gdbstuff script from, but then I remembered
that system forks itself anyway... sorry for being long-winded... again
:Dwavewave Richard Lindsey.
