[SSSD] SSSD + CYRUS/IMAP + LDAP + NSS caching = constantly growing sssd_be memory usage?
Mark London
mrl at psfc.mit.edu
Sun Oct 23 01:50:37 UTC 2011
Dmitri - I added valgrind to the sssd_be command, and didn't get any
error messages except for a bunch of these messages:
==30135== Warning: invalid file descriptor -1 in syscall close()
I believe these are minor, according to what I've read on the web.
Here's another question. When I turn on debugging, I get the following
log files:
-rw------- 1 root root 208 Oct 22 21:36 sssd.log
-rw------- 1 root root 30970503 Oct 22 17:27 sssd_nss.log
-rw------- 1 root root 1913856 Oct 22 17:27 sssd_pam.log
-rw------- 1 root root 0 Oct 22 16:58 sssd_PSFC.log
My domain is PSFC, yet the sssd_PSFC.log file is empty. Is that normal
to be empty, even with debug set to 10? I believe that's the log file
that the sssd_be process logs to.
- Mark
dpal at redhat.com wrote:
> On 10/21/2011 03:09 PM, Mark London wrote:
>> Hi - I've compiled and installed the latest version of SSSD (1.6.1),
>> with caching enabled, for a Redhat 6 computer running CYRUS IMAP mail
>> server software (with SASL). Users are authenticated via LDAP, and
>> the LDAP server is running as part of a Windows domain server. Mail
>> is sent using sendmail, with SMTP authentication. We have
>> appropriately 200 users (who read their mail using various
>> applications, including the server's Squirrelmail webmail interface).
>>
>> Using both the version of SSSD that came with Redhat 6 and the newly
>> compiled, the sssd_be process will constantly increase it's memory
>> usage over time. Within a day, the process is now using up 2G:
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+
>> COMMAND
>> 22900 root 20 0 2002m 1.7g 5628 S 0.0 14.8 9:41.42 sssd_be
>>
>> Why is there a constant need for extra memory, and is the amount of
>> memory being used, "normal" for a mail server, that only 200 users?
>> Here is my sssd.conf file. Thanks for any suggestions or help that
>> anyone can provide. - Mark
>
> Seems like a time to run Valgrind. Looks like a leak to me ...
>
>> ----------------------------- sssd.conf --------------------------------
>> [sssd]
>> config_file_version = 2
>> # Number of times services should attempt to reconnect in the
>> # event of a crash or restart before they give up
>> reconnection_retries = 3
>>
>> # If a back end is particularly slow you can raise this timeout here
>> sbus_timeout = 30
>> services = nss, pam
>>
>> # SSSD will not start if you do not configure any domains.
>> # Add new domain configurations as [domain/<NAME>] sections, and
>> # then add the list of domains (in the order you want them to be
>> # queried) to the "domains" attribute below and uncomment it.
>> ; domains = LOCAL,LDAP
>>
>> domains = PSFC
>>
>> [nss]
>> # The following prevents SSSD from searching for the root user/group in
>> # all domains (you can add here a comma-separated list of system accounts that
>> # are always going to be /etc/passwd users, or that you want to filter out).
>> filter_groups = root
>> filter_users = root
>> reconnection_retries = 3
>> debug_level = 0
>>
>> # The entry_cache_timeout indicates the number of seconds to retain an
>> # entry in cache before it is considered stale and must block to refresh.
>> # The entry_cache_nowait_timeout indicates the number of seconds to
>> # wait before updating the cache out-of-band. (NSS requests will still
>> # be returned from cache until the full entry_cache_timeout). Setting this
>> # value to 0 turns this feature off (default).
>> #entry_cache_timeout = 600
>> #entry_cache_nowait_timeout = 300
>>
>> [pam]
>> reconnection_retries = 3
>> debug_level = 0
>>
>> # LDAP domain where the LDAP server is an Active Directory server.
>>
>> [domain/PSFC]
>> description = LDAP domain with AD server
>> enumerate = true
>> min_id = 501
>> cache_credentials = TRUE
>>
>> id_provider = ldap
>> chpass_provider = none
>> auth_provider = ldap
>> ldap_uri = ldaps://xxxxxxxx
>> ldap_tls_cacertdir = /etc/openldap/cacerts
>> ldap_schema = rfc2307bis
>> ldap_search_base = dc=psfc,dc=mit,dc=edu
>> ldap_user_search_base = dc=psfc,dc=mit,dc=edu
>> ldap_group_search_base = dc=psfc,dc=mit,dc=edu
>> ldap_default_bind_dn = CN=ADldapreadonly,OU=Computer Group,OU=PSFC Users,DC=psfc,DC=mit,DC=edu
>> ldap_default_authtok_type = password
>> ldap_default_authtok = ldapread
>> ldap_user_object_class = person
>> ldap_user_name = sAMAccountName
>> ldap_user_uid_number = msSFU30UidNumber
>> ldap_user_gid_number = msSFU30GidNumber
>> ldap_user_home_directory = msSFU30HomeDirectory
>> ldap_user_shell = msSFU30LoginShell
>> ldap_user_principal = userPrincipalName
>> ldap_group_object_class = group
>> ldap_group_member = msSFU30PosixMember
>> ldap_user_member_of = msSFU30PosixMemberOf
>> ldap_group_name = name
>> ldap_group_gid_number = msSFU30GidNumber
>> ldap_force_upper_case_realm = True
>>
>>
>>
>> _______________________________________________
>> sssd-devel mailing list
>> sssd-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/sssd-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-devel/attachments/20111022/2fd59ce3/attachment.html>
More information about the sssd-devel
mailing list