[NBLUG/talk] ipcs/ipcrm

[Ross Thomas]

On Wed, 22 Jun 2005 12:32:47 -0700 (PDT), "Walter Hansen"
<gandalf at sonic.net> said:
> Sorry this took so long. I was real busy on a project and it's now
> clearing up...

NP.

So looking at the output, I'm assuming the shmid's owned by root
are the targets.  And also by looking at the keys, the two sema's
too.  Unfortunately, there is no way to determine whether a sema
is 'orphaned' since, by their nature, they exist outside of the whole
process structure.

> [root at abco wrs]# ipcs
> 
> ------ Shared Memory Segments --------
> key        shmid      owner      perms      bytes      nattch     status
> 0x626d756e 655360     root      666        65536      0
> 0x646c6f68 688129     root      666        65536      0
> 0x00000000 557058     postgres  600        10436608   1          dest
> 
> ------ Semaphore Arrays --------
> key        semid      owner      perms      nsems
> 0x626d756e 3801088    root      666        3
> 0x646c6f68 3833857    root      666        3

So from the above, the biggest 'hammer' we should use would
be something like this:

#!/bin/sh

# If we are debugging, just echo the nasties
if [ "$1" = "-d" ]
then
    ECHO=echo
    shift
fi

user=${1:-`whoami`}

ipcs -m |
   while read key shmid owner perms bytes nattch status
   do
       # Simple exclusions.  The garbage headers will be caught by
       # the "$nattch" != "0" clause.
       #
       [ -n "$status" -o "$nattch" != "0" -o "$key" = "0x00000000" ] &&
            continue

       # Arg-based exclusions.  You could do more here, but this
       # will do for now.
       #
       [ "$user" != "$owner" ] && continue

       # At this point we know it hasn't been destroyed already.
       # And it's got no attachments.  And it has a key.  And it
       # belongs to the specified user.  Kill it and and any associated
       # sema.
       #
       $ECHO ipcrm -m "$shmid" && $ECHO ipcrm -S "$key"
  done

You may get some error messages from the blind removal of the
sema so you can either ignore them or redirect them to /dev/null.

HTH

Oh!  Yeah.  Usual disclaimers apply.  ;-)

Ross.
       

-- 
http://www.fastmail.fm - And now for something completely different