Bug 477590 - No activity after resume from suspend (to ram or to disk)
No activity after resume from suspend (to ram or to disk)
Product: Fedora
Classification: Fedora
Component: offlineimap (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Christoph Höger
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-12-22 02:50 EST by Amit Shah
Modified: 2009-06-27 09:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-27 09:03:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Amit Shah 2008-12-22 02:50:04 EST
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 08:31:27 EST
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.


Comment 2 Amit Shah 2009-01-10 09:25:28 EST
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 17:40:09 EST
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 02:25:50 EST
Hi Christoph,

I tried this option and looks like it helps. Thanks!
Comment 5 Christoph Höger 2009-06-27 09:03:16 EDT
closed - forgot that long time ago.

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