Not that anyone should care about the things that make me crabby, but…here comes another brief post in my Little Things Doth Crabby Make series.
In the following box, you’ll see how I was just simply trying to remove a wee bit of detritus, specifically a segment of SysV IPC shared memory. So, here’s how this all transpired:
- I used the ipcs command to get the shmid (262145).
- I then fat-fingered a typo and tried to remove shmid 262146
- Having realized what I did I immediately satisfied my curious morbidity, er, I mean morbid curiosity and checked the return code from the ipcs command. Oddly ipcs reported that it was perfectly happy to not remove a non-existent segment. But that’s not entirely what made me crabby.
- I then issued the command without the typo.
- Next (as fast as I could type) I checked to see what segments remained. That’s where I started to get even crabbier.
- Since it seemed I was facing some odd stubbornness, I decided to issue the “old school” style command (i.e., the shm argument/option pair). The command failed but since that style of command is documented as deprecated I simply thought I was getting deprecated functionality.
- Finally, I ran ipcs once gain to find that the segment was gone.
# ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 0 root 600 189 1 dest 0x522d5fd4 262145 oracle 660 6444548096 14 # ipcrm -m 262146 # echo $? 0 # ipcrm -m 262145 # ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 0 root 600 189 1 dest 0x00000000 262145 oracle 660 6444548096 14 dest # ipcrm shm 262145 cannot remove id 262145 (Invalid argument) # ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 0 root 600 189 1 dest
Forget the oddball situation with the return code for a moment. What I just discovered is that the work behind the ipcrm command that clears down the memory is asynchronous functionality. You all may have known that for all time, but I didn’t. Or, at least I don’t remember forgetting that fact if I did know it at one time.
It turns out the very first ipcrm –m 262145 was in the process of succeeding. That’s why my deprecated command usage was answered truthfully with EINVAL. The segment was gone, I was just being impatient.
Disclaimer
I reserve the right to remain crabby about the success code returned after my failed attempt to remove a segment that didn’t exist.
Hold it. Why would anyone care about SysV IPC shared memory where the Linux ports of Oracle Database 11g are concerned? After all, Automatic Memory Management is implemented via memory mapped files.
Summary
Don’t script against the return code of the Linux ipcrm command. It might make you crabby.
Kevin Closson's Blog: Platforms, Databases and Storage 
poking about on the man pages on the intertubes and my own systems, I see things like:
-m shmid
removes the shared memory segment identified by shmid after the last detach is performed.
So getting crabby about that is like rm’ing your datafiles and being crabby you haven’t crashed your database or gotten the space back. Yet.
Joel,
You missed the point. I got crabby about the success code returned by a command that didn’t succeed. Also, the database was down. That’s why I refer to the segment as detritus. That’s also why I don’t see your point about manpage content. I was aware of what it says.
Let’s see if this aid’s your misunderstanding of the point:
# ipcrm -m this-is-for-joels-edification
# echo $?
0
You can run this same command on any of your systems (Linux 2.6 kernel) without harm and see the crabby-maker too.
Thanks for stopping by.
Hmmm.. I had some memory leak problems before, I should have used ipcs -a it seems. Do you know if/which meminfo counters show the still existing segment?
Bernd