Red Hat Bugzilla – Bug 477590
No activity after resume from suspend (to ram or to disk)
Last modified: 2009-06-27 09:03:16 EDT
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.
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.
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.
# 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?
I tried this option and looks like it helps. Thanks!
closed - forgot that long time ago.