offlineimap hangs

Edd Barrett edd at
Sun Jan 11 14:36:55 GMT 2015

On Sun, Jan 11, 2015 at 04:44:23AM +0300, Eygene Ryabinkin wrote:
> Can you, please, kill offlineimap with SIGQUIT: it will print the full
> backtrace of all threads to the stderr.  It will be interesting to see
> the output.

I (accidentally) found one scenario where the hang occurs. I apply the
SIGQUIT approach below.

First background. I have a script which runs offlineimap and mu (the
mail indexer) in a loop with a 180 second sleep in each iteration.

Last night I suspended my laptop, and when it woke this morning, offlineimap
was hanging:

OfflineIMAP 6.5.6
  Licensed under the GNU GPL v2+ (v2 or any later version)
Account sync XXXXX:
 *** Processing account XXXXX
 Establishing connection to XXXXX:993
Traceback (most recent call last):
  File "/home/edd/source/passout/", line 111, in <module>
  File "/home/edd/source/passout/", line 108, in entrypoint
    args.func(args, expand=True)
  File "/home/edd/.local/lib/python2.7/site-packages/argspander/", line 74, in _inner
    return func(*func_args)
  File "/home/edd/source/passout/", line 41, in cmd_stdout
    print(passout.get_password(cfg, pass_name))
  File "/home/edd/source/passout/passout/", line 100, in get_password
    (out, err))
passout.PassOutError: gpg returned non-zero
STDERR: gpg: cancelled by user
gpg: encrypted with 2048-bit RSA key, ID XXXXXXXX, created XXXX-XX-XX
      "Edd Barrett <XXXXXXXXXXXXXXXX>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

Enter password for account 'XXXXX': 
^CTerminating NOW (this may take a few seconds)...
^CTerminating NOW (this may take a few seconds)...

What is happening here is, offlineimap was either mid-sync or due to sync
during suspend. The stack trace you see is my password manager attempting to
decrypt a password from disk and send it back to offlineimap (via
remotepasseval). The password manager is communicating with gpg-agent, which
may need to prompt the user to unlock the GPG keychain (via pinentry-gtk2 in
my case). I suppose this can time out, or perhaps it had probems connecting
to the X server whilst X was resuming.

Anyway, after this, offlineimap is hung in the way I described in my first

I sent it a SIGQUIT:

# Thread #0 (id=9702286294272), Account sync XXXXX
File: "/usr/local/lib/python2.7/", line 783, in __bootstrap self.__bootstrap_inner()
File: "/usr/local/lib/python2.7/", line 810, in __bootstrap_inner
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 229, in run
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 158, in run
File: "/usr/local/lib/python2.7/", line 763, in run self.__target(*self.__args, **self.__kwargs)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 241, in syncrunner self.__sync()
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 303, in __sync remoterepos.getfolders()
File: "/usr/local/lib/python2.7/site-packages/offlineimap/repository/", line 322, in getfolders imapobj = self.imapserver.acquireconnection()
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 418, in acquireconnection self.__authn_helper(imapobj)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 327, in __authn_helper if func(imapobj):
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 253, in __authn_plain imapobj.authenticate('PLAIN', self.__plainhandler)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 648, in authenticate typ, dat = self._simple_command('AUTHENTICATE', mechanism.upper())
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 1615, in _simple_command return self._command_complete(self._command(name, *args), kw)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 1343, in _command ok, data = crqb.get_response('command: %s => %%s' % name)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 170, in get_response self.ready.wait()
File: "/usr/local/lib/python2.7/", line 621, in wait self.__cond.wait(timeout)
File: "/usr/local/lib/python2.7/", line 340, in wait waiter.acquire()

# Thread #1 (id=9700364648960), Sync Runner
File: "/usr/local/lib/python2.7/", line 783, in __bootstrap self.__bootstrap_inner()
File: "/usr/local/lib/python2.7/", line 810, in __bootstrap_inner
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 158, in run
File: "/usr/local/lib/python2.7/", line 763, in run self.__target(*self.__args, **self.__kwargs)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 37, in syncitall syncaccount(threads, config, accountname)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 29, in syncaccount thread.start()
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 224, in start instancelimitedsems[self.instancename].acquire()
File: "/usr/local/lib/python2.7/", line 468, in acquire self.__cond.wait()
File: "/usr/local/lib/python2.7/", line 340, in wait waiter.acquire()

# Thread #2 (id=9701371553504), MainThread
File: "/usr/local/bin/offlineimap", line 23, in <module>
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 50, in run self.__sync(options)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 382, in __sync threadutil.exitnotifymonitorloop(threadutil.threadexited)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 109, in exitnotifymonitorloop thrd = exitthreads.get(True, 60)
File: "/usr/local/lib/python2.7/", line 177, in get self.not_empty.wait(remaining)
File: "/usr/local/lib/python2.7/", line 359, in wait _sleep(delay)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/", line 359, in sig_handler stacktrace.dump (sys.stderr)
File: "/usr/local/lib/python2.7/site-packages/offlineimap/utils/", line 20, in dump for f, lno, name, line in traceback.extract_stack (stack):
Abort trap (core dumped) 

Looks like some kind of deadlock between threads?

This is 6.5.6 on OpenBSD/amd64.

Best Regards
Edd Barrett

More information about the OfflineIMAP-project mailing list