hyc@symas.com wrote:
ando@sys-net.it wrote:
hyc@symas.com wrote:
ando@sys-net.it wrote:
When slapadd'ing -q, existing database log files seem to become unusable. If this is correct, as it seems to be, slapadd could refuse to start with -q if log files are present, or, for example, remove the logs if -qq.
I guess we could add that check. The docs already say that if an error occurs, the entire database will be unusable. As such, you should only use it for initially populating a database, not for adding to an existing one.
The story is that I placed logs in a separate directory and I forgot to clean them up when regenerating the DB after removing the database files :)
Ugh. I don't see how we can reliably detect this case.
In what way do the logs become unusable? I've tried to reproduce this situation and see no errors of any kind.
E.g., sh run test001 rm testrun/db.1.a/{alock,*db*} ../servers/slapd/slapadd -q -f testrun/slapd.1.conf -l testdata/test-ordered.ldif (the above works fine) ../servers/slapd/slapd -f testrun/slapd.1.conf ... (works fine)
db_stat -h testrun/db.1.a -l
(no complaints there either)
Initially, I thought your check was not much representative, since test001 doesn't do any writes. In my original case, I forgot to mention that DB_LOG_AUTOREMOVE was set. So I tried that configuration and manually ran the load of test008, resulting in creating multiple logs, part of which were removed. Then I ran the commands you suggested above, but nothing happened, so I'm at a loss. In fact, old log files were immediately removed by slapd itself, and log files numbering correctly restarted from where it left.
Probably I was chasing a red herring. p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
-
ando＠sys-net.it