Hello, One workaround would be to allow the master caldavd process to perform the upgrade, instead of doing it out-of-band with calendarserver_upgrade (which is normally the recommended way).
In your caldavd plist, as a top-level key (i.e. in the outter-most dict), set: <key>FailIfUpgradeNeeded</key> <false/> ... as seen here: https://github.com/apple/ccs-calendarserver/blob/master/conf/caldavd-stdconfig.plist#L199 <https://github.com/apple/ccs-calendarserver/blob/master/conf/caldavd-stdconfig.plist#L199> Then just start the service, and if all is well, you should be upgraded to version 63. This will take some amount of time depending on how much data you have, your hardware performance, etc. Some of the upgrade phases can be run concurrently (useful for large sites), however that requires use of the calendarserver_upgrade tool. I'd recommend setting FailIfUpgradeNeeded back to true after you're done. Schema upgrades should be explicit and never surprising. It's always a good idea to make a backup before upgrading :) The schema upgrade process is pretty robust with respect to handling all manner of wacky user data, but there are a number of potential operational problems that could interrupt an upgrade. If a schema upgrade dies part-way through (for some correctable environmental reason), and you want to retry, we have no facility for gracefully retrying a partially applied schema version upgrade. To continue, figure out where the upgrade left off by running manual SQL queries to check for the expected DB state that would result from each of the upgrade statements. Once you find where it stopped, manually run the remaining statements from that upgrade (up until the end of that schema upgrade file, the last statement of which is always setting the schema version in the DB), and then the tools can take it from there. If an upgrade failed because (this is a weird example) the host rebooted, it's good to have the option of restoring from backup and retrying instead of doing the above procedure to recover from a partial upgrade. -dre > On Jan 12, 2017, at 9:12 AM, Dirk-Willem van Gulik <di...@webweaving.org> > wrote: > > On a recent py27-calendarserver-9.0 (freebsd ports) should one expect caldavd > to auto upgrade a 24 -> 63 (postgress backend) database ? > > A cursory glance at the code suggest this - but I see: > > 017-01-12T17:11:27+0000 > [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] > Beginning database schema check. > 2017-01-12T17:11:27+0000 > [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] > Required database key VERSION: 63. > 2017-01-12T17:11:27+0000 [twext.enterprise.adbapi2#debug] ConnectionPool: txn > busy 'UpgradeDatabaseCoreStep.getVersions': free=0, busy=1, waiting=0 > 2017-01-12T17:11:27+0000 [twext.enterprise.adbapi2#debug] ConnectionPool: txn > free 'UpgradeDatabaseCoreStep.getVersions': free=1, busy=0, waiting=0 > 2017-01-12T17:11:27+0000 > [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] > Actual database key VERSION: 24. > 2017-01-12T17:11:27+0000 [calendarserver.tap.caldav#error] Data store not > available; shutting down > > and unfortunately > > calendarserver_upgrade > > Seems mired with some circular dependencies in this version: > > Traceback (most recent call last): > File "/usr/local/bin/calendarserver_upgrade", line 11, in <module> > load_entry_point('CalendarServer==9.0', 'console_scripts', > 'calendarserver_upgrade')() > ... > File "/usr/local/lib/python2.7/site-packages/calendarserver/tap/util.py", > line 38, in <module> > from calendarserver.tools.util import checkDirectory > > Any advice appreciated, > > Dw > > _______________________________________________ > calendarserver-users mailing list > calendarserver-users@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/calendarserver-users
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/calendarserver-users
