Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

IPCRM ? Shared Memory Segments Locked

501 views
Skip to first unread message

Krumrey, Laurie

unread,
Apr 17, 2002, 7:27:45 PM4/17/02
to

Hi All,

We have an informix engine 7.3 and Unix 11.0. We tried to reboot..bad news.

She won't come up. She toggles stuck in the INFORMIX start up script
(WAIT/BUSY).

We have been told in the past...to use ipcrm on the informix shared memory
segments that were
locked and then the engine would come up.

We don't know how to use IPCRM. Does this sound like the correct procedure?
We took the engine
down correctly, turned off continuous logging and then turned offline
gracefully.

Please help us...

Laurie Krumrey
816-584-6393
lau...@mail.park.edu
www.park.edu

kakaz

unread,
Apr 18, 2002, 3:03:05 AM4/18/02
to
"Krumrey, Laurie" <lau...@mail.park.edu> wrote in message news:<a9l17o$orj$1...@news.xmission.com>...

> Hi All,
>
> We have an informix engine 7.3 and Unix 11.0. We tried to reboot..bad news.
>
> She won't come up. She toggles stuck in the INFORMIX start up script
> (WAIT/BUSY).
>
> We have been told in the past...to use ipcrm on the informix shared memory
> segments that were
> locked and then the engine would come up.
>
> We don't know how to use IPCRM.
Hi!
Comand ipcs -m shows You folowing output ( example)
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x00000000 0 nobody 600 46084 8 dest
0x00000000 933505 root 777 21280 0
0x00000000 933506 root 777 36176 0
0x00000000 933507 root 777 38000 0
0x00000000 1463684 root 777 51984 0
0x00000000 1001861 root 777 40000 0
0x00000000 1003910 root 777 40000 0
0x00000000 5689991 root 777 21280 0
0x00000000 1018888 root 777 40000 0
0x00000000 6120841 root 777 383400 0
0x00000000 6120714 root 777 3648 0

As You see there are few columns. Column shmid shows You shared memory
segment id, which is unical. If You want to remowe ( destroy) that
segment You must just as root ( or owner of the segment ) use ipcrm
[option] shmid. Which opiton You must use You may read in man ipcrm.

But be careful: when You remowe segment which is used by some
programs, and You don't stop this programs before, anything may hapen:
maybe your machine will explode?
Maybe You will be poisoned?
Maybe there will be the end of known world?

Let the power be with You!!!


Regards
KK

Colin Bull

unread,
Apr 18, 2002, 3:00:13 AM4/18/02
to

Depending on your flavour of Unix --
ipcs shows---------------
dev-ds2-1# ipcs
Message Queues:
T ID KEY MODE OWNER GROUP
q 0 0x412204e6 --rw------- root system

Shared Memory:
T ID KEY MODE OWNER GROUP
m 1024 0x527b4801 -Lrw-rw---- root informix
m 1025 0x527b4802 --rw-rw---- root informix
m 1026 0x527b4803 --rw-rw-rw- root informix

Semaphores:
T ID KEY MODE OWNER GROUP
s 0 0x696e6974 --ra-r--r-- root system
s 1 0x412204e6 --ra------- root system
s 514 0 --ra-ra---- root informix
s 515 0 --ra-ra-ra- root informix
-------------------------------
If Informix is not running, there should not be any mention of Informix.
I would try onmode -yuck before doing this to double check, as killing
memory segments can be dangerous if engine is running.

Then to kill a Shared Memeory segment -
ipcrm -m 1026

To kill a semaphore -
ipcrm -s 514


Colin Bull
c.b...@VideoNetworks.com Watch over 1300 films AND Premier League football
when ever you want

> -----Original Message-----
> From: owner-inf...@iiug.org
> [mailto:owner-inf...@iiug.org]On Behalf Of Krumrey, Laurie
> Sent: 18 April 2002 00:28
> To: inform...@iiug.org
> Subject: IPCRM ? Shared Memory Segments Locked
>
>
> Hi All,
>
> We have an informix engine 7.3 and Unix 11.0. We tried to
> reboot..bad news.
>
> She won't come up. She toggles stuck in the INFORMIX start up script
> (WAIT/BUSY).
>
> We have been told in the past...to use ipcrm on the informix shared memory
> segments that were
> locked and then the engine would come up.
>

Dirk Moolman

unread,
Apr 18, 2002, 6:46:36 AM4/18/02
to

I tried releasing memory this morning, by using "ipcrm -m 1026" (example)

but the status just changed to
m 1026 0x527b4803 D-rw-rw-rw- root informix (notice the capital D)

and the memory wasn't released. This was on AIX 4.3.3

Simmons, Keith

unread,
Apr 18, 2002, 7:28:01 AM4/18/02
to

Using 'ipcrm -m' removes the shared memory identifier from the system,
however the shared memory segment and the data structures are only destroyed
(released) after the last detach (according to the man pages). You must
still have a process attached to the shared memory segment (also indicated
by the cap D).
Use ipcs -o to see how many processes are still attached to the memory
segment. -p shows last process to attach/detach.
Oh what the heck! use -a to show all information !! that might give you some
clue as to what is going on and who has got their hooks into you memory :-)

Keith Simmons
Banner Business Supplies Limited
Informix Certified Professional

-> -----Original Message-----
-> From: Dirk Moolman [mailto:Di...@mxgroup.co.za]
-> Sent: Thursday, April 18, 2002 11:47 AM
-> To: 'Colin Bull'; iiug
-> Subject: RE: IPCRM ? Shared Memory Segments Locked
->
->
-> I tried releasing memory this morning, by using "ipcrm -m
-> 1026" (example)
->
-> but the status just changed to
-> m 1026 0x527b4803 D-rw-rw-rw- root informix (notice
-> the capital D)
->
-> and the memory wasn't released. This was on AIX 4.3.3
->
->
-> -----Original Message-----
-> From: Colin Bull [mailto:c.b...@videonetworks.com]
-> Sent: 18 April 2002 09:00
-> To: iiug
-> Subject: RE: IPCRM ? Shared Memory Segments Locked
->
->
-> Depending on your flavour of Unix --
-> ipcs shows---------------
-> dev-ds2-1# ipcs
-> Message Queues:
-> T ID KEY MODE OWNER GROUP
-> q 0 0x412204e6 --rw------- root system
->
-> Shared Memory:
-> T ID KEY MODE OWNER GROUP
-> m 1024 0x527b4801 -Lrw-rw---- root informix
-> m 1025 0x527b4802 --rw-rw---- root informix
-> m 1026 0x527b4803 --rw-rw-rw- root informix
->
-> Semaphores:
-> T ID KEY MODE OWNER GROUP
-> s 0 0x696e6974 --ra-r--r-- root system
-> s 1 0x412204e6 --ra------- root system
-> s 514 0 --ra-ra---- root informix
-> s 515 0 --ra-ra-ra- root informix
-> -------------------------------
-> If Informix is not running, there should not be any mention
-> of Informix. I
-> would try onmode -yuck before doing this to double check,
-> as killing memory
-> segments can be dangerous if engine is running.
->
-> Then to kill a Shared Memeory segment -
-> ipcrm -m 1026
->
-> To kill a semaphore -
-> ipcrm -s 514
->
->
-> Colin Bull
-> c.b...@VideoNetworks.com Watch over 1300 films AND Premier
-> League football
-> when ever you want
->
-> > -----Original Message-----
-> > From: owner-inf...@iiug.org
-> > [mailto:owner-inf...@iiug.org]On Behalf Of Krumrey, Laurie
-> > Sent: 18 April 2002 00:28
-> > To: inform...@iiug.org
-> > Subject: IPCRM ? Shared Memory Segments Locked
-> >
-> >
-> > Hi All,
-> >
-> > We have an informix engine 7.3 and Unix 11.0. We tried to
-> reboot..bad
-> > news.
-> >
-> > She won't come up. She toggles stuck in the INFORMIX
-> start up script
-> > (WAIT/BUSY).
-> >
-> > We have been told in the past...to use ipcrm on the
-> informix shared
-> > memory segments that were locked and then the engine would come up.
-> >
-> > We don't know how to use IPCRM. Does this sound like the correct
-> > procedure? We took the engine
-> > down correctly, turned off continuous logging and then
-> turned offline
-> > gracefully.
-> >
-> > Please help us...
-> >
-> > Laurie Krumrey
-> > 816-584-6393
-> > lau...@mail.park.edu
-> > www.park.edu
-> >
->

**********************************************************************************
This message is sent in strict confidence for the addressee only. It may
contain legally privileged information. The contents are not to be disclosed
to anyone other than the addressee. Unauthorised recipients are requested
to preserve this confidentiality and to advise the sender immediately of any
error in transmission.
This footnote also confirms that this email message has been swept for the
presence of computer viruses, however we cannot guarantee that this message
is free from such problems.
**********************************************************************************

Dirk Moolman

unread,
Apr 18, 2002, 9:46:53 AM4/18/02
to

Excellent, thank you Keith !

Rajib Sarkar

unread,
Apr 20, 2002, 5:08:06 AM4/20/02
to
U can also do a ps -ef|grep oninit and most probably there's one
process still hanging around ... killing that process will remove the
SHMEM segment.

Rajib

Dirk Moolman <Di...@mxgroup.co.za> wrote in message news:<a9mkan$a3b$1...@news.xmission.com>...

kakaz

unread,
Apr 22, 2002, 2:41:26 AM4/22/02
to
rsa...@us.ibm.com (Rajib Sarkar) wrote in message news:<f965274d.02042...@posting.google.com>...

> U can also do a ps -ef|grep oninit and most probably there's one
> process still hanging around ... killing that process will remove the
> SHMEM segment.
>
> Rajib
Hi!
But why You want to detach a process from shared memory when it is
runing?
If it is oninit it means that You don't stop it completly and so You
should rather stop it using onmode -ky than kill ;-)))

I don't understand what You are doing, but if You have to kill Your
oninit You doing something wrong. if You want not to start informix
during machine startup, just remove proper file from Yur starting
script directory /etc/rcN.d where N usually = 3.
If You can't stop informix during it is working, it is normal
especially if You have distributed transactions. It may just take a
while...
If You doing experiments with Your dataserver, just keep going on...it
is OK!

I setup and patch and tune over 200 informix servers, and I NEVER have
had to kill oninit in order to stop it. yes sometimes I must detach
shared memory segment, but it where never used by oninit ( or
something else)!!!

By!
KK

Dirk Moolman

unread,
Apr 22, 2002, 9:20:17 AM4/22/02
to

In this case he was refering to an engine that has already been stopped
(onmode -kuy) and there are still oninits floating around in Unix ......

Rajib Sarkar

unread,
Apr 22, 2002, 1:42:30 PM4/22/02
to
I know what you are talking about ... but say you have done a onmode
-kuy and you are still seeing oninits in the ps -ef output and a
DELETED shared memory segment in the ipcs output ... essentially,
what's happening is that there is one process still attached to the
SHMEM segment which is causing it to remain in the shared memory ...
in that kind of a scenario what would you do ..since you now cannot
start up an engine (the D -- shmem segment is still occupying the
memory) and you might get ENOMEM errors ... the only way out is to
isolate the process which is still attached to it and kill that
process ... of course, there's another way too i.e. REBOOT the server
.. I guess we don't really need to go into that ..:-)

Hope that's made it clear ...:-)


Rajib

kak...@yahoo.com (kakaz) wrote in message news:<efd3e15d.02042...@posting.google.com>...

0 new messages