[Date Prev][Date Next]
Re: Old Post: Re: Unexpected Shutdown
David Brown wrote:
Assuming that your slapd runs as a non-root userID there is no way for
anything in the OpenLDAP processes to suddenly change the ownership of
these files to root. As such, the only explanation is that someone on
your system used a tool (like slapadd, slapindex, or db_load) while
running as root, made changes to the database which resulted in the
creation of a new log file owned by root, and left things that way.
I'm having a bit of a problem with one of our OpenLDAP 2.2.20 servers
(running on RHEL3 with bdb 4.3.21 - I know 4.3.21 is not recommended
but I'll be upgrading to 2.2.23 soon and will move to bdb 4.2.....
then). We have 3 servers, 1 master and 2 syncrepl slaves. LDAP1
(Master) and LDAP3 (slave) have no problems but LDAP2 (slave) does.
The old post referenced at:
describes the exact same error I am seeing. Brief rundown of error is
every now and then (have seen it twice today) any LDAP query returns
the error "80 Internal (implementation specific) error". I find that
one of the bdb logfiles is owned by root. Once i do an LDAP restart
(restart script includes a checkpoint and a db_recover), OpenLDAP
works fine again.
1. Has anyone seen this error before and if so, what causes it, how do
i fix it etc etc
2. Robert (from old post) said that he might increase the log file
size and see how it goes but didn't post any further info to the list.
Anyone out there know if this fixed the problem (or Robert if you're
still on this list / email address could you let me know how you
You can minimize the trouble by setting the setgid bit on the directory
where the log files are stored, and making sure that root's umask is
002. Of course, having root run around with umask 002 in general is a
bad idea, so it's a tradeoff.
The best fix is to find whoever is doing this and slap their hands...
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support