shmget: No space on device (sshit)

David King dking at
Sun Jun 4 21:19:06 PDT 2006

>> 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  

# 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

More information about the freebsd-questions mailing list