[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Old Post: Re: Unexpected Shutdown
>On Wed, 09 Feb 2005 21:56:04 -0800, Howard Chu <hyc@symas.com> wrote:
> David Brown wrote:
>
> >Hi All,
> >
> >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:
> >http://www.openldap.org/lists/openldap-software/200403/msg00785.html
> >
> >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
> >went).
> >
> >
> 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.
>
Thanks Howard,
I have found that the problem was caused by the slapd_db_stat -m
command. I was running this perioically (as root) against the database
and have found that if a bdb transaction log is being created at the
exact same time the command is running that the new log file is owned
by root and causes OpenLDAP to stop answering queries. The dbstat
script only runs for approx 0.04 seconds (on our system) so this
explains why it was only happening every so often and not on every
transaction file creation.
Have slapped myself on the wrist and warned myself not to do it again :o)
David
> 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
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
>
>