docker-offlineimap/offlineimap/syncmaster.py

50 lines
2.2 KiB
Python
Raw Normal View History

# OfflineIMAP synchronization master code
2007-07-04 19:53:48 +02:00
# Copyright (C) 2002-2007 John Goerzen
# <jgoerzen@complete.org>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
2006-08-12 06:15:55 +02:00
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
from offlineimap import imaplib2, imapserver, repository, folder, mbnames, threadutil, version
from offlineimap.threadutil import InstanceLimitedThread, ExitNotifyThread
import offlineimap.accounts
Patch for signal handling to start a sync by Jim Pryor Here's the way I'd like to use offlineimap on my laptop: 1. Have a regular cron job running infrequently. The cron job checks to see if I'm online, plugged in, and that no other copy of offlineimap is running. If all of these conditions are satisfied, it runs offlineimap just once: "offlineimap -o -u Noninteractive.Quiet" 2. When I start up mutt, I do it by calling a wrapper script that delays until cron-started copies of offlineimap have finished, then starts offlineimap on its regular, stay-alive and keep checking schedule. When I quit mutt, the wrapper script tells offlineimap to stop. This way I get frequent regular checks while I have mutt running, but I don't waste my battery/cpu checking frequently for mail when I'm not interested in it. To make this work, though, it'd be nicer if it were easier to tell offlineimap, from the outside, things like "terminate cleanly now" and "when you've finished synching, then terminate instead of sleeping and synching again." OK, to put my money where my mouth is, I attach two patches against offlineimap 6.0.3. The first, "cleanup.patch", cleans up a few spots that tend to throw exceptions for me as offlineimap is exiting from a KeyboardInterrupt. The second adds signaling capabilities to offlineimap. * sending a SIGTERM tells offlineimap to terminate immediately but cleanly, just as if "q" had been pressed in the GUI interface * sending a SIGUSR1 tells every account to do a full sync asap: if it's sleeping, then wake up and do the sync now. If it's mid-sync, then re-synch any folders whose syncing has already been started or completed, and continue to synch the other, queued but not-yet-synched folders. * sending a SIGHUP tells every account to die as soon as it can (but not immediately: only after finishing any synch it's now engaged in) * sending a SIGUSR2 tells every account to do a full sync asap (as with SIGUSR1), then die It's tricky to mix signals with threads, but I think I've done this correctly. I've been using it now for a few weeks without any obvious problems. But I'm passing it on so that others can review the code and test it out on their systems. I developed the patch when I was running Python 2.5.2, but to my knowledge I don't use any Python 2.5-specific code. Now I'm using the patch with Python 2.6. Although I said "without any obvious problems," let me confess that I'm seeing offlineimap regularly choke when I do things like this: start up my offlineimap-wrapped copy of mutt, wait a while, put the machine to sleep (not sure if offlineimap is active in the background or idling), move to a different spot, wake the machine up again and it acquires a new network, sometimes a wired network instead of wifi. Offlineimap doesn't like that so much. I don't yet have any reason to think the problems here come from my patches. But I'm just acknowledging them, so that if others are able to use offlineimap without any difficulty in situations like I described, then maybe the fault is with my patches.
2008-12-01 23:13:16 +01:00
from offlineimap.accounts import SyncableAccount, SigListener
from offlineimap.ui import UIBase
import re, os, os.path, offlineimap, sys
from ConfigParser import ConfigParser
from threading import *
Patch for signal handling to start a sync by Jim Pryor Here's the way I'd like to use offlineimap on my laptop: 1. Have a regular cron job running infrequently. The cron job checks to see if I'm online, plugged in, and that no other copy of offlineimap is running. If all of these conditions are satisfied, it runs offlineimap just once: "offlineimap -o -u Noninteractive.Quiet" 2. When I start up mutt, I do it by calling a wrapper script that delays until cron-started copies of offlineimap have finished, then starts offlineimap on its regular, stay-alive and keep checking schedule. When I quit mutt, the wrapper script tells offlineimap to stop. This way I get frequent regular checks while I have mutt running, but I don't waste my battery/cpu checking frequently for mail when I'm not interested in it. To make this work, though, it'd be nicer if it were easier to tell offlineimap, from the outside, things like "terminate cleanly now" and "when you've finished synching, then terminate instead of sleeping and synching again." OK, to put my money where my mouth is, I attach two patches against offlineimap 6.0.3. The first, "cleanup.patch", cleans up a few spots that tend to throw exceptions for me as offlineimap is exiting from a KeyboardInterrupt. The second adds signaling capabilities to offlineimap. * sending a SIGTERM tells offlineimap to terminate immediately but cleanly, just as if "q" had been pressed in the GUI interface * sending a SIGUSR1 tells every account to do a full sync asap: if it's sleeping, then wake up and do the sync now. If it's mid-sync, then re-synch any folders whose syncing has already been started or completed, and continue to synch the other, queued but not-yet-synched folders. * sending a SIGHUP tells every account to die as soon as it can (but not immediately: only after finishing any synch it's now engaged in) * sending a SIGUSR2 tells every account to do a full sync asap (as with SIGUSR1), then die It's tricky to mix signals with threads, but I think I've done this correctly. I've been using it now for a few weeks without any obvious problems. But I'm passing it on so that others can review the code and test it out on their systems. I developed the patch when I was running Python 2.5.2, but to my knowledge I don't use any Python 2.5-specific code. Now I'm using the patch with Python 2.6. Although I said "without any obvious problems," let me confess that I'm seeing offlineimap regularly choke when I do things like this: start up my offlineimap-wrapped copy of mutt, wait a while, put the machine to sleep (not sure if offlineimap is active in the background or idling), move to a different spot, wake the machine up again and it acquires a new network, sometimes a wired network instead of wifi. Offlineimap doesn't like that so much. I don't yet have any reason to think the problems here come from my patches. But I'm just acknowledging them, so that if others are able to use offlineimap without any difficulty in situations like I described, then maybe the fault is with my patches.
2008-12-01 23:13:16 +01:00
def syncaccount(threads, config, accountname, siglisteners):
account = SyncableAccount(config, accountname)
Patch for signal handling to start a sync by Jim Pryor Here's the way I'd like to use offlineimap on my laptop: 1. Have a regular cron job running infrequently. The cron job checks to see if I'm online, plugged in, and that no other copy of offlineimap is running. If all of these conditions are satisfied, it runs offlineimap just once: "offlineimap -o -u Noninteractive.Quiet" 2. When I start up mutt, I do it by calling a wrapper script that delays until cron-started copies of offlineimap have finished, then starts offlineimap on its regular, stay-alive and keep checking schedule. When I quit mutt, the wrapper script tells offlineimap to stop. This way I get frequent regular checks while I have mutt running, but I don't waste my battery/cpu checking frequently for mail when I'm not interested in it. To make this work, though, it'd be nicer if it were easier to tell offlineimap, from the outside, things like "terminate cleanly now" and "when you've finished synching, then terminate instead of sleeping and synching again." OK, to put my money where my mouth is, I attach two patches against offlineimap 6.0.3. The first, "cleanup.patch", cleans up a few spots that tend to throw exceptions for me as offlineimap is exiting from a KeyboardInterrupt. The second adds signaling capabilities to offlineimap. * sending a SIGTERM tells offlineimap to terminate immediately but cleanly, just as if "q" had been pressed in the GUI interface * sending a SIGUSR1 tells every account to do a full sync asap: if it's sleeping, then wake up and do the sync now. If it's mid-sync, then re-synch any folders whose syncing has already been started or completed, and continue to synch the other, queued but not-yet-synched folders. * sending a SIGHUP tells every account to die as soon as it can (but not immediately: only after finishing any synch it's now engaged in) * sending a SIGUSR2 tells every account to do a full sync asap (as with SIGUSR1), then die It's tricky to mix signals with threads, but I think I've done this correctly. I've been using it now for a few weeks without any obvious problems. But I'm passing it on so that others can review the code and test it out on their systems. I developed the patch when I was running Python 2.5.2, but to my knowledge I don't use any Python 2.5-specific code. Now I'm using the patch with Python 2.6. Although I said "without any obvious problems," let me confess that I'm seeing offlineimap regularly choke when I do things like this: start up my offlineimap-wrapped copy of mutt, wait a while, put the machine to sleep (not sure if offlineimap is active in the background or idling), move to a different spot, wake the machine up again and it acquires a new network, sometimes a wired network instead of wifi. Offlineimap doesn't like that so much. I don't yet have any reason to think the problems here come from my patches. But I'm just acknowledging them, so that if others are able to use offlineimap without any difficulty in situations like I described, then maybe the fault is with my patches.
2008-12-01 23:13:16 +01:00
siglistener = SigListener()
thread = InstanceLimitedThread(instancename = 'ACCOUNTLIMIT',
target = account.syncrunner,
Patch for signal handling to start a sync by Jim Pryor Here's the way I'd like to use offlineimap on my laptop: 1. Have a regular cron job running infrequently. The cron job checks to see if I'm online, plugged in, and that no other copy of offlineimap is running. If all of these conditions are satisfied, it runs offlineimap just once: "offlineimap -o -u Noninteractive.Quiet" 2. When I start up mutt, I do it by calling a wrapper script that delays until cron-started copies of offlineimap have finished, then starts offlineimap on its regular, stay-alive and keep checking schedule. When I quit mutt, the wrapper script tells offlineimap to stop. This way I get frequent regular checks while I have mutt running, but I don't waste my battery/cpu checking frequently for mail when I'm not interested in it. To make this work, though, it'd be nicer if it were easier to tell offlineimap, from the outside, things like "terminate cleanly now" and "when you've finished synching, then terminate instead of sleeping and synching again." OK, to put my money where my mouth is, I attach two patches against offlineimap 6.0.3. The first, "cleanup.patch", cleans up a few spots that tend to throw exceptions for me as offlineimap is exiting from a KeyboardInterrupt. The second adds signaling capabilities to offlineimap. * sending a SIGTERM tells offlineimap to terminate immediately but cleanly, just as if "q" had been pressed in the GUI interface * sending a SIGUSR1 tells every account to do a full sync asap: if it's sleeping, then wake up and do the sync now. If it's mid-sync, then re-synch any folders whose syncing has already been started or completed, and continue to synch the other, queued but not-yet-synched folders. * sending a SIGHUP tells every account to die as soon as it can (but not immediately: only after finishing any synch it's now engaged in) * sending a SIGUSR2 tells every account to do a full sync asap (as with SIGUSR1), then die It's tricky to mix signals with threads, but I think I've done this correctly. I've been using it now for a few weeks without any obvious problems. But I'm passing it on so that others can review the code and test it out on their systems. I developed the patch when I was running Python 2.5.2, but to my knowledge I don't use any Python 2.5-specific code. Now I'm using the patch with Python 2.6. Although I said "without any obvious problems," let me confess that I'm seeing offlineimap regularly choke when I do things like this: start up my offlineimap-wrapped copy of mutt, wait a while, put the machine to sleep (not sure if offlineimap is active in the background or idling), move to a different spot, wake the machine up again and it acquires a new network, sometimes a wired network instead of wifi. Offlineimap doesn't like that so much. I don't yet have any reason to think the problems here come from my patches. But I'm just acknowledging them, so that if others are able to use offlineimap without any difficulty in situations like I described, then maybe the fault is with my patches.
2008-12-01 23:13:16 +01:00
name = "Account sync %s" % accountname,
kwargs = {'siglistener': siglistener} )
# the Sync Runner thread is the only one that will mutate siglisteners
siglisteners.append(siglistener)
thread.setDaemon(1)
thread.start()
threads.add(thread)
Patch for signal handling to start a sync by Jim Pryor Here's the way I'd like to use offlineimap on my laptop: 1. Have a regular cron job running infrequently. The cron job checks to see if I'm online, plugged in, and that no other copy of offlineimap is running. If all of these conditions are satisfied, it runs offlineimap just once: "offlineimap -o -u Noninteractive.Quiet" 2. When I start up mutt, I do it by calling a wrapper script that delays until cron-started copies of offlineimap have finished, then starts offlineimap on its regular, stay-alive and keep checking schedule. When I quit mutt, the wrapper script tells offlineimap to stop. This way I get frequent regular checks while I have mutt running, but I don't waste my battery/cpu checking frequently for mail when I'm not interested in it. To make this work, though, it'd be nicer if it were easier to tell offlineimap, from the outside, things like "terminate cleanly now" and "when you've finished synching, then terminate instead of sleeping and synching again." OK, to put my money where my mouth is, I attach two patches against offlineimap 6.0.3. The first, "cleanup.patch", cleans up a few spots that tend to throw exceptions for me as offlineimap is exiting from a KeyboardInterrupt. The second adds signaling capabilities to offlineimap. * sending a SIGTERM tells offlineimap to terminate immediately but cleanly, just as if "q" had been pressed in the GUI interface * sending a SIGUSR1 tells every account to do a full sync asap: if it's sleeping, then wake up and do the sync now. If it's mid-sync, then re-synch any folders whose syncing has already been started or completed, and continue to synch the other, queued but not-yet-synched folders. * sending a SIGHUP tells every account to die as soon as it can (but not immediately: only after finishing any synch it's now engaged in) * sending a SIGUSR2 tells every account to do a full sync asap (as with SIGUSR1), then die It's tricky to mix signals with threads, but I think I've done this correctly. I've been using it now for a few weeks without any obvious problems. But I'm passing it on so that others can review the code and test it out on their systems. I developed the patch when I was running Python 2.5.2, but to my knowledge I don't use any Python 2.5-specific code. Now I'm using the patch with Python 2.6. Although I said "without any obvious problems," let me confess that I'm seeing offlineimap regularly choke when I do things like this: start up my offlineimap-wrapped copy of mutt, wait a while, put the machine to sleep (not sure if offlineimap is active in the background or idling), move to a different spot, wake the machine up again and it acquires a new network, sometimes a wired network instead of wifi. Offlineimap doesn't like that so much. I don't yet have any reason to think the problems here come from my patches. But I'm just acknowledging them, so that if others are able to use offlineimap without any difficulty in situations like I described, then maybe the fault is with my patches.
2008-12-01 23:13:16 +01:00
def syncitall(accounts, config, siglisteners):
currentThread().setExitMessage('SYNC_WITH_TIMER_TERMINATE')
ui = UIBase.getglobalui()
threads = threadutil.threadlist()
mbnames.init(config, accounts)
for accountname in accounts:
Patch for signal handling to start a sync by Jim Pryor Here's the way I'd like to use offlineimap on my laptop: 1. Have a regular cron job running infrequently. The cron job checks to see if I'm online, plugged in, and that no other copy of offlineimap is running. If all of these conditions are satisfied, it runs offlineimap just once: "offlineimap -o -u Noninteractive.Quiet" 2. When I start up mutt, I do it by calling a wrapper script that delays until cron-started copies of offlineimap have finished, then starts offlineimap on its regular, stay-alive and keep checking schedule. When I quit mutt, the wrapper script tells offlineimap to stop. This way I get frequent regular checks while I have mutt running, but I don't waste my battery/cpu checking frequently for mail when I'm not interested in it. To make this work, though, it'd be nicer if it were easier to tell offlineimap, from the outside, things like "terminate cleanly now" and "when you've finished synching, then terminate instead of sleeping and synching again." OK, to put my money where my mouth is, I attach two patches against offlineimap 6.0.3. The first, "cleanup.patch", cleans up a few spots that tend to throw exceptions for me as offlineimap is exiting from a KeyboardInterrupt. The second adds signaling capabilities to offlineimap. * sending a SIGTERM tells offlineimap to terminate immediately but cleanly, just as if "q" had been pressed in the GUI interface * sending a SIGUSR1 tells every account to do a full sync asap: if it's sleeping, then wake up and do the sync now. If it's mid-sync, then re-synch any folders whose syncing has already been started or completed, and continue to synch the other, queued but not-yet-synched folders. * sending a SIGHUP tells every account to die as soon as it can (but not immediately: only after finishing any synch it's now engaged in) * sending a SIGUSR2 tells every account to do a full sync asap (as with SIGUSR1), then die It's tricky to mix signals with threads, but I think I've done this correctly. I've been using it now for a few weeks without any obvious problems. But I'm passing it on so that others can review the code and test it out on their systems. I developed the patch when I was running Python 2.5.2, but to my knowledge I don't use any Python 2.5-specific code. Now I'm using the patch with Python 2.6. Although I said "without any obvious problems," let me confess that I'm seeing offlineimap regularly choke when I do things like this: start up my offlineimap-wrapped copy of mutt, wait a while, put the machine to sleep (not sure if offlineimap is active in the background or idling), move to a different spot, wake the machine up again and it acquires a new network, sometimes a wired network instead of wifi. Offlineimap doesn't like that so much. I don't yet have any reason to think the problems here come from my patches. But I'm just acknowledging them, so that if others are able to use offlineimap without any difficulty in situations like I described, then maybe the fault is with my patches.
2008-12-01 23:13:16 +01:00
syncaccount(threads, config, accountname, siglisteners)
# Wait for the threads to finish.
threads.reset()