Are you certain that you are using UW imapd?
None of those syslog messages are from UW imapd, or at least from UW imapd
as I distribute it. Either your copy of UW imapd has been modified, or
you are actually using some other IMAP server implementation.
On Wed, 26 Dec 2007, Derek Xu wrote:
Thanks, Mark. The copy of the imapd being used was directly downloaded
from UW and thus should be unmodified.
I compared two cases -- one is using the "spam" button and the other
is the client's normal forward function, and found the following
difference in the termination message(var/log/syslog):
Case1: Using "Spam" button -- connection drop error message returned
Dec 26 10:10:14 poisson imapd[28495]: [ID 323218 mail.debug] tid= 1:
unlocking sessionLock
In contrast, in the case 2 that is using forward function ( the
operation successed without connection drop error message), a lot
more mail info has been logged:
Dec 26 10:13:20 testmachine imapd[28515]: [ID 323218 mail.debug] tid=
1: unlocking s
essionLock
Dec 26 10:13:20 testmachine imapd[28515]: [ID 453631 mail.debug] tid=
1: Adding conn
ection (serverAddr=192.168.1.50)
Dec 26 10:13:20 testmachine imapd[28515]: [ID 816976 mail.debug] tid=
1: Connection
added [1]
Dec 26 10:13:20 testmachine imapd[28515]: [ID 467101 mail.debug] tid=
1: connectionI
D=1025
Dec 26 10:13:20 testmachine imapd[28515]: [ID 805042 mail.debug] tid=
1: shared=1
Dec 26 10:13:20 testmachine imapd[28515]: [ID 982078 mail.debug] tid=
1: usedBit=0
Dec 26 10:13:20 testmachine imapd[28515]: [ID 727660 mail.debug] tid=
1: threadID=1
Dec 26 10:13:20 testmachine imapd[28515]: [ID 577507 mail.debug] tid=
1: serverAddr=
192.168.1.50
Dec 26 10:13:20 testmachine imapd[28515]: [ID 939703 mail.debug] tid=
1: AuthType=1
Dec 26 10:13:20 testmachine imapd[28515]: [ID 142272 mail.debug] tid=
1: TlsType=0
Dec 26 10:13:20 testmachine imapd[28515]: [ID 537450 mail.debug] tid=
1: SaslMech=0
Dec 26 10:13:20 testmachine imapd[28515]: [ID 625532 mail.debug] tid=
1: SaslOpt=0
Dec 26 10:13:20 testmachine imapd[28515]: [ID 339871 mail.debug] tid=
1: hostCertPat
h=/var/ldap
Dec 26 10:13:20 testmachine imapd[28515]: [ID 639905 mail.debug] tid=
1: userID=uid=
tester,ou=People,dc=testdomain,dc=com
Dec 26 10:13:21 testmachine imapd[28515]: [ID 453631 mail.debug] tid=
1: Adding conn
ection (serverAddr=192.168.1.50)
Dec 26 10:13:21 testmachine imapd[28515]: [ID 816976 mail.debug] tid=
1: Connection
added [2]
Dec 26 10:13:21 testmachine imapd[28515]: [ID 467101 mail.debug] tid=
1: connectionI
D=1026
Dec 26 10:13:21 testmachine imapd[28515]: [ID 805042 mail.debug] tid=
1: shared=1
Dec 26 10:13:21 testmachine imapd[28515]: [ID 982078 mail.debug] tid=
1: usedBit=0
Dec 26 10:13:21 testmachine imapd[28515]: [ID 727660 mail.debug] tid=
1: threadID=1
Dec 26 10:13:21 testmachine imapd[28515]: [ID 577507 mail.debug] tid=
1: serverAddr=
192.168.1.50
Dec 26 10:13:21 testmachine imapd[28515]: [ID 939703 mail.debug] tid=
1: AuthType=1
Dec 26 10:13:21 testmachine imapd[28515]: [ID 142272 mail.debug] tid=
1: TlsType=0
Dec 26 10:13:21 testmachine imapd[28515]: [ID 537450 mail.debug] tid=
1: SaslMech=0
Dec 26 10:13:21 testmachine imapd[28515]: [ID 625532 mail.debug] tid=
1: SaslOpt=0
Dec 26 10:13:21 testmachine imapd[28515]: [ID 339871 mail.debug] tid=
1: hostCertPat
h=/var/ldap
Dec 26 10:13:21 testmachine imapd[28515]: [ID 639905 mail.debug] tid=
1: userID=uid=
tester,ou=People,dc=testdomain,dc=com
Dec 26 10:13:21 testmachine imapd[28515]: [ID 234311 mail.info] Login
user=tester hos
t=testmachine [192.168.1.23]
Dec 26 10:13:21 testmachine imapd[28515]: [ID 960700 mail.info] Logout
user=tester ho
st=testmachine [192.168.1.23]
I am not sure what we can conclude from the above differences.
Derek
On Dec 25, 2007 7:35 PM, Mark Crispin <[EMAIL PROTECTED]> wrote:
Unless you have memory limits set ridiculously low (as in suitable for the
early 1980s), it is quite unlikely that imapd would fail due to lack of
memory. If it did, there would be an entry in the mail syslog reading
"IMAP toolkit crash: Out of memory".
Nor is the IMAP command "FETCH 106 BODY[HEADER]" a particularly difficult,
unexpected, or risky operation for an IMAP server to undertake.
Rather than guess at the problem, and trying all sorts of things at random
until you find the measure that fixes it, I suggest that you try a little
bit more investigation first.
As noted above, UW imapd leaves its log messages in the mail syslog. [At
least it does in unmodified UW imapd. If you have a copy of UW imapd that
was modified by a third party, the first thing to do is see if unmodified
UW imapd directly from UW works any better.] So, take a look in the mail
syslog and see if there are any interesting log messages corresponding
with the incident.
UW imapd normally logs its startup, authentication, and termination. The
last is probably the most interesting. Is there a termination message, or
did that imapd vanish without a trace? If there is a termination message,
what did the message say? That will point you towards the next step in
your debugging.
On Tue, 25 Dec 2007, Derek Xu wrote:
Hello --
I am running UW IMAP 2007. The mail client is squirrel webmail 1.4.13
with spam_buttons plugin. When I click on the "spam" button, it always
generates the following error message:
ERROR: Connection dropped by IMAP server.
Query: FETCH 106 BODY[HEADER]
I queried the squirrel webmail mailing list, they suspected it is an
IMAP-related issue. However, the mail log doesn't provide any useful
information. I just came across an article talking about bincimap and
squeirrelMail. There was a similar problem and the suggested solution
is use /usr/local/bin/softlimit to set memory resource,such as stack
segment per process, physical pages per process and data segment per
process, for bincimap to much higher values.
http://osdir.com/ml/mail.imap.binc.general/2003-10/msg00089.html
I wonder if there is any similar way to change the memory resource
for UW imapd. What normally cause imapd drop connections with clients?
Thanks,
Derek
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
[email protected]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
