On Mon, 20 Feb 2006, Rob Henderson wrote:
However, when it fails, I see the following error from imapd in the logs: imapd[24422]: [ID 839431 mail.alert] IMAP toolkit slave process crash: Unknown master response for append: <FF> I was hoping that someone might be able to interpret this error message or have other information about this problem. IMAP server: UW imapd 2004.357 under Solaris 8
This error message only occurs on SVR4 systems such as Solaris, HP-UX, AIX, etc. The underlying cause is what the BSD man pages call "the completely stupid semantics" of POSIX file locking (fcntl() system call). Systems which have the flock() system call, such as BSD (including Mac OS X) and Linux, do not have this problem.
The outcome of these "completely stupid semantics" (harsh words, but ones which I agree) is that operations which deal with a named mailbox must run in an independent subprocess. Otherwise, if the client does any such operation (DELETE, RENAME, STATUS, SCAN, COPY, APPEND) with the currently seleted mailbox as the target, the lock on the selected mailbox is lost. The most common offenders are COPY and especially APPEND (e.g., copying a message to the currently open mailbox).
There is a communication protocol between the master imapd and the subprocess. This error message is an error in the communication protocol. The fact that the error was a spurious 0xff character suggests that what really happened is that what was passed as an EOF instead of a 0xff character. That is, the master process died (perhaps because the client dropped the connection), and the slave found out by getting an EOF on the pipe.
So, although the error message is flawed (I will fix it to test for EOF), the underlying problem in your case is probably that the client dropped the connection unexpectedly. So it's probably a Thunderbird issue, not an imapd issue.
Another good thing that you can do is to dump your Solaris systems in favor of Linux or BSD. SVR4 is a very poor platform for IMAP servers, and SUN is a particularly troublesome vendor.
-- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ Imap-uw mailing list [email protected] https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
