We have a working script which identifies and kills ipcs resources which havent been correctly killed during normal shutdowns.
It is working fine and dandy however there are some issues now.
Our target search string has increased by 1 character from 8 chars to 9. What I am observing @ this point is the ipcs -a | grep (9 char string) is returning blank results. The increase in characters is due to new naming conventions. So while it may be easy to say , "simply use an 8 char database", in practicality it is over my head.
Desired Solution:
I need to find a way to get ipcs to be able to identify resources associated with a 9 char search string. From what I have read so far I havent dug up an environment var or quick fix for this issue. I have also dug through a few posts here in the forum in the hopes of finding a solution.
Code Example:
a) Working:
ipcs -a | grep 1245678
b) Not working
ipcs -a | grep 123456789
Anything you can offer is appreciated!
There are logic tweaks I can make to the script however out of curiosity I would like to learn more about ipcs on solaris. Constantly hungry for skills!
ipcs resources are kernel persistent. They cannot persist over a reboot. So, what you said appears to be wrong, or you need to do some more explanation - specifically 'database name' - what is it: a key generated by ftok()? What are we doing here?
How do you know that the shared memory for a db was not destroyed then recreated by a reboot? Rather than persisting over reboot.
Or do you mean a db shutdown/restart? We need clarity. And a decent example.
I did not imply a reboot was going to be done in any way shape or form, so if I gave that misinimpression I apologize. The issue is this:
1) We are using a script to clean up any hanging ps/ipcs resources that may be erroneosly be left over after we shut down application servers ( database servers are not being stopped/shutdown).
2) The script works as long as your target search string is up to 8 characters long.
3) We have new instances in our environment which have 9 character strings.
When I use the ipcs -a | grep (a 9 char string) there is no data returned. Unless I am mistaken this is because the ipcs command itself will not detect any search string > 8 characters.
I have tested this out and lo and behold this is an issue. So my question is this:
Q) Is there any way to tweak the command via env settings or ANY other feasible method so that we can get ipcs to detect a search pattern that is longer than 8 characters?
Again, the database is NOT being shutdown or restarted, it is our application servers which are being shutdown. As far as clarity goes I think the example was pretty clear :
1) ipcs -a | grep 1245678 - DOES return a set of results as the 8 char limit isnt breached.
2) ipcs -a | grep 123456789 - DOES NOT return a set of results with this 9 char search string, I am trying to find a way to get the ipcs command to detect something longer than 8 chars in its search string.
Again, I understand the ipcs command stems for a library within Solaris itself. So I am not going to get into re-writing any part of code and recompiling the kernel,etc.
Rather I am curious to see if anyone else has run into this limitation and how they have worked around it?
Thanks! All positive answers and your time are much appreciated.
Just wanted to follow up and clarify this post a bit, I apologize for any confusion caused.
The output from the ipcs command that I am concerned with is the "CREATOR" column. I am using the -a flag . The issue is that newer app servers are named with a 9 name character set. And from what I can tell the max char is 8 for the CREATOR group with the ipcs command.
So my question refined would be , "Is there any way to get ipcs to increase the limit for the CREATOR column from the ipcs command when using on Solaris 10?"
In this case the CREATOR is listed as "xgudprda" which is an 8 char string. The crux of my question is can we get this output to default to 9 characters or anything greater than 8 chars?
ipcs doesn't have the magic ability to know when something on the other side of the pipe is grepping for 9 characters or more. Maybe it's not printing more than 8 characters in the first place, but it's not the searching that's screwing it up. It may also be a problem with the search string itself.
Post the raw output from ipcs, and post the string that somehow fails to match, and maybe we'll see why grep isn't matching it.
