View Issue Details

IDProjectCategoryView StatusLast Update
0000302SOGoBackend Generalpublic2009-12-25 23:07
Reporterludovic Assigned Toludovic  
PriorityurgentSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product Versionnightly v2 
Target Version1.2.0Fixed in Version1.2.0 
Summary0000302: SOPE (or SOGo) might leak LDAP fds

The issue can be experienced with sogo-tool on large LDAP directories.

Message from James Ray on his:

=== SNIP ===
I think the sogo-tool backup is failing for my installation due to its

$ /usr/GNUstep/System/Tools/Admin/sogo-tool backup ./ ALL
<0x0x20e032b8[SOGoCache]> Cache cleanup interval set every 300.000000
seconds for memcached
<0x0x20e032b8[SOGoCache]> memcached error: unable to cache values with
subtype attributes for user z. .x.yyyy@maildomain.tld
2009-12-14 11:37:07.022 sogo-tool[444] Failed to recurse into directory

    • Too many open files
      2009-12-14 11:37:07.021 sogo-tool[444] Could not bind to the LDAP server
      auth-dir.domain.tld (389) using the bind DN:
      2009-12-14 11:37:07.022 sogo-tool[444] Could not bind to the LDAP server
      auth-dir.domain.tld (389) using the bind DN:
      2009-12-14 11:37:07.026 sogo-tool[444] File NSData.m: 922. In
      [NSDataMalloc -writeToFile:atomically:] Open (./userxyz) failed - Too
      many open files

The LDAP server stopped working after 1000 connects in a min due to the
bad internal workings of the sogo-tool I think. From what I can tell it
searches the directory and then connects to query each user individually
causing a connection flood and poor performance.

Anyone able to offer assistance in the best way I can back up SOGo? I am
currently just doing full database dumps every night.
=== SNIP ===

If the issue is exposed using sogo-tool, the issue should also be present when sogod runs as usual.

TagsNo tags attached.




2009-12-25 17:25

administrator   ~0000386

The problem, for the tool, is that everything is done in a while loop and we LDAP connections are closed (from NGLdapConnection) in the -dealloc call.

Since we're working with an autorelease pool, all items will get freed at once at the end of the runloop (so at the end of the while loop).

We should create a local autorelease pool in the loop to avoid this.



2009-12-25 23:07

administrator   ~0000387

Fixed in

Issue History

Date Modified Username Field Change
2009-12-25 16:18 ludovic New Issue
2009-12-25 16:18 ludovic Target Version => 1.2.0
2009-12-25 16:18 ludovic Status new => assigned
2009-12-25 16:18 ludovic Assigned To => ludovic
2009-12-25 17:25 ludovic Note Added: 0000386
2009-12-25 23:07 ludovic Note Added: 0000387
2009-12-25 23:07 ludovic Status assigned => resolved
2009-12-25 23:07 ludovic Fixed in Version => 1.2.0
2009-12-25 23:07 ludovic Resolution open => fixed