How should a cron jobb handle modify(cn=config) error?

[Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>]

We have a cn=config database with

   olcDbDirectory: /ldap/var/db/foobar-<directory version>

A cron job in a quandary can clear things up thus: Rebuild the database
in a new directory with slapadd, ldapmodify cn=config so olcDbDirectory
points at the new DB directory, and finally throw away the old DB dir.

ldapmodify -H ldapi:// -Q -Y EXTERNAL <<EOF
# hdb can have more "interesting" problems than mdb:-)
dn: olcDatabase={3}hdb,cn=config
changetype: modify
replace: olcDbDirectory
olcDbDirectory: /ldap/var/db/foobar-$NEW_DIR_VERSION
EOF

Now if ldapmodify fails, what should the cron job do - in addition to
alerting a human?

When can it assume that the new DB dir is unused and can be deleted?
...that the old DB dir can be deleted?

How complicated code should I have to examine the situation and decide
what to do?

Do we just wait for a human to fix things?  Or is it time to restart
slapd?  Yet that can fail too, so next question becomes what to do next
- reboot?  A cron job which keeps escalating the problem in order to fix
it makes me nervous - LDAP must be up.  It's load balanced, so a single
server in trouble is OK - unless the problem is a systemic one so all
servers hiccup at once.

Do others have something like this implemented?

-- 
Hallvard