shmget errors

Oliver Fromme olli at
Thu Dec 15 06:22:08 PST 2005

Morten A. Middelthon <morten at> wrote:
 > I've seen this problem discussed before on various mailinglists and forums,
 > but never any real solutions.

What you describe is an inherent problem with so-called
System-V shared memory (SysV ShMem) which doesn't have a
simple solution.  But read on for some hints ...

SysV IPC (inter-process communication) provides objects
to communicate between arbitrary processes:  shared memory
segments, semaphores and message queues.  Those objects
are _not_ automatically freed when the process terminates,
unlike other resources (such as open files or network

That means:  When a process crashes which has opened such
SysV IPC object, then those objects will _not_ be freed,
but stay around and consume memory.  This is not a bug,
it's a feature, because those IPV objects are intended to
be used by unrelated processes, so a process may later
pick up the existing IPC objects and continue working with

The problem is that those resources are limited.  You can
put hard limits on the in your kernel configuration.
Look for "SYSV IPC" in /sys/conf/NOTES.  You can also see
the values in ``sysctl kern.ipc'' and via ``ipcs -T''.

Of course, you could increase the values, but that puts the
limit only a bit further away, but it doesn't remove the
problem.  Apart from that, the "dead" reasources will take
up more and more memory.

You can see all IPC object currently existing the ``ipcs''

If you have programs that create SysV IPC objects and which
are particularly prone to crash often, leaving the objects
behind, it might be best to write a small wrapper script
which calls the program and then cleans up afterwards.

Also, the following shell snippet might be helpful:

ipcs | awk '($1=="m"){print $2}' | xargs -n 1 -t ipcrm -m

It removes _all_ shared memory segments.  Be careful:
Don't do that while any programs are still running which
use SysV shared memory.  You can check that by looking at
the output of ``ipcs -p'':  If the process IDs listed under
the CPID and LPID columns don't exist, chances are that the
memory segment isn't in use anymore.

Best regards

Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD:
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"C is quirky, flawed, and an enormous success."
        -- Dennis M. Ritchie.

More information about the freebsd-stable mailing list