[Date Prev][Date Next]
Re: running slapcat on a live openldap installation?
- To: Adam Williams <firstname.lastname@example.org>
- Subject: Re: running slapcat on a live openldap installation?
- From: Philip Guenther <email@example.com>
- Date: Mon, 22 Jun 2009 18:45:57 -0700
- Cc: firstname.lastname@example.org
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1245721493; bh=HQSakASPnchBTeJI2uo/Aw4KCOq6uGsCBrIq 56Nb8vU=; h=Received:X-BATV:X-DKIM:DKIM-Signature:X-DKIM:Date:From: X-X-Sender:To:cc:Subject:In-Reply-To:Message-ID:References: User-Agent:MIME-Version:Content-Type; b=Uj9b4tDzqWnCelYEUbJqvXZ/9j VPN7NXe7UfwJdbHB/KrZgd38+HKpSgDZ3v+LU0erDA9EaSFGn4IZwBZs6AQFFYlwEVr gADONTCmPrwf3Al5Haopww4kc5Qh3iSXSYeHrqk3k71jGQnjYhNqCrN2j2mWYHPnw8g iVMRCBpNaWU=
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1245721558; bh=HQSakASPnchBTeJI2uo/Aw4KCOq6uGsCBrIq5 6Nb8vU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID: References:MIME-Version:Content-Type; b=hjXVuT5FrHABOJ/twARVQWnCfP yNa4tqX513RmG2l4mz7ImDPN8BsrYFF9JxsLiUh9t/mko3rjh/ahOZIoOJeXwEV2ZBX j3QWhUuZTlE2k7UehXJHtezCdPN1MUG52UNEp+m8FPCgmMmMAlrKWayzkkz5pAl+mma Y01zGkW2Gcw=
- In-reply-to: <4A3FF831.email@example.com>
- References: <4A3FF831.firstname.lastname@example.org>
- User-agent: Alpine 2.00 (BSO 1167 2008-08-23)
On Mon, 22 Jun 2009, Adam Williams wrote:
> On the one on roark when I run slapcat it errors, why is that?:
> [root@roark ~]# slapcat -v -l /root/backup.ldif -b "dc=mdah,dc=state,dc=ms,dc=us"
> bdb_db_open: database "dc=mdah,dc=state,dc=ms,dc=us": unclean shutdown
> detected; attempting recovery.
> bdb_db_open: database "dc=mdah,dc=state,dc=ms,dc=us": recovery skipped in
> read-only mode. Run manual recovery if errors are encountered.
> bdb_db_open: database "dc=mdah,dc=state,dc=ms,dc=us": alock_recover failed
> bdb_db_close: database "dc=mdah,dc=state,dc=ms,dc=us": alock_close failed
> backend_startup_one: bi_db_open failed! (-1)
> slap_startup failed
I'm not sure if this is *the* problem for your situation, but it can
certainly be *a* problem: if you run slapd as a non-root user or with the
-U option to change its user id, then you should be running slapcat as
that same user.
Why? Because all the programs that open a Sleepycat/Berkeley DB
environment should be run as the same user. Otherwise, a transaction log
file may be created by the wrong user, making it inaccessable by the other
user, which will cause a database panic. Yes, even a (read-only) slapcat
process will create transaction log records. It only happens if the
transaction log is close to rolling over to the next file, making it a
small window, but I saw it happen multiple times with a different project
using BDB, so I know lightening can strike repeatedly.
If this is what happened then slapd will have died and you'll need to
manually chown the transaction log files to the correct user.
The other thought is that the alock subsystem mentioned in the error
messages depends on being able to hold kernel locks (fcntl() or lockf())
on a file in the BDB environment directory. If the filesystem where that
directory is located doesn't support file locks (NFS?) or the system has a
hard limit on the number of locks allocated, then this may fail. (But I
would expect you to see those failures during slapd startup too...)