Bug 5836 - (int-144429) POP3 TCP connection is left open leading to locking issues
(int-144429)
: POP3 TCP connection is left open leading to locking issues
Status: RESOLVED FIXED
Product: Email
General
: 5.0/(2.2009.51-1)
: All Linux
: Low major with 3 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: modest-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-10-27 14:36 UTC by Attila Csipa
Modified: 2010-06-29 07:40 UTC (History)
6 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Attila Csipa (reporter) nokia 2009-10-27 14:36:33 UTC
SOFTWARE VERSION:
Maemo 5, 1.2009.41-10

STEPS TO REPRODUCE THE PROBLEM:
Do (or wait for a scheduled) send&receive (in my case it's a SSL port 995 POP3
mailbox with LOGIN authentication). Modest will show a progress indicator and a
'last updated' when it's done.

EXPECTED OUTCOME:
Close the POP3 connection

ACTUAL OUTCOME:
The POP3 connection is left open even though there is no indication of this on
the GUI (except when you click the edit settings when you willl be greeted with
a surprising you will be disconnected warning). This in turn wreaks havoc on
the server side, by leaving locks open far longer than necessary.

REPRODUCIBILITY:
sometimes

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre)
Gecko/20090916 Ubuntu/8.04 (hardy) Shiretoko/3.5.4pre
Comment 1 Sergio Villar Senin 2009-10-27 19:20:14 UTC
Please specify when do you see the connection opened. "Sometimes" is not very
descriptive
Comment 2 Attila Csipa (reporter) nokia 2009-10-27 19:39:05 UTC
I didn't put always as some actions (like closing the Modest window) DO flush
the connection.

UPDATE: The connection gets established even just by running Modest. So, even
if one disables automatic checks, the moment Modest is started, it will log in
to the POP3 account and hog it until it is explicitly closed or it gets timed
out.

It gets even worse when automatic checks are enabled, as then this login is
done by the daemon and there is no way to get rid of the ever-present lockfile
but to start and quit the email client.
Comment 3 Lucas Maneos 2009-11-14 18:21:29 UTC
Confirmed in 1.2009.42-11, testing with fakepop as a server and tcpdump to
watch the connection.  This is made worse by modest lingering (and keeping the
connection open) for up to 30' after closing the UI.
Comment 4 Sergio Villar Senin 2009-11-16 14:08:04 UTC
(In reply to comment #3)
> Confirmed in 1.2009.42-11, testing with fakepop as a server and tcpdump to
> watch the connection.  This is made worse by modest lingering (and keeping the
> connection open) for up to 30' after closing the UI.
> 

Well there is a good explanation for that. Closing UI does not always mean to
close the program, as Modest is in a state that is called pre-loaded in order
to launch the UI faster the next time. By default Modest is launched with "-t
30" which means that it will wait 30 minutes in the background before getting
closed. 

So in that case I agree that we might close that connection, but I don't see
why we should close and open it everytime we do something. That would be an
error IMO as the program will behave terribly slow and the server will most
likely ban you as you were making too many connection attempts.
Comment 5 Attila Csipa (reporter) nokia 2009-11-16 14:34:00 UTC
There seems to be a misunderstanding. POP3 is not IMAP. There is no 'every time
we do something' as you only do downloading batches of messages/headers (and
sometimes deleting them) :) 

And it gets worse. The way I discovered this problem is that mails addressed to
me started getting late or outright bouncing. Apparently some mail servers
(Exim4, for example) will by default not deliver mail into your mbox format
mailbox if there is a lock on it (which makes sense as that would break the
mailbox consistency from the aspect of the mail client).
Comment 6 Sergio Villar Senin 2009-11-26 19:39:31 UTC
*** Bug 5839 has been marked as a duplicate of this bug. ***
Comment 7 Sergio Villar Senin 2010-01-18 15:47:08 UTC
The problem was spread over both Modest & tinymail. Regarding tinymail the POP3
code was incorrect. It was not disconnecting the account when the CamelService
was finalized. By Modest side, there were some reference leaks that were
preventing the TnyAccount from being properly freed, and thus, it was
preventing the CamelPOP3Store from being finalized.

Fixed in
* Modest
modest-3-2 (PR1.2): ea4df7e8e3f6354d7056554eee242f5f9e4d0f6c
master (community): 9954ebe62f9bdfd9776f909a4d2ed47dd4c36112

* Tinymail
modest-3-2 (PR1.2): r4138
trunk  (community): r4136
Comment 8 Lucas Maneos 2010-01-22 10:07:48 UTC
*** Bug 8376 has been marked as a duplicate of this bug. ***
Comment 9 Andre Klapper maemo.org 2010-03-15 20:56:13 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).
Comment 10 Andre Klapper maemo.org 2010-03-26 14:34:30 UTC
Fix included in modest 3.2.11-2+0m5 and later.
Internal version: 10.2010.05-4 and later.
Comment 11 Lucas Maneos 2010-03-30 09:07:17 UTC
*** Bug 9764 has been marked as a duplicate of this bug. ***
Comment 12 martin.bruce 2010-06-02 00:02:41 UTC
This bug was not resolved for me in PR 1.2. Actually it was made way worse.  

I haver a Pop3 account that I have configured to check every 30 min on my N900.
On my computer I check the same Pop3 account every 2 minutes.

Before PR 1.2 I was able to fetch my mails to my computer every once in a
while. At least several times a day. Since PR 1.2, I installed it as soon as it
was made available to me (Sweden), I have managed to fetch mails to my computer
exactly 2 times without entering the mail settings on my N900 forcing a
termination of the Pop3 session.

Whatever was done with the Pop3 code definately did not resolve my problems,
they where made way worse.
Comment 13 Andre Klapper maemo.org 2010-06-23 15:20:14 UTC
Martin: Does not necessarily sound related to me to this report...
If you can provide exact steps, feel free to file a separate issue.
Comment 14 martin.bruce 2010-06-28 23:42:49 UTC
(In reply to comment #13)
> Martin: Does not necessarily sound related to me to this report...
> If you can provide exact steps, feel free to file a separate issue.

To me it feels very related. What I do is set the following up on my N900

1) Setup a pop3 mail account.
2) Have the account being updated every 30 min.
3) Let the account update at least 1 time on the phone.
4) Try to fetch mails from the same pop3 account on a normal computer. You will
hardly ever succeed. You will get the following error: -ERR [SYS/PERM] mailbox
locked by a POP3 session. I have tried setting my computer to update every 2
min and still not been able to fetch any mails for several days. Every once in
a while I succeed. Before PR 1.2 I succeeded in fetching my mails to my
computer several times every day. Now it usually is several days between I'm
able unless I forecully closes the POP3 session on my N900 by entering the
settings.
Comment 15 luarvique 2010-06-29 07:40:12 UTC
I made an additional observation:

When the remote POP3 server is down, the N900 becomes progressively more
sluggish over several days, until you reboot it. Disabling the POP3 account in
Modest seems to remedy this problem.

Please note that I am not quite sure the Modest POP3 code is to blame here:
there might have been other causes.