Just to clarify - subject on original post was wrong - version is 2.4.36.
From: Aaron Bennett Sent: Tuesday, December 3, 2013 9:58 AM To: 'openldap-technical@openldap.org' Subject: 2.4.26 : too many open files
Hi,
I just ran into this yesterday on CentOS 6 / OpenLdap 2.4.36, my own build against bdb 5.1.29 and OpenSSL.
Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): /var/lib/ldap/log.0000032796: log file unreadable: Too many open files Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: Too many open files Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: fatal region error detected; run recovery Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: fatal region error detected; run recovery Dec 2 16:55:40 animal slapd[13735]: null_callback : error code 0x50
I never did anything to change the default process limit, looks like it's set to 1024 in /proc/$(pidof slapd)/limits.
Is there anything I can do short of an automatic restart to prevent that from cropping up again? I have an MMR via Syncrepl setup with nothing too complicated; can't think of any reason offhand that slapd would need to have more than 1024 files open.
Best,
Aaron
--- Aaron Bennett Manager of Systems Administration Clark University ITS W:508.793.7315
On Tue, Dec 3, 2013 at 6:59 AM, Aaron Bennett abennett@clarku.edu wrote:
Just to clarify – subject on original post was wrong – version is 2.4.36.
From: Aaron Bennett Sent: Tuesday, December 3, 2013 9:58 AM To: 'openldap-technical@openldap.org' Subject: 2.4.26 : too many open files
I just ran into this yesterday on CentOS 6 / OpenLdap 2.4.36, my own build against bdb 5.1.29 and OpenSSL.
Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): /var/lib/ldap/log.0000032796: log file unreadable: Too many open files Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: Too many open files Is there anything I can do short of an automatic restart to prevent that from cropping up again? I have an MMR via Syncrepl setup with nothing too complicated; can’t think of any reason offhand that slapd would need to have more than 1024 files open.
I've bumped up against this too on our CentOS 5 mail servers. It seems there are various variables that can cause this limit to get hit. Google for "openldap too many open files" and you'll see several different cases for this (built with tcpwrappers, default ulimit soft and hard limits, etc).
In my case, it was too many incoming TCP connections, not actually the number of open files on the filesystem. To fix it, I just added another ldap server: I made a third VM (another slave ldap server) and added it to the load balancer. If I ever start to bump up against it again, I'll make a fourth one (not likely, it's part of a declining system as customers request migration to the newer system).
No doubt that's not the answer you are looking for, but it works for my simple case. ...Todd
I have the same problem. Any solutions?
2013/12/14 Todd Lyons tlyons@ivenue.com
On Tue, Dec 3, 2013 at 6:59 AM, Aaron Bennett abennett@clarku.edu wrote:
Just to clarify – subject on original post was wrong – version is 2.4.36.
From: Aaron Bennett Sent: Tuesday, December 3, 2013 9:58 AM To: 'openldap-technical@openldap.org' Subject: 2.4.26 : too many open files
I just ran into this yesterday on CentOS 6 / OpenLdap 2.4.36, my own
build
against bdb 5.1.29 and OpenSSL.
Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): /var/lib/ldap/log.0000032796: log file unreadable: Too many open files Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: Too
many
open files Is there anything I can do short of an automatic restart to prevent that from cropping up again? I have an MMR via Syncrepl setup with nothing
too
complicated; can’t think of any reason offhand that slapd would need to
have
more than 1024 files open.
I've bumped up against this too on our CentOS 5 mail servers. It seems there are various variables that can cause this limit to get hit. Google for "openldap too many open files" and you'll see several different cases for this (built with tcpwrappers, default ulimit soft and hard limits, etc).
In my case, it was too many incoming TCP connections, not actually the number of open files on the filesystem. To fix it, I just added another ldap server: I made a third VM (another slave ldap server) and added it to the load balancer. If I ever start to bump up against it again, I'll make a fourth one (not likely, it's part of a declining system as customers request migration to the newer system).
No doubt that's not the answer you are looking for, but it works for my simple case. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine
Am Sat, 14 Dec 2013 16:12:59 +0800 schrieb Ferne Quinlan shimmy886@gmail.com:
I have the same problem. Any solutions?
man bash(1) section ulimit. ulimit -Hn8192 -Sn4096
-Dieter
2013/12/14 Todd Lyons tlyons@ivenue.com
On Tue, Dec 3, 2013 at 6:59 AM, Aaron Bennett abennett@clarku.edu wrote:
Just to clarify – subject on original post was wrong – version is 2.4.36.
From: Aaron Bennett Sent: Tuesday, December 3, 2013 9:58 AM To: 'openldap-technical@openldap.org' Subject: 2.4.26 : too many open files
I just ran into this yesterday on CentOS 6 / OpenLdap 2.4.36, my own
build
against bdb 5.1.29 and OpenSSL.
Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): /var/lib/ldap/log.0000032796: log file unreadable: Too many open files Dec 2 16:55:40 animal slapd[13735]: bdb(dc=clarku,dc=edu): PANIC: Too
many
open files Is there anything I can do short of an automatic restart to prevent that from cropping up again? I have an MMR via Syncrepl setup with nothing
too
complicated; can’t think of any reason offhand that slapd would need to
have
more than 1024 files open.
I've bumped up against this too on our CentOS 5 mail servers. It seems there are various variables that can cause this limit to get hit. Google for "openldap too many open files" and you'll see several different cases for this (built with tcpwrappers, default ulimit soft and hard limits, etc).
In my case, it was too many incoming TCP connections, not actually the number of open files on the filesystem. To fix it, I just added another ldap server: I made a third VM (another slave ldap server) and added it to the load balancer. If I ever start to bump up against it again, I'll make a fourth one (not likely, it's part of a declining system as customers request migration to the newer system).
No doubt that's not the answer you are looking for, but it works for my simple case. ...Todd -- The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to. --John Levine
openldap-technical@openldap.org
-
Aaron Bennett -
Dieter Klünter -
Ferne Quinlan -
Todd Lyons