IMAP - maillog - Disconnected: Connection closed: read(size=xxx) failed:
I was investigating an increase in bandwidth usage in an account when I found these in /var/log/mailog
Aug 9 16:51:37 hostname dovecot[2708227]: imap(user@domain.com)<3106800><cyzf+0cfVt7JlSeS>: Disconnected: Connection closed: read(size=7992) failed: Connection reset by peer (UID FETCH running for 0.021 + waiting input/output for 3.824 secs, 60 B in + 4079873+8192 B out, state=wait-output) in=200, out=4081108, bytes=200/4081108
There's not a lot of these, 117 entries since Aug 4 in a server with some 400 - 500 email accounts but then again, numbers are big and I'm looking for an IMAP increase in bandwidth
What are these?
-
Just so you have the complete picture, I found that one email on this account had its webmail database corrupted, it wasn't loading at all with a browser error, it was the same email account that was throwing these errors for this domain (although there are more errors on other domains also, btw, so far I have found all these email accounts use webmail).
I repaired the database (from backup) and the webmail worked again, but I'm not really sure this fixed the issue since the user is out for the day (maybe the weekend) at this time.
The question remains, what are those errors?0 -
Hey there! It's possible you could have fixed it with that work - the FETCH errors like that typically mean they have a mail client (Outlook, Thunderbird, etc.) on their local desktop that is pulling their email into the client. In your case, if there was an issue with the database, it may not have been able to make a successful connection properly, leading to those connection errors.
If all of those entries are similar, that's 4M per entry, 117 entries, so about 468M of extra usage for that one account in the time period you mentioned.
0 -
Hello cPRex, sorry for the lack of timely answer.
Yes, indeed I fixed the problem with the database repair, those errors sounded bad because the "waiting input/output" part sounded like a hardware problem, but i read somewhere that the "state=wait-output" part meant that the server was waiting for I/O on the client side, not the local side.The user ended consuming about 30GB in a day because of this problem.
0 -
I'm glad to hear you were able to fix it!
0
Please sign in to leave a comment.
Comments
4 comments