Re: Shared memory segments hanging around

Hi Family. In July, I posted the following cry [in the dark] for help. I even had a case for it at Informix. I have edited out the social niceities for brevity (an attribute I am not famous for ;-) . |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. OK, so much for the reminder. I note that I forgot to include the OS version in my post. It happens to be HP-UX 10.01 but so what? Well, I have been informed by a colleague that the problem seems to trace back to an OS bug in an internal messaging subsystem. The result is that on occasion, the order to release the shared memory descriptors back the pool is effectively ignored. Sounds familiar. I will simply have to start lobbying and otherwise being an Irritattus Maximus en Glutea for my admin folks to upgrade their OS to 10.20+ (as well as the Informix version to 7.23) but that's another story. -- -- Jake (In pursuit of undomesticated aquatic avians) +---------------------------------------------------------------+ |Insofar as manifestations of functional deficiencies are agreed| |by any and all concerned parties to be imperceivable, and are | |so stipulated, it is incumbent upon said heretofore mentioned | |parties to exercise the deferment of otherwise pertinent | |maintenance procedures. | +------------------- A Legal Minded Engineer (hardyharhar.com) -+