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):
< tcp 0 0 localhost.localdom:ldap localhost.localdo:53381
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:51077
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:54146
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:34959
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:50318
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:51081
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:34964
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:36243
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:41362
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:36240
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:49309
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:56988
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:44452
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:44451
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:39330
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:49312
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:46261
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:47551
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:60351
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:41661
VERBUNDEN
< tcp 0 0 localhost.localdom:ldap localhost.localdo:57017
VERBUNDEN
< tcp 0 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
