[Date Prev][Date Next]
Re: "descriptor table size" errors?
Gregory K. Ruiz-Ade skrev, on 13-07-2007 22:24:
We seem to be getting errors every night a couple minutes after
logrotate rotates our logs and sends a SIGHUP to syslog-ng (to force a
Jul 11 04:02:46 csenet slapd: daemon: 1024 beyond descriptor table
Nothing is touching our slapd process (i.e., same process over several
This seems only to happen on our master LDAP server. We're using slurpd
for replication to our two slave servers.
This morning, something apparently corrupted our directory, which
apparently got replicated to our slaves; we restored the db from the
nightly dump (made from slapcat on another replica) and LDAP seems happy
We can't see anything in the logs that would lend a clue as to what
might be going on. Any suggestions as to where I should start looking?
We're running RHEL 4 with all updates applied, using RH's openldap
Looking back in the logs, it seems that the syslog message above occurs
for a couple minutes after syslog-ng is restarted, and then stops
occurring until the next time syslog-ng is restarted, but it's
apparently been happening for quite a while. Today is the first time
we've had corruption (or otherwise total failure) of the LDAP directory,
Any suggestions or help will be greatly appreciated.
We run RHAS4, with a new (IBM iron Opteron) RHL5 Server machine soon to
be deployed. I also run a home Fedora FC6 rig with the same setups and
API software specs.
All work fine, no problems.
We run syslog-ng 1.6.8. We run Buchan Milne's OpenLDAP 2.3 version
2.3.36, using his built-in BDB 4.2.52 support on RHL5 and FC6, with my
own BDB 4.2.52 libraries on RHAS4. Everything works fine on all machines.
Kudos to Buchan:
1: RHL5 and FC6 both have BDB 4.3 as standard; Buchan's srpm (and,
believe me, I refuse to install *ANY* software without it being
available as an rpm. If it's not, I bake my own - but Buchan's srpm is
far superior to anything I could bake myself) is "intelligent" enough to
see that Red Hat has given me an unstable version of BDB and substitute
a stable version - 5-patched 4.2.52 for his OpenLDAP alone - all the
other RH stuff continues to use 4.3;
2: I'm a die-hard Red Hat/CentOS person, but although those give me
unparalleled stability and mostly update without preference, OpenLDAP is
a great exception. I would not touch RHAS4/CentOS 5's OpenLDAP with a
barge pole. Fedora FC6/7 is a possible exception because it's largely up
to date, but since Buchan's stuff gives me so much modular
configurability, I'll stick with him for FC as well.
Email: tonni at hetnet dot nl