On Tue, Feb 28, 2006, Paul J Stevens <[EMAIL PROTECTED]> said:

> Aaron Stone wrote:
>> This fixes it for me:
>> 
>> --- ../dbmail/imapd.c   2006-02-28 04:15:22.556837664 -0800
>> +++ imapd.c     2006-02-28 10:16:50.398784536 -0800
>>   case 0:
>>           /* child process */
>>           drop_privileges(config.serverUser, config.serverGroup);
>>           result = StartServer(&config);
>>           trace(TRACE_INFO, "%s,%s: server done, restart = [%d]",
>>                           __FILE__, __func__, result);
>> -
>> +         exit(result);
> 
> Looks like on-target to me :-).

I'm away from my dev box until 6pm -- would you mind checking in this fix?
I also think that we should review the other daemons to apply the same
fix-pattern. The stress test that every daemon should pass:

for i in `seq 1 10`; do kill -HUP `cat /var/run/dbmail-*.pid`; done

I had a little fun with the imap daemon this morning, and did this:

while [ 1 -eq 1 ]; do kill -HUP...
and eventually smashed the signal stack ;-) The daemon code held up until
the stack was smashed, though!

> The server code offers many opportunities for redesign (understatement).
> That's very much a set target for post-2.2 development, as far as I am
> concerned.

Agreed. No rush replacing something what works for now.
 
> But bugs in the current, simple setup should and will be fixed during
> 2.2's lifetime. I'm still a bit unclear though as to why these problems
> didn't surface earlier.

Yeah, weird. Let's get 2.1.4 out the door! :-D

Aaron

Reply via email to