Date: Sun, 4 Jun 2006 21:18:50 -0700 From: David King <dking@ketralnis.com> To: freebsd-questions@freebsd.org Cc: Bill Moran <wmoran@collaborativefusion.com> Subject: Re: shmget: No space on device (sshit) Message-ID: <27CE73B8-B2DC-4EB5-A350-8259E7AFDD1A@ketralnis.com> In-Reply-To: <20060604193932.1872024a.wmoran@collaborativefusion.com> References: <0CFDA5B7-6649-4891-BB66-31D9BCB83B38@ketralnis.com> <20060604085148.5f7c5287.wmoran@collaborativefusion.com> <A1281BE0-942C-454E-B4D2-FF6519033579@ketralnis.com> <20060604193932.1872024a.wmoran@collaborativefusion.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> Here it is. There looks to be quite a few share memory segments (192) >> of size 64k owned by root, for a total of 12MB. >> Any way to find out who (i.e. what process) owns these? > Yes. Read the man page. Okay, so the following command line (as well as a manual verification) produces no results # ipcs -pm | cut -c 50-56 | while read r; do if [ "$r" -gt 1 ]; then ps axuww|grep -E "^[a-z]+[ ]+$r"; fi; done That cuts out the CPID (creator PID?) of each of the shared memory segments from the output of "ipcs -pm" and then tries to find each of those PIDs in the output of "ps". That leads me to believe that all of the processes that allocated the shm segments are no longer around. The machine has only been up for nine days this time around, so whatever program is doing it is doing it in relatively little time. Can you think of a way to track that, other than by PID (since those PIDs are disappearing)? It may be sshit itself; can anyone on the list read enough Perl to spot shared memory leaks? (it's a short script, 182 non-comment lines, that I can attach, and that is in /usr/ports/security/sshit) >> Anything here that would prevent sshit from allocating more? > Sure. That's the point to this. You trimmed out all your config > information, > but how many shared memory segments are you allowing? How many > semaphores? > If those are near 192 and 10, you may be hitting the limit on how > _many_ > are allowed, not how much memory they can use. I have all of the IPC-related sysctls listed below. I do see that kern.ipc.shmmni is set to 192, and that kern.ipc.semmni is set to 10. Are those the maximums? What does MNI mean in those names? Is there a man page or recommended document that describes what these mean in detail? # sysctl -a | grep ipc kern.ipc.maxsockbuf: 262144 kern.ipc.sockbuf_waste_factor: 8 kern.ipc.somaxconn: 128 kern.ipc.max_linkhdr: 16 kern.ipc.max_protohdr: 60 kern.ipc.max_hdr: 76 kern.ipc.max_datalen: 132 kern.ipc.nmbclusters: 10944 kern.ipc.maxpipekva: 5341184 kern.ipc.pipes: 94 kern.ipc.pipekva: 819200 kern.ipc.pipefragretry: 0 kern.ipc.pipeallocfail: 0 kern.ipc.piperesizefail: 0 kern.ipc.piperesizeallowed: 1 kern.ipc.msgmax: 16384 kern.ipc.msgmni: 40 kern.ipc.msgmnb: 2048 kern.ipc.msgtql: 40 kern.ipc.msgssz: 8 kern.ipc.msgseg: 2048 kern.ipc.semmap: 30 kern.ipc.semmni: 10 kern.ipc.semmns: 60 kern.ipc.semmnu: 30 kern.ipc.semmsl: 60 kern.ipc.semopm: 100 kern.ipc.semume: 10 kern.ipc.semusz: 92 kern.ipc.semvmx: 32767 kern.ipc.semaem: 16384 kern.ipc.shmmax: 134217728 kern.ipc.shmmin: 1 kern.ipc.shmmni: 192 kern.ipc.shmseg: 128 kern.ipc.shmall: 8192 kern.ipc.shm_use_phys: 0 kern.ipc.shm_allow_removed: 0 kern.ipc.numopensockets: 223 kern.ipc.maxsockets: 10944 kern.ipc.nsfbufs: 2992 kern.ipc.nsfbufspeak: 5 kern.ipc.nsfbufsused: 0 ripcb: 180, 10956, 2, 42, 266 security.jail.sysvipc_allowed: 0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27CE73B8-B2DC-4EB5-A350-8259E7AFDD1A>