maemo.org Bugzilla – Full Text Bug Listing
|Summary:||POP3 TCP connection is left open leading to locking issues|
|Product:||[Maemo Official Applications] Email||Reporter:||Attila Csipa <attila.csipa>|
|Status:||RESOLVED FIXED||QA Contact:||modest-bugs|
|Priority:||Low||CC:||andre_klapper, luarvique, maemo, martin.bruce, meamobz, svillar|
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:22.214.171.124pre) Gecko/20090916 Ubuntu/8.04 (hardy) Shiretoko/3.5.4pre
Please specify when do you see the connection opened. "Sometimes" is not very descriptive
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.
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.
(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.
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).
*** Bug 5839 has been marked as a duplicate of this bug. ***
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
*** Bug 8376 has been marked as a duplicate of this bug. ***
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).
Fix included in modest 3.2.11-2+0m5 and later. Internal version: 10.2010.05-4 and later.
*** Bug 9764 has been marked as a duplicate of this bug. ***
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.
Martin: Does not necessarily sound related to me to this report... If you can provide exact steps, feel free to file a separate issue.
(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.
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.