Re: [CalendarServer-users] Trouble upgrading from 5.3 to 7.0
On Jan 17, 2016, at 2:19 PM, ebach <ebach2@gmail.com> wrote:
Does anything show up in the various log files calendarserver outputs too?
Nope. access.log shows only the server starting up (and, when I hit ^C, shuttung down): Log opened - server start: [Sun Jan 17 14:16:53 2016]. Log closed - server stop: [Sun Jan 17 14:18:35 2016]. error.log shows nothing. A little more playing around (adding debug messages in appropriate-looking places), it seems that it gets as far as running UpgradeReleaseLockStep (in txdav.common.datastore.upgrade.sql.upgrade). But no further than that.
On Jan 17, 2016, at 12:49 AM, Jacques Distler <distler@golem.ph.utexas.edu> wrote:
On Jan 17, 2016, at 12:52 AM, Jacques Distler <distler@golem.ph.utexas.edu> wrote:
bin/calendarserver_upgrade
completed without errors. But
bin/run -n
stalls at
2016-01-17 00:26:57-0600 [-] [twistedcaldav.upgrade#warn] Migrating delegates to the store
How can I diagnose what's causing the problem? After hitting ^C (the only way to get out), the old
proxies.sqlite
file is deleted (I can easily restore a copy from backup), but nothing seems to get me any further in the process of initializing the server.
N.B.: The "delegates" and "delegate_groups" tables in postgreSQL both still have zero rows, so none of the delegate data actually got migrated.
% sudo bin/run -n Using /usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/bin/python as Python Starting server... Reading configuration from file: /usr/local/CalDAV-7.0/CalendarServer/conf/caldavd-dev.plist 2016-01-18 11:56:41-0600 [-] Log opened. 2016-01-18 11:56:41-0600 [-] ControlSocket starting on '/Library/CalDAV/logs/caldavd.sock' 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Beginning database schema check. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Required database key VERSION: 58. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Actual database key VERSION: 58. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Schema version check complete: no upgrade needed. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Database schema check complete. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Beginning database addressbook data check. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Required database key ADDRESSBOOK-DATAVERSION: 2. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Actual database key ADDRESSBOOK-DATAVERSION: 2. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Addressbook data version check complete: no upgrade needed. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Database addressbook data check complete. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] Beginning database calendar data check. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] Required database key CALENDAR-DATAVERSION: 6. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] Actual database key CALENDAR-DATAVERSION: 6. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] Calendar data version check complete: no upgrade needed. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] Database calendar data check complete. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseNotificationDataStep#warn] Beginning database notification data check. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseNotificationDataStep#warn] Required database key NOTIFICATION-DATAVERSION: 1. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseNotificationDataStep#warn] Actual database key NOTIFICATION-DATAVERSION: 1. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseNotificationDataStep#warn] Notification data version check complete: no upgrade needed. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseNotificationDataStep#warn] Database notification data check complete. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseOtherStep#warn] Beginning database other upgrades check. 2016-01-18 11:56:41-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseOtherStep#warn] Database other upgrades check complete. ^C2016-01-18 12:03:09-0600 [-] (UNIX Port '/Library/CalDAV/logs/caldavd.sock' Closed)
Hi Jacques, --On January 17, 2016 at 2:27:56 PM -0600 Jacques Distler <distler@golem.ph.utexas.edu> wrote:
Does anything show up in the various log files calendarserver outputs too?
Nope. access.log shows only the server starting up (and, when I hit ^C, shuttung down):
Log opened - server start: [Sun Jan 17 14:16:53 2016]. Log closed - server stop: [Sun Jan 17 14:18:35 2016].
error.log shows nothing.
A little more playing around (adding debug messages in appropriate-looking places), it seems that it gets as far as running UpgradeReleaseLockStep (in txdav.common.datastore.upgrade.sql.upgrade). But no further than that.
Can you set the "DefaultLogLevel" key to "debug" on the plist config you are using and then try a bin/run again and attach the result from the error.log file? -- Cyrus Daboo
On Jan 19, 2016, at 10:30 AM, Cyrus Daboo <cdaboo@apple.com> wrote:
Can you set the "DefaultLogLevel" key to "debug" on the plist config you are using and then try a bin/run again and attach the result from the error.log file?
Here is the error.log, with DefaultLogLevel set to "debug". As you can see, after the database checks, nothing happens ... till I kill the server. 2016-01-19 10:44:23-0600 [-] Log opened. 2016-01-19 10:44:23-0600 [-] [twisted.application.app#info] twistd 15.2.1 (/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/bin/python 2.7.11) starting up. 2016-01-19 10:44:23-0600 [-] [twisted.application.app#info] reactor class: twisted.internet.selectreactor.SelectReactor. 2016-01-19 10:44:23-0600 [-] ControlSocket starting on '/Library/CalDAV/logs/caldavd.sock' 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Beginning database schema check. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Required database key VERSION: 58. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Actual database key VERSION: 58. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Schema version check complete: no upgrade needed. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Database schema check complete. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Beginning database addressbook data check. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Required database key ADDRESSBOOK-DATAVERSION: 2. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Actual database key ADDRESSBOOK-DATAVERSION: 2. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Addressbook data version check complete: no upgrade needed. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseAddressBookDataStep#warn] Database addressbook data check complete. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] Beginning database calendar data check. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] Required database key CALENDAR-DATAVERSION: 6. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] Actual database key CALENDAR-DATAVERSION: 6. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] Calendar data version check complete: no upgrade needed. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseCalendarDataStep#warn] Database calendar data check complete. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseNotificationDataStep#warn] Beginning database notification data check. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseNotificationDataStep#warn] Required database key NOTIFICATION-DATAVERSION: 1. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseNotificationDataStep#warn] Actual database key NOTIFICATION-DATAVERSION: 1. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseNotificationDataStep#warn] Notification data version check complete: no upgrade needed. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseNotificationDataStep#warn] Database notification data check complete. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseOtherStep#warn] Beginning database other upgrades check. 2016-01-19 10:44:23-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseOtherStep#warn] Database other upgrades check complete. 2016-01-19 10:49:22-0600 [-] [twisted.internet.base#info] Received SIGTERM, shutting down. 2016-01-19 10:49:22-0600 [-] [memcached-Default] Signal handled: Terminated: 15. 2016-01-19 10:49:22-0600 [-] (UNIX Port '/Library/CalDAV/logs/caldavd.sock' Closed) 2016-01-19 10:49:22-0600 [-] [twisted.internet.base#info] Main loop terminated. 2016-01-19 10:49:22-0600 [-] [twisted.application.app#info] Server Shut Down.
Hi Jacques, --On January 19, 2016 at 10:53:14 AM -0600 Jacques Distler <distler@golem.ph.utexas.edu> wrote:
Here is the error.log, with DefaultLogLevel set to "debug". As you can see, after the database checks, nothing happens ... till I kill the server.
When it hangs what processes do you see running? There should be at least one python process and some postgres ones. Can you tell if the python process is idle or consuming CPU? -- Cyrus Daboo
On Jan 20, 2016, at 3:25 PM, Cyrus Daboo <cdaboo@apple.com> wrote:
Hi Jacques,
--On January 19, 2016 at 10:53:14 AM -0600 Jacques Distler <distler@golem.ph.utexas.edu> wrote:
Here is the error.log, with DefaultLogLevel set to "debug". As you can see, after the database checks, nothing happens ... till I kill the server.
When it hangs what processes do you see running? There should be at least one python process and some postgres ones. Can you tell if the python process is idle or consuming CPU?
Here are the processes initiated when the CalendarServer starts up (PostgreSQL is already running): PID TTY TIME CMD 70038 ttys000 0:01.85 CalendarServer 7.0 [Combined] 70135 ttys000 0:00.02 /usr/local/bin/memcached -U 0 -s /var/run/caldav/memcache.sock -u _calendar 70136 ?? 0:00.01 postgres: caldav caldav 127.0.0.1(56199) idle There's a database connection, about which "lsof -i" reports: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME python2.7 70038 root 9u IPv4 0x22e34989d8c573db 0t0 TCP localhost:56199->localhost:postgresql (ESTABLISHED) That's the only TCP/IP connection the CalendarServer makes (in particular, it HAS NOT started a listener on port 8443, as it should). top says that the none of the three processes is consuming any CPU: PID COMMAND %CPU TIME #TH #WQ #PORT #MREGS MEM RPRVT PURG CMPR VPRVT VSIZE PGRP PPID STATE UID FAULTS COW MSGS MSGR 70038 python2.7 0.0 00:01.84 2 0 20 386 80M 80M 0B 0B 130M 2498M 70034 70034 sleeping 0 42899 2524 72 30 70135 memcached 0.0 00:00.02 6 0 24 47 780K 612K 0B 0B 31M 2399M 70034 70038 sleeping 93 956 270 34 12 70136 postgres 0.0 00:00.00 1 0 7 61 2512K 1172K 0B 0B 25M 2587M 70136 124 sleeping 252 1369 61 8 4
On the other hand, starting up the server with bin/run -n -t Slave gets a lot further.
On Jan 20, 2016, at 3:57 PM, Jacques Distler <distler@golem.ph.utexas.edu> wrote:
Here are the processes initiated when the CalendarServer starts up (PostgreSQL is already running):
PID TTY TIME CMD 70038 ttys000 0:01.85 CalendarServer 7.0 [Combined] 70135 ttys000 0:00.02 /usr/local/bin/memcached -U 0 -s /var/run/caldav/memcache.sock -u _calendar 70136 ?? 0:00.01 postgres: caldav caldav 127.0.0.1(56199) idle
Now, 44308 ttys000 0:01.46 CalendarServer 7.0 [Slave] (n.b.: no memcached started)
There's a database connection, about which "lsof -i" reports:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME python2.7 70038 root 9u IPv4 0x22e34989d8c573db 0t0 TCP localhost:56199->localhost:postgresql (ESTABLISHED)
Now it binds listeners to port 8443: python2.7 44308 root 3u IPv4 0x22e34989eb57dbc3 0t0 TCP *:pcsync-https (LISTEN) python2.7 44308 root 4u IPv6 0x22e34989eb58a33b 0t0 TCP *:pcsync-https (LISTEN) python2.7 44308 root 13u IPv4 0x22e34989ed97b3db 0t0 TCP localhost:51681->localhost:postgresql (ESTABLISHED)
That's the only TCP/IP connection the CalendarServer makes (in particular, it HAS NOT started a listener on port 8443, as it should).
But, of course, while the resulting Slave Server responds to requests, it always returns an error: 2016-01-23 13:18:53-0600 [HTTPChannel,0,nn.nn.nn.nn] [txweb2.server#info] GET /principals/ HTTP/1.1 2016-01-23 13:18:53-0600 [HTTPChannel,0,nn.nn.nn.nn] [txdav.who.cache#debug] Directory cache miss: shortName ('user', 'distler') 2016-01-23 13:18:53-0600 [HTTPChannel,0,,nn.nn.nn.nn] [txdav.dps.client#debug] Creating connection 2016-01-23 13:18:53-0600 [-] [txweb2.server#error] Exception rendering request: <GET /principals/ (1, 1)> Traceback (most recent call last): Failure: twisted.internet.error.ConnectError: An error occurred while connecting: 2: No such file or directory. Still, this seems like progress ... Jacques
On the other hand, starting up the server with bin/run -n -t Slave gets a lot further. And, just to complete the trilogy, bin/run -n -t Single gets further than bin/run -n but not far enough to actually listen on port 8443: Using /usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/bin/python as Python Starting server... Reading configuration from file: /usr/local/CalDAV-7.0/CalendarServer/conf/caldavd-dev.plist 2016-01-23 19:43:48-0600 [-] Log opened. 2016-01-23 19:43:48-0600 [-] [twisted.application.app#info] twistd 15.2.1 (/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/bin/python 2.7.11) starting up. 2016-01-23 19:43:48-0600 [-] [twisted.application.app#info] reactor class: twisted.internet.selectreactor.SelectReactor. 2016-01-23 19:43:48-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Beginning database schema check. ... [skip over the database upgrade checks] 2016-01-23 19:43:48-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseOtherStep#warn] Database other upgrades check complete. 2016-01-23 19:43:48-0600 [-] [calendarserver.tap.caldav.CalDAVServiceMaker#info] Setting up service 2016-01-23 19:43:48-0600 [-] [calendarserver.tap.caldav.CalDAVServiceMaker#info] Configuring access log observer: <calendarserver.accesslog.RotatingFileAccessLoggingObserver object at 0x107181f90> ^C Signal handled: Interrupt: 2. 2016-01-23 19:46:06-0600 [-] [twisted.internet.base#info] Received SIGINT, shutting down. 2016-01-23 19:46:06-0600 [-] [twisted.internet.base#info] Main loop terminated. 2016-01-23 19:46:06-0600 [-] [twisted.application.app#info] Server Shut Down.
Hi Jacques, --On January 23, 2016 at 8:13:57 PM -0600 Jacques Distler <distler@golem.ph.utexas.edu> wrote:
On the other hand, starting up the server with
bin/run -n -t Slave
gets a lot further.
And, just to complete the trilogy,
bin/run -n -t Single
gets further than
bin/run -n
but not far enough to actually listen on port 8443:
-t Slave is not meant for normal operation. I wonder if you have a permissions issue. Have you tried running it via sudo? Have you tried installing directly from our latest svn trunk into a separate directory with a clean DB? -- Cyrus Daboo
On Jan 25, 2016, at 8:57 AM, Cyrus Daboo <cdaboo@apple.com> wrote:
-t Slave is not meant for normal operation.
I realize that. But it has the advantage of skipping the database checks and (apparently) succeeds in binding to Port 8443. Neither of the other two modes get that far.
I wonder if you have a permissions issue. Have you tried running it via sudo?
I've tried both 'sudo' and running directly as root ( via 'su'). The result is the same. The other difference, which I should have noted, is that "-t Slave" successfully drops privileges (so that "lsof -i" lists the processes as running under the user _calendar), whereas "-t Combined" and "-t Single" are still shown as running as root.
Have you tried installing directly from our latest svn trunk into a separate directory with a clean DB?
Haven't tried that yet.
On Jan 25, 2016, at 9:43 AM, Jacques Distler <distler@golem.ph.utexas.edu> wrote:
Have you tried installing directly from our latest svn trunk into a separate directory with a clean DB?
Haven't tried that yet.
Trying it was something of a washout. Trunk does not compile on MacOSX 10.9. (You probably knew that already.) Installing a fresh copy of CalendarServer 7.0, into a separate directory with a clean DB, had a (to me) surprising result. sudo bin/run -n failed to initialize the database. ============== Using /usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/bin/python as Python Starting server... Reading configuration from file: /usr/local/CalDAV-7.0/CalendarServer/conf/caldavd-dev.plist 2016-01-26 02:39:48-0600 [-] Log opened. 2016-01-26 02:39:48-0600 [-] [twisted.application.app#info] twistd 15.2.1 (/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/bin/python 2.7.11) starting up. 2016-01-26 02:39:48-0600 [-] [twisted.application.app#info] reactor class: twisted.internet.selectreactor.SelectReactor. 2016-01-26 02:39:48-0600 [-] ControlSocket starting on '/Library/CalDAV/logs/caldavd.sock' 2016-01-26 02:39:48-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Beginning database schema check. 2016-01-26 02:39:48-0600 [-] [txdav.common.datastore.upgrade.sql.upgrade.UpgradeDatabaseSchemaStep#warn] Required database key VERSION: 58. 2016-01-26 02:39:48-0600 [-] Exception from execute() on first statement in transaction. Possibly caused by a database server restart. Automatically reconnecting now. Traceback (most recent call last): File "/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/src/twextpy/twext/internet/threadutils.py", lne 48, in _run while self._qpull(): File "/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/src/twextpy/twext/internet/threadutils.py", line 68, in _qpull self._oneWorkUnit(*work) File "/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/src/twextpy/twext/internet/threadutils.py", line 74, in _oneWorkUnit result = instruction() File "/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/src/twextpy/twext/enterprise/adbapi2.py", line 322, in <lambda> lambda: self._reallyExecSQL(*args, **kw) --- <exception caught here> --- File "/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/src/twextpy/twext/enterprise/adbapi2.py", line 246, in _reallyExecSQL self._cursor.execute(sql, args) File "/usr/local/CalDAV-7.0/CalendarServer/txdav/base/datastore/dbapiclient.py", line 83, in execute self.realCursor.execute(sql, args) File "/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/lib/python2.7/site-packages/pg8000/core.py", line 910, in execute self._c.execute(self, operation, args) File "/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/lib/python2.7/site-packages/pg8000/core.py", line 1969, in execute self.handle_messages(cursor) File "/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/lib/python2.7/site-packages/pg8000/core.py", line 2117, in handle_messages raise self.error pg8000.core.ProgrammingError: (u'ERROR', u'42P01', u'relation "calendarserver" does not exist', u'19', u'parse_relation.c', u'1156', u'parserOpenTable', u'', u'') 2016-01-26 02:39:48-0600 [-] [calendarserver.tap.util#error] Step failure Traceback (most recent call last): ... [lots of similar messages] File "/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/lib/python2.7/site-packages/pg8000/core.py", line 1969, in execute self.handle_messages(cursor) File "/usr/local/CalDAV-7.0/CalendarServer/.develop/virtualenv/lib/python2.7/site-packages/pg8000/core.py", line 2117, in handle_messages raise self.error pg8000.core.ProgrammingError: (u'ERROR', u'42P01', u'relation "calendarserver" does not exist', u'19', u'parse_relation.c', u'1156', u'parserOpenTable', u'', u'') 2016-01-26 02:39:48-0600 [-] [calendarserver.tap.caldav#error] Data store not available; shutting down 2016-01-26 02:39:48-0600 [-] [memcached-Default] Signal handled: Terminated: 15. 2016-01-26 02:39:48-0600 [-] (UNIX Port '/Library/CalDAV/logs/caldavd.sock' Closed) 2016-01-26 02:39:48-0600 [-] [twisted.internet.base#info] Main loop terminated. 2016-01-26 02:39:48-0600 [-] [twisted.application.app#info] Server Shut Down. ============= This seems very wrong to me. Perhaps it is relevant that the running PostgreSQL is version 9.5 (rather than the v. 9.3) assumed by CalendarServer? N.B.: PostgreSQL 9.5 worked just fine with CalendarServer 5.3.
participants (2)
-
Cyrus Daboo
-
Jacques Distler