Applied Security Update 2014-001 recently to 10.7.5 Server (on this server I’m behind on purpose.)  First time through it stalled on reboot and killed the network user database.  Thought it wasn’t the update’s fault since I had a failing external backup drive I was replacing.  Restored from secondary backup and ran the update again.  This time it appeared to work – mail was coming in, sharepoints working, etc.

I found it actually had trashed the postgres db dealing with calendar and contacts.  The error messages received on the client side were “the server is not responding” and the old “CalDAVAccountRefreshQueueableOperation” error.  The port wasn’t open, which was because the service wasn’t starting.  Errors in the server logs were varied.  For example /Library/Logs/PostgreSQL/PostgreSQL.log was showing (date & time removed since it won’t match any search terms anyway):

LOG:  connection received: host=[local]
LOG:  connection authorized: user=caldav database=caldav
FATAL:  role “caldav” does not exist

In case you run into these errors first verify you have the same issue by checking for the caldav database in postgres:

sudo -u calendar psql -U _postgres caldav

If you receive

psql: FATAL:  database “caldav” does not exist

then you have the same problem.  If you are dropped into a caldav prompt after it lists the psql version, then this is not your exact problem.

– Verify there is a /var/pgsql.pre-restore-[something] folder in /var/.  Without it this guide is worthless.
– Open Server.app and shut down all services.
– Perform the following steps:
sudo serveradmin stop postgres
sudo mv /var/pgsql /var/pgsql.broken
—Use tab to autocomplete the part in brackets below.—
sudo cp -Rp /var/pgsql.pre-restore-[my .pre-restore file] /var/pgsql
sudo serveradmin start postgres

– Check permission to make sure _postgres is both the user and group.  If not run this:
chown -R _postgres:_postgres /var/pgsql

– Verify it works by running:
sudo -u _postgres psql -U caldav

– Open Server.app and start all previously running services.

I manage a healthy number of servers, and this does not happen on all of them.  However it does happen to other people as targeted searches indicate, so I’m inclined to believe certain OS versions shipped with a bug that causes this.  I’ve run into something similar with the 10.7.3 combo update, but none of the rest of my 10.7.x servers have this issue.  They also came with different versions of OS X, though that’s a guess based on timing and not hard data.  If you’ve had this bug occur, it will probably occur again and I urge you to make a bootable clone after shutting down services prior to running security updates (there will be no more combo updates for 10.7.5, obviously.)

When it’s time to upgrade I will be starting from scratch in order to avoid migrating this bug, and I suggest you do the same!