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 reload):
Jul 11 04:02:46 csenet slapd[8823]: daemon: 1024 beyond descriptor table size 1024
Nothing is touching our slapd process (i.e., same process over several days.)
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 again.
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 packages (2.2.13).
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, though.
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:
2 surmises:
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.
Best,
--Tonni