Calendar Server crashes in Yosemite 10.10 with Server App 4.0

I am running an OS X Server (4.0) in Yosemite 10.10 locally on my iMac to provide calendars in our house. Since the combined update of OS and the "Server App" the calendar server crashes frequently. It restarts when I run the server app but crashes again a couple of minutes later.


Error log is below, I hope someone has an idea.


Thanks,


shoot_me


2014-10-22 21:34:15+0200 [-] Exception from execute() on first statement in transaction. Possibly caused by a database server restart. Automatically reconnecting now.

Traceback (most recent call last):

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/twext/internet/threadutils.py", line 48, in _run

while self._qpull():

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/twext/internet/threadutils.py", line 68, in _qpull

self._oneWorkUnit(*work)

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/twext/internet/threadutils.py", line 74, in _oneWorkUnit

result = instruction()

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/twext/enterprise/adbapi2.py", line 312, in <lambda>

lambda: self._reallyExecSQL(*args, **kw)

--- <exception caught here> ---

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/twext/enterprise/adbapi2.py", line 242, in _reallyExecSQL

self._cursor.execute(sql, args)

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/txdav/base/datastore/dbapiclient.py", line 77, in execute

self.realCursor.execute(sql, args)

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/pgdb.py", line 323, in execute

return self.executemany(operation, [params])

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/pgdb.py", line 342, in executemany

raise _op_error("can't start transaction")

pg.OperationalError: can't start transaction

2014-10-22 21:34:15+0200 [-] [twext.enterprise.jobqueue#error] Failed to pick a new job, FATAL: the database system is shutting down

2014-10-22 21:34:15+0200 [-] Unhandled Error

Traceback (most recent call last):

File "/System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/twi sted/python/context.py", line 81, in callWithContext

return func(*args,**kw)

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/twext/internet/threadutils.py", line 48, in _run

while self._qpull():

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/twext/internet/threadutils.py", line 69, in _qpull

return True

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/twext/internet/threadutils.py", line 82, in _oneWorkUnit

self._reactor.callFromThread(deferred.callback, result)

--- <exception caught here> ---

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/twext/internet/threadutils.py", line 74, in _oneWorkUnit

result = instruction()

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/twext/enterprise/adbapi2.py", line 352, in reallySomething

really()

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/txdav/base/datastore/dbapiclient.py", line 176, in rollback

self.realConnection.rollback()

File "/Applications/Server.app/Contents/ServerRoot/Library/CalendarServer/lib/python 2.7/site-packages/pgdb.py", line 521, in rollback

raise _op_error("connection has been closed")

pg.OperationalError: connection has been closed

Posted on Oct 22, 2014 1:00 PM

Reply
11 replies

Oct 22, 2014 6:00 PM in response to shoot_me

Looks like a corrupt database. I suggest you export all calendars on the clients, then delete /Library/Server/Wiki/Data and reinitialize the server.

Back up all data.

Quit the Server application and drag it to the Trash, but don't empty. You'll be prompted to confirm that you want to stop all services. You won't lose any data.

If you're using the server for DNS, temporarily change the primary DNS setting in the Network preference pane to your ISP's DNS.

Put the app back where it was and launch it. Test.

Revert the DNS setting, if applicable.

Jan 7, 2015 3:17 AM in response to Linc Davis

Hi Linc,


we see here the same problem like user shoot_me reports and we came from a perfectly running calendar server setup on Mavericks Server. Our installation hosts over 170 calendar accounts and multiple delegated calendars with either write or just read proxy settings. Your solution is certainly no solution in this scenario. There is a bug inside the implementation of CalDAV or the migration corrupted the database if we follow your logic. Both is very bad and shouldn't happen at all.


Alex

Nov 4, 2015 11:47 AM in response to _morgen__

after much test


the differences between version (3,4) and the last version 5 are:


- the delegations/proxies makes with terminal (command: calendar server_manage_principals) require a restart of calendar service for that they applies

BUG or not BUG?

=> version 3 and 4 don't require a restart service / However the proxies makes with ical client doesn't require restart services in ever versions.


- The proxies makes with ldap groups ignore the groups in groups contrary with version server 3


- remove the proxies.sqlite file in version 4 permit purge proxies before migration, thanks morgen


If i have more info, I shall communicate them

Nov 4, 2015 12:18 PM in response to ACSEA

new info: When you modify a proxy with terminal (calendar server_manage_principals), calendar service not purge the old proxy if it exist.


EXAMPLE

srv-ical:~ root# calendarserver_manage_principals --add-read-proxy users:user1 users:user2

Added "user1" 9B67E86E-36CA-4DD8-8311-598C34AE421F (user) user1 as a read proxy for "user2" 455518F1-919C-43A6-8F51-680D3F6B8567 (user) user2


^[[Asrv-ical:~ root# calendarserver_manage_principals --list-proxies users:user2

Read-only proxies for "user2" 455518F1-919C-43A6-8F51-680D3F6B8567 (user) user2:

Full name Type UID Short names

--------- ---- --- -----------

user1 user1 9B67E86E-36CA-4DD8-8311-598C34AE421F user1


No write proxies for "user2" 455518F1-919C-43A6-8F51-680D3F6B8567 (user) user2


srv-ical:~ root# calendarserver_manage_principals --add-write-proxy users:user1 users:user2

Added "user1" 9B67E86E-36CA-4DD8-8311-598C34AE421F (user) user1 as a read proxy for "user2" 455518F1-919C-43A6-8F51-680D3F6B8567 (user) user2


^[[Asrv-ical:~ root# calendarserver_manage_principals --list-proxies users:user2

Read-only proxies for "user2" 455518F1-919C-43A6-8F51-680D3F6B8567 (user) user2:

Full name Type UID Short names

--------- ---- --- -----------

user1 user1 9B67E86E-36CA-4DD8-8311-598C34AE421F user1


Write-only proxies for "user2" 455518F1-919C-43A6-8F51-680D3F6B8567 (user) user2:

Full name Type UID Short names

--------- ---- --- -----------

user1 user1 9B67E86E-36CA-4DD8-8311-598C34AE421F user1



the read proxy for user1 is not removed when i add a write proxy for user1 contrary with version 3, the double Can cause a bug in ical client.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Calendar Server crashes in Yosemite 10.10 with Server App 4.0

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.