Re: Confused engine: No SHM segments but thinks it is quiescent

Hi again, family. This time I can contribute a solution because it happened again and I was able to pay attention to the messages when I tried to bounce the engine in an attempt to cure the ghost "quiescent mode" messages. I don't have that session open in front of me now but when I tried to start the engine I got "Error in shared memory initialization" with an error number. Finderr on that error number said something about ports already in use. AHA! The TCP port must still be occupied. But by *whom*? And which TCP port? The second question was easier - I grep the sqlhosts file for the name of my server and turned a port named sqlexec_Y. I then use the recently-learned Unix utility, lsof: $ lsof | grep sqlexec_Y This turned up a bunch of oninit processes. I was still monitoring the online.log file (tail -f &) so I could see the results of my actions. I killed the first oninit process in the list and watched "The master daemon has died" and "Attempting to bring system down". Now I could bring up the engine normally, with the original SHM allocations. Hurrah! Pat myself on the back. (Hey, I can *wash* my own back ;-) (I should confess that my first responses to the shared-memory messages were to reduce the BUFFER and SHMINIT parameters but it got to the point where I could proved they were not a memory issue.) Now *that* was fun! -- J On May 13, 1:38 pm, Beau Nanaz <spamntr...@yahoo.com> wrote: > Hi Family. > > I have a problem I have encountered before, years ago! > > Reasons aside (relating to a failed restore) when I tried to bring up > the engine, it failed. No shared memory segments exist for the > server. However, when I tried to demonstrate the down state of the > engine with a dbacces connection, I get the message: > -27002 No connections are allowed in quiescent mode. > Poor engine! It thinks it is asleep and does not realize it's dead! > > I recall there is a file someplace under $INFORMIXDIR that gives the > current state of the server. The bogus "quiescent" status is coming > from there. All I need to do is delete (OK, rename; Sheesh! > Paranoia! ;-) that file the server will know it is dead. > > Anyone recall what that file is? I found $INFORMIXDIR/etc/.conf. > {INFORMIXSERVER}, a binary data file, but don't know if this is the > one. (Please, no suggestions to delete oninit! ;-) > Advice, anyone? > > Thanks much. > > -- J

On 21 May 2007 21:40:54 -0700, Beau Nanaz <spamntrapf@yahoo.com> wrote: >Hi again, family. > >This time I can contribute a solution because it happened again and I >was able to pay attention to the messages when I tried to bounce the >engine in an attempt to cure the ghost "quiescent mode" messages. > >I don't have that session open in front of me now but when I tried to >start the engine I got "Error in shared memory initialization" with an >error number. Finderr on that error number said something about ports >already in use. AHA! The TCP port must still be occupied. But by >*whom*? And which TCP port? > >The second question was easier - I grep the sqlhosts file for the name >of my server and turned a port named sqlexec_Y. I then use the >recently-learned Unix utility, lsof: >$ lsof | grep sqlexec_Y> >This turned up a bunch of oninit processes. I was still monitoring >the online.log file (tail -f &) so I could see the results of my >actions. I killed the first oninit process in the list and watched >"The master daemon has died" and "Attempting to bring system down". > >Now I could bring up the engine normally, with the original SHM >allocations. Hurrah! Pat myself on the back. (Hey, I can *wash* my >own back ;-) > >(I should confess that my first responses to the shared-memory >messages were to reduce the BUFFER and SHMINIT parameters but it got >to the point where I could proved they were not a memory issue.) > >Now *that* was fun! > There is a great feeling when your "detective work" pays off . . . . and a lesson not soon forgotten . . . great job! JWC