Bug 477590

Summary:	No activity after resume from suspend (to ram or to disk)
Product:	[Fedora] Fedora	Reporter:	Amit Shah <amit.shah>
Component:	offlineimap	Assignee:	Christoph Höger <choeger>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	10	CC:	amit.shah, choeger
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-06-27 13:03:16 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Amit Shah 2008-12-22 07:50:04 UTC

Description of problem:
If an offlineimap process was active while suspending, on resume, the process doesn't progress at all. (Some vpn connections over which it may be fetching mail may have broken at resume as well.) It just sits there, preventing any new offlineimap processes to fetch mail as well. It also figures high in the powertop output in such a stage.

Manually killing the process helps; but I'm unsure if any mail is lost by such behaviour.

Using offlineimap-6.0.0-1.fc10.noarch

Comment 1 Christoph Höger 2009-01-10 13:31:27 UTC

Hi Amit,

I think this is a weird use case ;). You should probably not suspend when _any_ active application performs tasks on an active network connection. What is the server supposed to do?
Normally it would time out your connection, leaving your application in an undefined state. 
The only thing that comes in mind would be to write some kind of suspend awareness for offlineimap to allow it cancel all threads.
But I doubt upstream will do that...

That being said, could you please verify the behavior with the current version?
If you are firm with debugging python it would be nice if you could add a trace to show off, where offlineimap hangs, I will try and send that upstream then.

regards

Christoph

Comment 2 Amit Shah 2009-01-10 14:25:28 UTC

Well, ideally I'd expect the server to timeout. I have offlineimap in a cron job spawning every few minutes. Laptops do get suspended. Any network activity should timeout on the server.

For offlineimap, we can add some timer to detect if the connection has been stalled for some time and using actual wall-clock time, detect if we've been moved far ahead. In that case, just quit.

Comment 3 Christoph Höger 2009-01-13 22:40:09 UTC

Hi Amit,

citing /usr/share/doc/offlineimap-6.0.3/offlineimap.conf

# By default, OfflineIMAP will not exit due to a network error until
# the operating system returns an error code.  Operating systems can sometimes
# take forever to notice this.  Here you can activate a timeout on the
# socket.  This timeout applies to individual socket reads and writes,
# not to an overall sync operation.  You could perfectly well have a 30s
# timeout here and your sync still take minutes.
#
# Values in the 30-120 second range are reasonable.
#
# The default is to have no timeout beyond the OS.  Times are given in seconds.
#
# socktimeout = 60

I think that this means, your bug is none.
(Did not know that, had to ask upstream)
Does that help you out?

Comment 4 Amit Shah 2009-01-20 07:25:50 UTC

Hi Christoph,

I tried this option and looks like it helps. Thanks!

Comment 5 Christoph Höger 2009-06-27 13:03:16 UTC

closed - forgot that long time ago.