maemo.org Bugzilla – Bug 5836
POP3 TCP connection is left open leading to locking issues
Last modified: 2010-06-29 07:40:12 UTC
You need to
before you can comment on or make changes to this bug.
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.
Close the POP3 connection
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.
EXTRA SOFTWARE INSTALLED:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206pre)
Gecko/20090916 Ubuntu/8.04 (hardy) Shiretoko/3.5.4pre
Please specify when do you see the connection opened. "Sometimes" is not very
I didn't put always as some actions (like closing the Modest window) DO flush
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
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
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.
modest-3-2 (PR1.2): ea4df7e8e3f6354d7056554eee242f5f9e4d0f6c
master (community): 9954ebe62f9bdfd9776f909a4d2ed47dd4c36112
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
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.