Re: Shared memory segments hanging around

Hi: I'm not 100% sure on this, but what's probably happening is that OnLine is grabbing the first part of its shared memory segments (I believe it's the resident) and when it goes to get the rest, it's encountering a problem. One way to clean up this mess is to explicitly delete the segments before trying to bring up the engine using ipcrm. Hope that helps. Arun Jacob Salomon wrote: > 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?| > +----------------------------------------------------------+