Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!virtech!cpcahil
From: cpcahil@virtech.UUCP (Conor P. Cahill)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Memory
Message-ID: <1135@virtech.UUCP>
Date: 7 Sep 89 01:33:23 GMT
References: <20787@adm.BRL.MIL>
Organization: Virtual Technologies Inc
Lines: 28

In article <20787@adm.BRL.MIL>, SPETTRI%IFIIDG.BITNET@cunyvm.cuny.edu (Memcaraglia Francesco) writes:
>  I have two shared memory segments I would like to throw away;
>  I tried with ipcrm and I got the expected result, that is after
>  calling ipcs the segments were listed as D..... ( that is to be
>  destroyed after last attach) ; however, after reboot the two
>  segments are again there; closer examination shows that there are
>  attached processes . I do not understand how I can get rid of
>  these segments ? Any suggestion ?

The shared memory segments were not STILL there after the reboot, they
must have been recreated following the boot up.  Have you verified the 
creation times to see that they have not changed accross the reboot?
If what you are saying really does happen, you probably need to add some
additional information about your hardware and OS because this is not the
standard behavior.


I have worked on some system V implementations (Concurrent Computer's Xelos,
for example) that had a bug in that if the program does not explicitly 
detach from the shared memory segment, the attachment count might not be 
decremented  when the process exits.   When  this occured, the only way to 
get rid of the segment was to reboot.

-- 
+-----------------------------------------------------------------------+
| Conor P. Cahill     uunet!virtech!cpcahil      	703-430-9247	!
| Virtual Technologies Inc.,    P. O. Box 876,   Sterling, VA 22170     |
+-----------------------------------------------------------------------+