Shared memory segments hanging around
Hi Folks.
I have a problem I that calls for familiarity with certain quirks.
OnLine DSA 7.13.UC5.
Main Symptoms:
My users used onmonitor to change the number of locks (150000-->200000).
Onmonitor gives its usual warnings - are you sure blah blah.. But then
all just does nothing - it seems to think it's in recovery. If I bring
up another copy of onmonitor, it still registers OFF LINE. The
online.log contains the following text:
Thu Jul 31 13:35:35 1997
13:35:35 init_alarm(): alarmprog = '/usr/informix/onalarm.sh'
shell = '/bin/ksh'
13:35:36 DR: DRAUTO is 0 (Off)
13:35:36 hpkaioaddseg: ASYNC_ADDSEG failed, errno = 14
13:35:36 kaioapi.c, line 73, thread 17, proc id 3166, kaio error.
13:35:37 PANIC: Attempting to bring system down
HMMmm... I looked at ipcs -m and found the shared memory segments
hanging around. (Minus the user segment with the permissions rw-rw-rw-)
When I ran ipcrm -m on these segments, they get marked D and the key
values got zeroed out but they still hang around and I cannot bring up
the instance again.
Sorry, I didn't save the ipcs output for this posting.
When I want to change a parameter that requires bouncing the engine, I
prefer to change it in the $ONCONFIG file myself and bounce the engine
via onmode -k and oninit. Still, whatever my users did is 100% legit
(according to the docs).
So why can't it come up again? Those shared memory segments I see: Are
they from this current attempt to come up or are they holdovers from the
session that was running before I changed the parameters? I am inclined
to suspect the former, because the error was in "addseg" and there is a
segment missing (the user segment).
Oh yes, when the system gets rebooted, the OnLine comes up without a
hiccup. (With the locks adjusted as desired.)
Additional circumstances:
OnLine comes up as part of rc. (Actually, rc.d/some-other-script.) The
script file is being run by user at boot time root but is listed as
belonging to user/group bin/bin.
Since this is a production system, I cannot simply ask for permission to
experiment with using onmode -k and oninit to bounce the engine. But
this is probably what I would need to do in order to isolate the
problem.
Has anyone else experienced this situation? It has a familiar ring to
it, as though I have seen it at other clients (under a different
employer).
Any help deserves a beer. (Not that I'm likely to send you one, though I
have expresed gratitude this way before. ;-)
Thanks.
--
-- Jake (In pursuit of undomesticated aquatic avians)
+----------------------------------------------------------+
|Aside from that, how did you enjoy the play, Mrs. Lincoln?|
+----------------------------------------------------------+