Re: [SOGo] SOGo not releasing tcp spockets?
On 23/01/13 03:18, John Bieling wrote: Glad I could help, will this be fixed in 2.0.4? Or is it already fixed in the current codebase (git clone...)? It's fixed in git and will be part of 2.0.4. -- Ludovic Marcotte +1.514.755.3630 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] SOGo not releasing tcp spockets?
Glad I could help, will this be fixed in 2.0.4? Or is it already fixed in the current codebase (git clone...)? Thanks John Am 23.01.2013 00:50, schrieb Jean Raby: On 13-01-18 1:41 PM, John Bieling wrote: I investigated the problem further. I dumped the output of netstat before and after I restarted sogo. Before the restart (running 12 h) I had 280 conns (steadily increasing all day), after the restart I was back to 40. The diff shows that almost all of the persistent connections, which only go away by restarting sogo are somehow *ldap* related: (VERBUNDEN = ESTABLISHED): < tcp0 0 localhost.localdom:ldap localhost.localdo:53381 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:51077 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:54146 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:34959 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:50318 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:51081 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:34964 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:36243 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:41362 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:36240 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:49309 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:56988 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:44452 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:44451 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:39330 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:49312 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:46261 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:47551 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:60351 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:41661 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:57017 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:46264 VERBUNDEN ... These ldap conns are used to authenticate any sogo related http/webdav request with the local ldap server, right? Why do they stay? Is it possible to tell ldap to release these connections after a timeout? Is it possible to switch to a socket-based-communictaion? Thanks for pointing that out, there was a leak in the error path of the password checking code. Now fixed: https://github.com/inverse-inc/sogo/commit/9e38c5060ab161704e86398475f36aca105d2404 Thanks for your time John On 01/17/2013 12:04 PM, John Bieling wrote: My sogo installation is running on a virtuozo system (server4you.com) and I have a limit of 1200 "numtcpsock". If I sync my adressbook via thunderbird, I can see via cat /proc/user_beancounters that the number of held numtcpsock is going up. But it is not going down again, it just stays there. Now if my server runs for about a day, I reach the limit, which will "disconnect" my server from the outside, since no new connections can be established. Before reaching the limit, I can ssh into the maschine and restart sogo and the "numtcpsock" value drops from about 1000 back to 50 (which is normal). This is now automated by a cron job, but why is that happening? Has someone else experienced this? In my sogo profile I have setup an extra IMAP account (gmx.de) and when I click through the gmx folders in the sogo web-interface, for each folder-click the "numtcpsock" value increases by 1 or 2 as well. And is not going back down. Any Idea? The incomming connections vor CardDAV and CalDAV are http request, right? Can I tweak something there? Thanks John -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] SOGo not releasing tcp spockets?
On 13-01-18 1:41 PM, John Bieling wrote: I investigated the problem further. I dumped the output of netstat before and after I restarted sogo. Before the restart (running 12 h) I had 280 conns (steadily increasing all day), after the restart I was back to 40. The diff shows that almost all of the persistent connections, which only go away by restarting sogo are somehow *ldap* related: (VERBUNDEN = ESTABLISHED): < tcp0 0 localhost.localdom:ldap localhost.localdo:53381 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:51077 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:54146 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:34959 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:50318 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:51081 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:34964 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:36243 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:41362 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:36240 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:49309 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:56988 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:44452 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:44451 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:39330 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:49312 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:46261 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:47551 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:60351 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:41661 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:57017 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:46264 VERBUNDEN ... These ldap conns are used to authenticate any sogo related http/webdav request with the local ldap server, right? Why do they stay? Is it possible to tell ldap to release these connections after a timeout? Is it possible to switch to a socket-based-communictaion? Thanks for pointing that out, there was a leak in the error path of the password checking code. Now fixed: https://github.com/inverse-inc/sogo/commit/9e38c5060ab161704e86398475f36aca105d2404 Thanks for your time John On 01/17/2013 12:04 PM, John Bieling wrote: My sogo installation is running on a virtuozo system (server4you.com) and I have a limit of 1200 "numtcpsock". If I sync my adressbook via thunderbird, I can see via cat /proc/user_beancounters that the number of held numtcpsock is going up. But it is not going down again, it just stays there. Now if my server runs for about a day, I reach the limit, which will "disconnect" my server from the outside, since no new connections can be established. Before reaching the limit, I can ssh into the maschine and restart sogo and the "numtcpsock" value drops from about 1000 back to 50 (which is normal). This is now automated by a cron job, but why is that happening? Has someone else experienced this? In my sogo profile I have setup an extra IMAP account (gmx.de) and when I click through the gmx folders in the sogo web-interface, for each folder-click the "numtcpsock" value increases by 1 or 2 as well. And is not going back down. Any Idea? The incomming connections vor CardDAV and CalDAV are http request, right? Can I tweak something there? Thanks John -- Jean Raby jr...@inverse.ca :: +1.514.447.4918 (x120) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence (www.packetfence.org) -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] SOGo not releasing tcp spockets?
I investigated the problem further. I dumped the output of netstat before and after I restarted sogo. Before the restart (running 12 h) I had 280 conns (steadily increasing all day), after the restart I was back to 40. The diff shows that almost all of the persistent connections, which only go away by restarting sogo are somehow *ldap* related: (VERBUNDEN = ESTABLISHED): < tcp0 0 localhost.localdom:ldap localhost.localdo:53381 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:51077 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:54146 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:34959 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:50318 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:51081 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:34964 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:36243 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:41362 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:36240 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:49309 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:56988 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:44452 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:44451 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:39330 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:49312 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:46261 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:47551 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:60351 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:41661 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:57017 VERBUNDEN < tcp0 0 localhost.localdom:ldap localhost.localdo:46264 VERBUNDEN ... These ldap conns are used to authenticate any sogo related http/webdav request with the local ldap server, right? Why do they stay? Is it possible to tell ldap to release these connections after a timeout? Is it possible to switch to a socket-based-communictaion? Thanks for your time John On 01/17/2013 12:04 PM, John Bieling wrote: My sogo installation is running on a virtuozo system (server4you.com) and I have a limit of 1200 "numtcpsock". If I sync my adressbook via thunderbird, I can see via cat /proc/user_beancounters that the number of held numtcpsock is going up. But it is not going down again, it just stays there. Now if my server runs for about a day, I reach the limit, which will "disconnect" my server from the outside, since no new connections can be established. Before reaching the limit, I can ssh into the maschine and restart sogo and the "numtcpsock" value drops from about 1000 back to 50 (which is normal). This is now automated by a cron job, but why is that happening? Has someone else experienced this? In my sogo profile I have setup an extra IMAP account (gmx.de) and when I click through the gmx folders in the sogo web-interface, for each folder-click the "numtcpsock" value increases by 1 or 2 as well. And is not going back down. Any Idea? The incomming connections vor CardDAV and CalDAV are http request, right? Can I tweak something there? Thanks John -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] SOGo not releasing tcp spockets?
My sogo installation is running on a virtuozo system (server4you.com) and I have a limit of 1200 "numtcpsock". If I sync my adressbook via thunderbird, I can see via cat /proc/user_beancounters that the number of held numtcpsock is going up. But it is not going down again, it just stays there. Now if my server runs for about a day, I reach the limit, which will "disconnect" my server from the outside, since no new connections can be established. Before reaching the limit, I can ssh into the maschine and restart sogo and the "numtcpsock" value drops from about 1000 back to 50 (which is normal). This is now automated by a cron job, but why is that happening? Has someone else experienced this? In my sogo profile I have setup an extra IMAP account (gmx.de) and when I click through the gmx folders in the sogo web-interface, for each folder-click the "numtcpsock" value increases by 1 or 2 as well. And is not going back down. Any Idea? The incomming connections vor CardDAV and CalDAV are http request, right? Can I tweak something there? Thanks John -- users@sogo.nu https://inverse.ca/sogo/lists
