Re: Unexpected database recovery

2003-11-20 Thread Rob Siemborski
On Thu, 20 Nov 2003, Henrique de Moraes Holschuh wrote: > IMHO all that pid tracking code should be added to 2.1 as well. 2.1 is going to be basically end-of-life (barring currently unforseen issues) when I release 2.1.16 later today... and as such we've been trying to avoid significant code chan

Re: Unexpected database recovery

2003-11-20 Thread Richard Gilbert
> > Yesterday I applied John Wade's lock_flock patch to the version of Cyrus > > imapd we were already running, i.e. 2.1.14 and rebuilt and reinstalled. > > cyrus-imapd was restarted at 5 am this morning to minimise inconvenience > > to users. I was surprised to find that the system was unavailabl

Re: Unexpected database recovery

2003-11-20 Thread Henrique de Moraes Holschuh
On Thu, 20 Nov 2003, Philipp Sacha wrote: > I could reproduce stucking behaviour of lmtp by starting cyrus with 5 > preforked "lmtpd -a" processes. When i kill that processes manually > and then try to telnet to port lmtp on the mailserver, i have a stuck > lmptd. That means that port lmtp is op

Re: Unexpected database recovery

2003-11-19 Thread Henrique de Moraes Holschuh
One with deadlock problems and thinking of using the flock patch should read the stuff in https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=1177 The POSIX alarm fix for the timeout/deadlocks stuff is working just fine here. Unfortunately Philipp Sacha didn't reply yet to give us a second testimony

Re: Unexpected database recovery

2003-11-19 Thread Rob Siemborski
On Wed, 19 Nov 2003, Richard Gilbert wrote: > Yesterday I applied John Wade's lock_flock patch to the version of Cyrus > impad we were already running, i.e. 2.1.14 and rebuilt and reinstalled. > cyrus-imapd was restarted at 5 am this morning to minimise inconvenience > to users. I was surprised t