On Tue, February 28, 2006 3:42 pm, Aaron Stone wrote: > 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 >
Guys before 2.1.4 rel, what about that memory leak issue in imapd?, did you find a workaround? This is the malloc for () keys in the command parser I am talking about. -leif > > Aaron > > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > >
