Dear Cyrus community,
I've got a question concerning the usage of "cvt_cyrusdb" utility. Nor
recently I've noticed that when I execute the following command:
> # cvt_cyrusdb /var/lib/cyrus/mailboxes.db skiplist
> /var/lib/cyrus/mailboxes.db.txt flat
nothing is printed on output and "mailboxes.db.txt" is not created (all
paths and files are valid). I've decided to "strace" cvt_cyrusdb and
find out that it exits after some manipulation with /var/lib/cyrus/db/*
Later on I've discovered that db was corrupted or was not correctly
migrated to new DB version:
log:
> cyrus/notify[18159]: DBERROR db5: PANIC: fatal region error detected; run
> recovery
> cyrus/notify[18159]: DBERROR: critical database situation
Finally I've removed /var/lib/cyrus/db/* (and the contents have been
re-created by Cyrus), and then the above mentioned cvt_cyrusdb command
started to work perfectly OK.
My question to community is:
If cvt_cyrusdb behaviour depends on correctness of db, then I cannot
rely on this utility for backup purposes, because if something goes
wrong with db, the utility _silently_ exits (one need to check logs?). I
think, that is not good.
I have digged the code and found the following in
lib/cyrusdb_berkeley.c:103:
static void db_panic(DB_ENV *dbenv __attribute__((unused)),
int errno __attribute__((unused)))
{
syslog(LOG_CRIT, "DBERROR: critical database situation");
/* but don't bounce mail */
exit(EC_TEMPFAIL);
}
I believe this behaviour is OK for imapd server, but what about command
line utility? In any case having exit() call in such an "unexpected"
place (callback!) seems to be not good, as the process terminates
suddenly and someone may spend time to find out the actual exit point. I
believe that more correct behaviour would be to raise the error flag,
and return the error code from init() function.
And what is sad, that the functioning of cvt_cyrusdb depends on many
objects, which it does not direclty operate with.
--
With best regards,
Dmitry
