2011/8/17 Dmitry Katsubo <dm...@mail.ru>:
> Dear Cyrus community,
......
> 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.
Your answer is there, you check the exit code. If non-zero then there
was a failure, generic unix scripting rule.
#!/bin/bash
cvt_cyrusdb mailboxes.db skiplist mailboxes.db.txt
RC=$?
if [ "${RC}" -ne 0 ]; then
echo "WAAAAAAH FAILED!" >&2
exit 1
fi
Bonus points for using mktemp, then mv-ing in the sucessful case and
cleaning up after yourself in the case of failure (hint, using trap
can save you lots of code here too).
--
"Genius might be described as a supreme capacity for getting its possessors
into trouble of all kinds."
-- Samuel Butler
