cvt_cyrusdb utility does not work if /var/lib/cyrus/db is inconsistent

[Greg Banks]

On 18/08/11 07:26, Greg Banks wrote:
>
>
> Sent from my iPhone
>
> On 18/08/2011, at 3:09, Michael Loftis <mloftis at wgops.com> wrote:
>
>> 2011/8/17 Dmitry Katsubo <dma_k at mail.ru>:
>>>
>>
>>>
>>>
>>> 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.

I'm not convinced that returning an error code in such a case is either 
feasible or helpful, particularly as all the calling code (either server 
or commandline utility) is almost certainly going to respond to any 
error initialising the database by doing exactly the same thing, i.e. 
logging an error message and exiting with a failure code.

>>>
>>> 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.
>
> Sure, but Dmitry does have a point that the error message appearing 
> only in syslog is an unexpected behaviour for a commandline utility.
>
> This is a widespread issue in Cyrus, where lots of common code was 
> clearly designed to live in a server, and it has made adding unit 
> tests that little bit more challenging. For example the unit test 
> framework now intercepts calls to the exit() libc routine and turns 
> that into a longjmp() out to the test failure code. It also intercepts 
> syslog() and pattern matches the message so that tests can pass or 
> fail depending on the occurrence or not of log messages.
>
> There's also the opposite problem of error handling code which calls 
> both syslog and fprintf(stderr), one after the other. That's just 
> silly, especially given that many modern syslog implementations have a 
> LOG_STDERR flag that will copy all syslog messages to stderr also.

Incidentally, there is a bugzilla for this

https://bugzilla.cyrusimap.org/show_bug.cgi?id=2924

with a very old patch from Florian Pflug.

Dmitry, if you're able to contribute perhaps you could update that patch 
for the 2.4 and master branches, and also remove some of the duplicated 
syslog+stderr logging calls?  I'm sure it would be much appreciated.

-- 
Greg.