EsiObjects won't start after reboot

[ephidryn hcl]

Hello,
  I have been working with EsiObject for a week now with GT.M on Linux. I noticed that there were about 10 "mumps" processes consuming ~85% of each CPU. I went out for a smoke and when I came back it was still up there around 85% on each cpu! I used the '"reboot" command to reboot the machine and when it came back online EsiObjects wouldn't start back up. I issued the command "/sbin/service start" and it would print out  "Starting EsiObjects " but never the "[OK]" portion.

After a few reboots and deleting the pid file and trying the /sbinservice program a few times, I just went to my home directory and reran the "setup" script. Now it works.

Will this type of corruption happen whenever a reboot  happens under heavy load times?

Cheers,
  Gardner

[K.S. Bhaskar]

Gardner --

ESI Objects probably has some mechanism to shut down cleanly, but simply rebooting is not a clean way to shut down GT.M.

If you don't shut GT.M down cleanly, you will need to issue a mupip recover command, with appropriate flags, to recover the database from the journal files, if you have journaling enabled.

To shut down GT.M, you should issue a mupip stop command to your GT.M processes.

If you plan to reboot your machine, a mupip rundown before the boot would be appropriate.

For more discussion about GT.M specifics that are not tied to ESIObjects, please do post to the GT.M forum - posts are read and responded to.

Regards
-- Bhaskar

[Eric Lambart]

When mumps pegs my CPU(s), I run this simple shell script (note that you will have to disconnect and reconnect the ESI IDE if it hasn't already frozen as well):

#!/bin/bash
echo n | /usr/local/gtm/gtmstop
echo
service esiobjects start

I've saved this in /usr/local/gtm/restart (and of course, made it executable).

HTH
Eric