Thanks to:
lisa.wallace_at_doniatel.com
patchov_at_ucalgary.ca
alan_at_nabeth.cxo.dec.com
Nikola.Milutinovic_at_ev.co.yu
joerg_at_sql.de
and the ever helpful Doctor Tom Blinn (tpb_at_doctor.zk3.dec.com)
Using the command ipcs -am, I was able to see what processes caused the
problem.
Serge P. (patchov_at_ucalgary.ca) Summed it up:
>System V-style shared memory segments will hang around even when no
>processes are attached to them. This can be either a conscious design
>decision (this property can be used to pass data between processes
>which are not guaranteed to be running at the same time), or may
>result from a program using System V shared memory exiting at a
>wrong moment (due to a bad design of System V IPC API, it is impossible
>to write a program such that it is guaranteed to remove shared memory
>segments it allocated under all conceivable circumstances).
>
>Unused shared memory segments hanging around are not a big problem
>in themselves; however, they do consume virtual memory. If you
>accumulate a lot of those, you may start running out of memory ...
>
>You can verify this (and get a bunch of potentially useful information
>on the stray segments) with 'ipcs -m'. The corresponding manual page
>gives references to other useful tools - such as ipcrm.
The processes belonged to an performance management tool called best/1.
This problem has been passed to them to have a look at.
In the mean time, I used the ipcrm command to remove the unattached
memory segments and everything seems to be running fine.
Many thanks.
Original Question:
------------------
>Dear Managers
>
>Just upgrade Tru64 4.0d to 4.0f patch kit 3
>
>Installed syscheck 114.
>
>When run, the following warning is issued. Can any one enlighten me
>what it means?
>
>Operational: Shared memory segment with 0 attaches ( 2048 ).
>Operational: Shared memory segment with 0 attaches ( 2080 ).
>Operational: Shared memory segment with 0 attaches ( 46128 ).
Internet communications are not secure and therefore the Barclays Group does
not accept legal responsibility for the contents of this message. Any views
or opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.
Received on Fri Apr 14 2000 - 07:33:33 NZST