Re: shmget: No space on device (sshit)

2006-06-05 Thread Bill Moran
On Sun, 4 Jun 2006 21:18:50 -0700
David King [EMAIL PROTECTED] wrote:

 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?

ipcs -M or /usr/src/sys/conf/NOTES

I believe the mni portion is maximum number of identifiers.

-- 
Bill Moran
Collaborative Fusion Inc.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: shmget: No space on device (sshit)

2006-06-05 Thread David King

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?

ipcs -M or /usr/src/sys/conf/NOTES
I believe the mni portion is maximum number of identifiers.


ipcs -M shows:
shminfo:
shmmax: 134217728   (max shared memory segment size)
shmmin:   1 (min shared memory segment size)
shmmni: 192 (max number of shared memory identifiers)
shmseg: 128 (max shared memory segments per process)
shmall:8192 (max amount of shared memory in pages)

So yes, it had definitely reached its max.

So I used ipcrm to remove all of the shared memory segments, and the  
problem seems to have cleared up for now. A few rounds of simulating  
failed logins to sshit shows that it does allocate shared memory  
segments, and every time it adds an IP address it seems to allocate a  
new shared memory segment instead of finding the old one.


But from here it looks like an issue to take up with the developer,  
since it seems to be a bug. Thanks Bill for your help!

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: shmget: No space on device (sshit)

2006-06-04 Thread Bill Moran
David King [EMAIL PROTECTED] wrote:

 I'm trying to use sshit.pl from /usr/ports/secrurity/sshit, and I'm  
 having some trouble with it that I think may be a bug, or a mis- 
 configuration on my part.
 
 sshit is a Perl program that receives syslog messages (configured in  
 syslog.conf) of the form '/failed .*from (\d+\.\d+\.\d+\.\d+) /i' to  
 try to detect SSH brute-force attempts, and after X from the same IP  
 address in Y minutes, it adds them to an IPFW2 table, which has a  
 deny from rule that runs on it.
 
 sshit seems to be not working (i.e. it's never adding IP addresses to  
 the ipfw2 table I specified) and dumping many of the following  
 messages to /var/log/messages:
 May 31 10:03:03 melchoir syslogd: Logging subprocess 20716 (exec /usr/ 
 local/sbin/sshit) exited with status 28.
 
 This appears to be because of the following:
 ~# echo 'May 29 12:20:32 melchoir sshd[5707]: Failed password for  
 illegal user user1 from 61.82.52.1 port 43282 ssh2' | sshit; echo  
 Error: $?
 IPC::Shareable::SharedMem: shmget: No space left on device
 at /usr/local/lib/perl5/site_perl/5.8.8/IPC/Shareable.pm line 566
 Could not create shared memory segment: No space left on device
 at ./sshit line 295
 Error: 28
 
 As you can see, shmget seems to say that it cannot get a shared  
 memory segment. However:
 
 ~% grep SYSV /usr/src/sys/i386/conf/ROUTERKERNEL
 options SYSVSHM #SYSV-style shared memory
 options SYSVMSG #SYSV-style message queues
 options SYSVSEM #SYSV-style semaphores
 
 ~% top|grep ^Mem
 Mem: 182M Active, 23M Inact, 71M Wired, 1540K Cache, 41M Buf, 28M Free
 
 ~% sysctl -a | grep ipc.*shm
 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
 
 (that is after I turned up shmmax)
 
 Some more potentially useful information:
 
 ~% grep sshit.pl.*v[0-9] `which sshit`
 #  sshit.pl  v0.5
 
 ~% uname -a
 FreeBSD  5.3-RELEASE-p20 FreeBSD 5.3-RELEASE-p20 #2: Fri Sep  9  
 14:11:12 PDT 2005 root@:/usr/obj/usr/src/sys/ROUTERKERNEL  i386
 
 ~% pkg_info | grep sshit
 sshit-0.5   Checks for SSH/FTP bruteforce and blocks given IPs
 
 ~% perl -v
 This is perl, v5.8.8 built for i386-freebsd-64int
 
 If you have absolutely any idea, please let me know. I'm happy to do  
 some more debugging if it helps

How about the output from 'ipcs -b'.

-- 
Bill Moran

That seem right to you?

Jubal Early

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: shmget: No space on device (sshit)

2006-06-04 Thread David King

I'm trying to use sshit.pl from /usr/ports/secrurity/sshit, and I'm
having some trouble with it that I think may be a bug, or a mis-
configuration on my part. [...]

How about the output from 'ipcs -b'.


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?
Anything here that would prevent sshit from allocating more?

Message Queues:
T ID KEYMODE   OWNERGROUP QBYTES

Shared Memory:
T ID KEYMODE   OWNERGROUP  SEGSZ
m  65536 1768452979 --rw-r--r-- rootwheel  65536
m  65537 134881 --rw-r--r-- rootwheel  65536
m  65538 936011 --rw-r--r-- rootwheel  65536
m  65539  21505 --rw-r--r-- rootwheel  65536
m  65540 708471 --rw-r--r-- rootwheel  65536
m  65541 393998 --rw-r--r-- rootwheel  65536
m  65542 463840 --rw-r--r-- rootwheel  65536
m  65543 239768 --rw-r--r-- rootwheel  65536
m  65544 315355 --rw-r--r-- rootwheel  65536
m  65545 647301 --rw-r--r-- rootwheel  65536
m  65546 758220 --rw-r--r-- rootwheel  65536
m  65547 319092 --rw-r--r-- rootwheel  65536
m  65548 438209 --rw-r--r-- rootwheel  65536
m  65549 264750 --rw-r--r-- rootwheel  65536
m  65550 900372 --rw-r--r-- rootwheel  65536
m  65551 450947 --rw-r--r-- rootwheel  65536
m  65552 319143 --rw-r--r-- rootwheel  65536
m  65553 667132 --rw-r--r-- rootwheel  65536
m  65554 678503 --rw-r--r-- rootwheel  65536
m  6 205070 --rw-r--r-- rootwheel  65536
m  65556 261008 --rw-r--r-- rootwheel  65536
m  65557 746913 --rw-r--r-- rootwheel  65536
m  65558 537169 --rw-r--r-- rootwheel  65536
m  65559 148677 --rw-r--r-- rootwheel  65536
m  65560 466431 --rw-r--r-- rootwheel  65536
m  65561 847944 --rw-r--r-- rootwheel  65536
m  65562 493283 --rw-r--r-- rootwheel  65536
m  65563 291515 --rw-r--r-- rootwheel  65536
m  65564 273361 --rw-r--r-- rootwheel  65536
m  65565 361511 --rw-r--r-- rootwheel  65536
m  65566 943679 --rw-r--r-- rootwheel  65536
m  65567 104850 --rw-r--r-- rootwheel  65536
m  65568 923027 --rw-r--r-- rootwheel  65536
m  65569  99654 --rw-r--r-- rootwheel  65536
m  65570 109215 --rw-r--r-- rootwheel  65536
m  65571 151776 --rw-r--r-- rootwheel  65536
m  65572 780233 --rw-r--r-- rootwheel  65536
m  65573  36300 --rw-r--r-- rootwheel  65536
m  65574 996835 --rw-r--r-- rootwheel  65536
m  65575 905752 --rw-r--r-- rootwheel  65536
m  65576 413185 --rw-r--r-- rootwheel  65536
m  65577 738308 --rw-r--r-- rootwheel  65536
m  65578 378455 --rw-r--r-- rootwheel  65536
m  65579 292777 --rw-r--r-- rootwheel  65536
m  65580 280534 --rw-r--r-- rootwheel  65536
m  65581 922167 --rw-r--r-- rootwheel  65536
m  65582 205803 --rw-r--r-- rootwheel  65536
m  65583 843486 --rw-r--r-- rootwheel  65536
m  65584 643431 --rw-r--r-- rootwheel  65536
m  65585 619205 --rw-r--r-- rootwheel  65536
m  65586 466482 --rw-r--r-- rootwheel  65536
m  65587 842890 --rw-r--r-- rootwheel  65536
m  65588 421007 --rw-r--r-- rootwheel  65536
m  65589 123134 --rw-r--r-- rootwheel  65536
m  65590 203026 --rw-r--r-- rootwheel  65536
m  65591 126853 --rw-r--r-- rootwheel  65536
m  65592 560544 --rw-r--r-- rootwheel  65536
m  65593 777368 --rw-r--r-- rootwheel  65536
m  65594 347079 --rw-r--r-- rootwheel  65536
m  65595 548244 --rw-r--r-- rootwheel  65536
m  65596 223498 --rw-r--r-- rootwheel  65536
m  65597 211499 --rw-r--r-- rootwheel  65536
m  65598 426141 --rw-r--r-- rootwheel  65536
m  65599 929676 --rw-r--r-- rootwheel  65536
m  65600 589519 --rw-r--r-- rootwheel  65536
m  65601 238356 --rw-r--r-- rootwheel  65536
m  65602 903119 --rw-r--r-- rootwheel  65536
m  65603 742518 --rw-r--r-- rootwheel  65536
m  65604 118906 --rw-r--r-- rootwheel  65536
m  65605  12195 --rw-r--r-- rootwheel  65536
m  65606 452658 --rw-r--r-- rootwheel  65536
m  65607 779292 --rw-r--r-- rootwheel  65536
m  65608 616472 --rw-r--r-- rootwheel  65536
m  65609 581670 --rw-r--r-- rootwheel  65536
m  65610 115726 --rw-r--r-- rootwheel  65536
m  65611 760272 --rw-r--r-- rootwheel  65536
m  65612 930615 --rw-r--r-- rootwheel  65536
m  65613 

Re: shmget: No space on device (sshit)

2006-06-04 Thread Bill Moran
David King [EMAIL PROTECTED] wrote:

  I'm trying to use sshit.pl from /usr/ports/secrurity/sshit, and I'm
  having some trouble with it that I think may be a bug, or a mis-
  configuration on my part. [...]
  How about the output from 'ipcs -b'.
 
 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.

 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.

 
 Message Queues:
 T ID KEYMODE   OWNERGROUP QBYTES
 
 Shared Memory:
 T ID KEYMODE   OWNERGROUP  SEGSZ
 m  65536 1768452979 --rw-r--r-- rootwheel  65536
 m  65537 134881 --rw-r--r-- rootwheel  65536
 m  65538 936011 --rw-r--r-- rootwheel  65536
 m  65539  21505 --rw-r--r-- rootwheel  65536
 m  65540 708471 --rw-r--r-- rootwheel  65536
 m  65541 393998 --rw-r--r-- rootwheel  65536
 m  65542 463840 --rw-r--r-- rootwheel  65536
 m  65543 239768 --rw-r--r-- rootwheel  65536
 m  65544 315355 --rw-r--r-- rootwheel  65536
 m  65545 647301 --rw-r--r-- rootwheel  65536
 m  65546 758220 --rw-r--r-- rootwheel  65536
 m  65547 319092 --rw-r--r-- rootwheel  65536
 m  65548 438209 --rw-r--r-- rootwheel  65536
 m  65549 264750 --rw-r--r-- rootwheel  65536
 m  65550 900372 --rw-r--r-- rootwheel  65536
 m  65551 450947 --rw-r--r-- rootwheel  65536
 m  65552 319143 --rw-r--r-- rootwheel  65536
 m  65553 667132 --rw-r--r-- rootwheel  65536
 m  65554 678503 --rw-r--r-- rootwheel  65536
 m  6 205070 --rw-r--r-- rootwheel  65536
 m  65556 261008 --rw-r--r-- rootwheel  65536
 m  65557 746913 --rw-r--r-- rootwheel  65536
 m  65558 537169 --rw-r--r-- rootwheel  65536
 m  65559 148677 --rw-r--r-- rootwheel  65536
 m  65560 466431 --rw-r--r-- rootwheel  65536
 m  65561 847944 --rw-r--r-- rootwheel  65536
 m  65562 493283 --rw-r--r-- rootwheel  65536
 m  65563 291515 --rw-r--r-- rootwheel  65536
 m  65564 273361 --rw-r--r-- rootwheel  65536
 m  65565 361511 --rw-r--r-- rootwheel  65536
 m  65566 943679 --rw-r--r-- rootwheel  65536
 m  65567 104850 --rw-r--r-- rootwheel  65536
 m  65568 923027 --rw-r--r-- rootwheel  65536
 m  65569  99654 --rw-r--r-- rootwheel  65536
 m  65570 109215 --rw-r--r-- rootwheel  65536
 m  65571 151776 --rw-r--r-- rootwheel  65536
 m  65572 780233 --rw-r--r-- rootwheel  65536
 m  65573  36300 --rw-r--r-- rootwheel  65536
 m  65574 996835 --rw-r--r-- rootwheel  65536
 m  65575 905752 --rw-r--r-- rootwheel  65536
 m  65576 413185 --rw-r--r-- rootwheel  65536
 m  65577 738308 --rw-r--r-- rootwheel  65536
 m  65578 378455 --rw-r--r-- rootwheel  65536
 m  65579 292777 --rw-r--r-- rootwheel  65536
 m  65580 280534 --rw-r--r-- rootwheel  65536
 m  65581 922167 --rw-r--r-- rootwheel  65536
 m  65582 205803 --rw-r--r-- rootwheel  65536
 m  65583 843486 --rw-r--r-- rootwheel  65536
 m  65584 643431 --rw-r--r-- rootwheel  65536
 m  65585 619205 --rw-r--r-- rootwheel  65536
 m  65586 466482 --rw-r--r-- rootwheel  65536
 m  65587 842890 --rw-r--r-- rootwheel  65536
 m  65588 421007 --rw-r--r-- rootwheel  65536
 m  65589 123134 --rw-r--r-- rootwheel  65536
 m  65590 203026 --rw-r--r-- rootwheel  65536
 m  65591 126853 --rw-r--r-- rootwheel  65536
 m  65592 560544 --rw-r--r-- rootwheel  65536
 m  65593 777368 --rw-r--r-- rootwheel  65536
 m  65594 347079 --rw-r--r-- rootwheel  65536
 m  65595 548244 --rw-r--r-- rootwheel  65536
 m  65596 223498 --rw-r--r-- rootwheel  65536
 m  65597 211499 --rw-r--r-- rootwheel  65536
 m  65598 426141 --rw-r--r-- rootwheel  65536
 m  65599 929676 --rw-r--r-- rootwheel  65536
 m  65600 589519 --rw-r--r-- rootwheel  65536
 m  65601 238356 --rw-r--r-- rootwheel  65536
 m  65602 903119 --rw-r--r-- rootwheel  65536
 m  65603 742518 --rw-r--r-- rootwheel  65536
 m  65604 118906 --rw-r--r-- rootwheel  65536
 m  65605  12195 --rw-r--r-- root

Re: shmget: No space on device (sshit)

2006-06-04 Thread David King

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

___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


shmget: No space on device (sshit)

2006-06-03 Thread David King
I'm trying to use sshit.pl from /usr/ports/secrurity/sshit, and I'm  
having some trouble with it that I think may be a bug, or a mis- 
configuration on my part.


sshit is a Perl program that receives syslog messages (configured in  
syslog.conf) of the form '/failed .*from (\d+\.\d+\.\d+\.\d+) /i' to  
try to detect SSH brute-force attempts, and after X from the same IP  
address in Y minutes, it adds them to an IPFW2 table, which has a  
deny from rule that runs on it.


sshit seems to be not working (i.e. it's never adding IP addresses to  
the ipfw2 table I specified) and dumping many of the following  
messages to /var/log/messages:
May 31 10:03:03 melchoir syslogd: Logging subprocess 20716 (exec /usr/ 
local/sbin/sshit) exited with status 28.


This appears to be because of the following:
~# echo 'May 29 12:20:32 melchoir sshd[5707]: Failed password for  
illegal user user1 from 61.82.52.1 port 43282 ssh2' | sshit; echo  
Error: $?

IPC::Shareable::SharedMem: shmget: No space left on device
at /usr/local/lib/perl5/site_perl/5.8.8/IPC/Shareable.pm line 566
Could not create shared memory segment: No space left on device
at ./sshit line 295
Error: 28

As you can see, shmget seems to say that it cannot get a shared  
memory segment. However:


~% grep SYSV /usr/src/sys/i386/conf/ROUTERKERNEL
options SYSVSHM #SYSV-style shared memory
options SYSVMSG #SYSV-style message queues
options SYSVSEM #SYSV-style semaphores

~% top|grep ^Mem
Mem: 182M Active, 23M Inact, 71M Wired, 1540K Cache, 41M Buf, 28M Free

~% sysctl -a | grep ipc.*shm
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

(that is after I turned up shmmax)

Some more potentially useful information:

~% grep sshit.pl.*v[0-9] `which sshit`
#  sshit.pl  v0.5

~% uname -a
FreeBSD  5.3-RELEASE-p20 FreeBSD 5.3-RELEASE-p20 #2: Fri Sep  9  
14:11:12 PDT 2005 root@:/usr/obj/usr/src/sys/ROUTERKERNEL  i386


~% pkg_info | grep sshit
sshit-0.5   Checks for SSH/FTP bruteforce and blocks given IPs

~% perl -v
This is perl, v5.8.8 built for i386-freebsd-64int

If you have absolutely any idea, please let me know. I'm happy to do  
some more debugging if it helps


___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]