Bug 479135 - offlineimap quits even if one of the mail servers isn't reachable
offlineimap quits even if one of the mail servers isn't reachable
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: offlineimap (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Christoph Höger
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-07 09:35 EST by Amit Shah
Modified: 2009-01-13 17:46 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-13 17:46:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This patch should prevent the whole application from crashing with one single thread (1.40 KB, patch)
2009-01-12 12:40 EST, Christoph Höger
no flags Details | Diff

  None (edit)
Description Amit Shah 2009-01-07 09:35:49 EST
Description of problem:

I have set up offlineimap to fetch mail from two different imap accounts. One is over vpn. If the vpn isn't up, offlineimap just quits and doesn't continue fetching from the other account.
Comment 1 Christoph Höger 2009-01-10 08:33:06 EST
Hi Amit,

thanks for the report. Could you please post the trace offlineimap writes into your console (if you use blinkenlights or TTY interface)? I will try to bring up a patch then.

regards

Christoph
Comment 2 Amit Shah 2009-01-10 09:28:45 EST
Well, a traceback will just state the obvious: that the socket failed to connect. This can be easily simulated by pointing one of the accounts to a fake url:port.

Anyhow, here's the trace if I don't have my VPN connection up.


Thread 'Account sync RH' terminated with exception:
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/offlineimap/threadutil.py", line 149, in run
    Thread.run(self)
  File "/usr/lib64/python2.5/threading.py", line 446, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.5/site-packages/offlineimap/accounts.py", line 108, in syncrunner
    self.sync()
  File "/usr/lib/python2.5/site-packages/offlineimap/accounts.py", line 142, in sync
    remoterepos.syncfoldersto(localrepos, [statusrepos])
  File "/usr/lib/python2.5/site-packages/offlineimap/repository/Base.py", line 135, in syncfoldersto
    srcfolders = src.getfolders()
  File "/usr/lib/python2.5/site-packages/offlineimap/repository/IMAP.py", line 194, in getfolders
    imapobj = self.imapserver.acquireconnection()
  File "/usr/lib/python2.5/site-packages/offlineimap/imapserver.py", line 224, in acquireconnection
    self.sslclientkey, self.sslclientcert)
  File "/usr/lib64/python2.5/imaplib.py", line 1128, in __init__
    IMAP4.__init__(self, host, port)
  File "/usr/lib64/python2.5/imaplib.py", line 163, in __init__
    self.open(host, port)
  File "/usr/lib/python2.5/site-packages/offlineimap/imapserver.py", line 65, in open
    imaplibutil.new_open_ssl(self, host, port)
  File "/usr/lib/python2.5/site-packages/offlineimap/imaplibutil.py", line 155, in new_open_ssl
    socket.SOCK_STREAM)
gaierror: (-2, 'Name or service not known')


Last 1 debug messages logged for Account sync RH prior to exception:
maildir: MaildirRepository initialized, sep is '.'
Comment 3 Christoph Höger 2009-01-12 12:40:27 EST
Created attachment 328766 [details]
This patch should prevent the whole application from crashing with one single thread

I am going to discuss that (and the other issue) with upstream.
As a temporary fix you could try out the attached patch, as it should fir your usecase (but probably breaks the design decisions of the upstream author).
Comment 4 Christoph Höger 2009-01-13 17:46:30 EST
Forget about that patch it breaks a lot of functionality.
I asked upstream and it seems preventing that behavior would require a major source code revamp. That will probably not happen.
So the solution for your special case is the -a switch which allows you to handle single accounts for single invocations. Simply use that in your cron script, and you'll be fine. 
(As a side note: that's what John Goerzen does too, so it's a pretty well known use case ;))
I'll close this bug as 'WONTFIX' although, if I happen to have _much_ spare time...

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