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)
Sure. That's the point to this. You trimmed out all your config
but how many shared memory segments are you allowing? How many
If those are near 192 and 10, you may be hitting the limit on how
Anything here that would prevent sshit from allocating more?
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
ripcb: 180, 10956, 2, 42, 266
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"