From owner-freebsd-stable@FreeBSD.ORG Thu Dec 15 14:22:08 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7F3F16A41F for ; Thu, 15 Dec 2005 14:22:08 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39D0F43D4C for ; Thu, 15 Dec 2005 14:22:05 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ojuzmj@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id jBFEM4vr058513 for ; Thu, 15 Dec 2005 15:22:04 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id jBFEM4Ei058512; Thu, 15 Dec 2005 15:22:04 +0100 (CET) (envelope-from olli) Date: Thu, 15 Dec 2005 15:22:04 +0100 (CET) Message-Id: <200512151422.jBFEM4Ei058512@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <20051215132556.GB74188@freenix.no> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-STABLE (i386)) Cc: Subject: Re: shmget errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2005 14:22:08 -0000 Morten A. Middelthon 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 sockets). 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 them. 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'' command. 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 -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd 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.