SEO

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

Greetings,

I also discovered last week deleting the SHM segment - using 'ipcrm' - may not completely remove it. If there is a "D" as the first character under the 'mode' column, the process controlling the memory segments - IDS in this case - must be terminated before the SHM segments will be removed.

Mike Badar
ESRI
1 International Ct.
Broomfield, CO 80021
mbadar@esri.com
303-449-7779
www.esri.com

> -----Original Message-----
> From: informix-list-bounces@iiug.org
> [mailto:informix-list-bounces@iiug.org] On Behalf Of Martin Fuerderer
> Sent: Monday, May 14, 2007 3:22 AM
> To: Beau Nanaz
> Cc: informix-list-bounces@iiug.org; informix-list@iiug.org
> Subject: Re: Confused engine: No SHM segments but thinks it
> is quiescent
>
> Hi,
>
> you can look in /INFORMIXTMP directory. (No environment
> variable in this name.)
>
> Also, make sure that when looking for SHM segments ("ipcs
> -m") you do that as user root. Depending on OS configuration
> you will simply not see SHM segments of an IDS instance if
> you are not user root ...
>
> Regards,
> Martin
> --
> Martin Fuerderer
> IBM Informix Development Munich, Germany Information Management
>
> IBM Deutschland GmbH
> Chairman of the Supervisory Board: Hans Ulrich Märki Board of
> Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
> Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas
> Fell, Michael Diemer Corporate Seat: Stuttgart, Germany;
> Reg.-Gericht: Amtsgericht Stuttgart,
> HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940
>
> informix-list-bounces@iiug.org wrote on 13.05.2007 19:38:55:
> > 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
> >
> > _______________________________________________
> > Informix-list mailing list
> > Informix-list@iiug.org
> > http://www.iiug.org/mailman/listinfo/informix-list
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>

Thank you, Martin and Mike.

That tidbit about not running ipcs -m as root was an interesting one;
I have never encountered an informix server with invisible SHM
segments. Normally, even when owned by root, I can see the segments in
the ipcs -m output.

Martin,

yes, I found all those 0-length files under /INFORMIXTMP, with names
like VP.${INFORMIXSERVER}.010101s (the most recent such file, time-
stamped 17:07). When I put the engine down, all these files with
this server name were gone.

I bring it up into quiescent mode and I find:
May 14 17:22 .inf.${INFORMIXSERVER}_shm (228 bytes)
May 14 17:22 VP.${INFORMIXSERVER}.010100s (0-bytes)

Bring it on-line and I get the same files, no change in time stamp.

While not exactly fascinating, it is rather interesting.

I might guess what those digits stand for and guess at the 's' suffix
they all have.

But my question is basically answered.

Thanks much.

-- J

On May 14, 5:21 am, Martin Fuerderer <MARTI...@de.ibm.com> wrote:
> Hi,
>
> you can look in /INFORMIXTMP directory. (No environment
> variable in this name.)
>
> Also, make sure that when looking for SHM segments ("ipcs -m")
> you do that as user root. Depending on OS configuration you
> will simply not see SHM segments of an IDS instance if you are
> not user root ...
>
> Regards,
> Martin
> --
> Martin Fuerderer
> IBM Informix Development Munich, Germany
> Information Management
>
> IBM Deutschland GmbH
> Chairman of the Supervisory Board: Hans Ulrich Märki
> Board of Management: Martin Jetter (Chairman), Rudolf Bauer, Christian
> Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael
> Diemer
> Corporate Seat: Stuttgart, Germany; Reg.-Gericht: Amtsgericht Stuttgart,
> HRB-Nr.: 14 562 WEEE-Reg.-Nr. DE 99369940
>
> informix-list-boun...@iiug.org wrote on 13.05.2007 19:38:55:
>
> > 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

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