Server Update v3.1.1: How does one get past the Updating Services screen: "The server is being updated on this Mac"?

That can reportedly take a while. Try letting that run overnight, if you can. (On a fairly clean test install of OS X Server locally, that part of the upgrade took several hour. There wasn't much data in that configuration, either.)

Same here… Even after 2 days it keeps hanging, still showing the progress bar at 1/3…

In the system.log I see this messages every 5 secs "com.apple.DeveiceManagement.postgres" Throttling respawn: Will start in 5 seconds.

Forced quit Server.app, delete Server.app and redownload > same problem.

I think I'm goig to try this later on today: http://krypted.com/mac-os-x-server/unresponsive-server-after-mavericks-upgrade-r eset-server-app/

I hope that most of my settings are kept.

I'lll post the result here.

Result: This doesn't help because that file does not exist yet (of course).

rm: /var/db/.ServerSetupDone: No such file or directory

Because this file does not exist the Server.app does it's "Updating Services" and after a successful "Updating Services" the .ServerSetupDone file gets recreated.

so no solution yet…

When I google for the

com.apple.DeveiceManagement.postgres - Throttling respawn: Will start in 5 seconds.

I get way too many results. Haven't found something helpful yet because most of the solutions mentioned are issues with the postgres daemon/database 'after' starting this daemon, but in this case this daemon doesn't get started at all.

Following the discussion on "https://discussions.apple.com/thread/5663262?answerId=24122772022#24122772022" I checked the ServerSetup.log for any issues.

The only thing in the log that was marked 'not succesful' is the postgres failing to start…

ServerSetup.log: … received postgres stderr pg_ctl: could not start server

When I google for this one I don't get any solutions in combination with the OS X platform. And I'm not a postgres specialist…

I think I'm going to completely reset the server and reinstall Server.app following the guidelines in this article: http://support.apple.com/kb/TS5237

-update-

Did not yet completely reset the server. (It's not mine… it's from a customer so completely resetting the server is really the last thing he wants to be done…)

but I've digged deeper into the problem and the logs.

Test: renaming the .plist files mentioned in the arcticle about resetting the server

• /Library/Preferences/com.apple.serverd.plist > /Library/Preferences/com.apple.serverd-old.plist
• /Library/Preferences/com.apple.servermgrd.plist > /Library/Preferences/com.apple.servermgrd-old.plist

This triggers also a 'new setup' from the server instead of 'updating services'.

And even now the configuration of the server halted on the same place in the logs!

It's always in the part with 70_calendarcommonextra.py

path: /Applications/Server.app/Contents/ServerRoot/System/Library/ServerSetup/CommonE xtras/70_calendarcommonextra.py

…

…

2014-04-16 11:36:42+0100 Requesting postgres start via /Applications/Server.app/Contents/ServerRoot/usr/bin/xpg_ctl

2014-04-16 11:36:42+0100 received postgres stdout '2014-04-16 11:36:42 XPG.32230: Executing pg_ctl [\'/Applications/Server.app/Contents/ServerRoot/usr/bin/pg_ctl\', \'-p\', \'/Applications/Server.app/Contents/ServerRoot/usr/bin/xpostgres\', \'start\', \'-l\', \'/var/log/caldavd/xpg_ctl.log\', \'-w\', \'-o\', "-c listen_addresses=\'\' -k \'/var/run/caldavd/PostgresSocket\' -c shared_buffers=105 -c max_connections=70 -c standard_conforming_strings=on -c unix_socket_permissions=0770 -c log_lock_waits=TRUE -c deadlock_timeout=10 -c log_line_prefix=\'%m [%p] \' -c logging_collector=on -c log_truncate_on_rotation=on -c log_directory=/var/log/caldavd/postgresql -c log_filename=postgresql_%w.log -c log_rotation_age=1440"]\n2014-04-16 11:36:42 XPG.32230: Spawning... [\'/Applications/Server.app/Contents/ServerRoot/usr/bin/pg_ctl\', \'-p\', \'/Applications/Server.app/Contents/ServerRoot/usr/bin/xpostgres\', \'start\', \'-l\', \'/var/log/caldavd/xpg_ctl.log\', \'-w\', \'-o\', "-c listen_addresses=\'\' -k \'/var/run/caldavd/PostgresSocket\' -c shared_buffers=105 -c max_connections=70 -c standard_conforming_strings=on -c unix_socket_permissions=0770 -c log_lock_waits=TRUE -c deadlock_timeout=10 -c log_line_prefix=\'%m [%p] \' -c logging_collector=on -c log_truncate_on_rotation=on -c log_directory=/var/log/caldavd/postgresql -c log_filename=postgresql_%w.log -c log_rotation_age=1440"]\n'

2014-04-16 11:36:42+0100 received postgres stdout 'waiting for server to start....'

2014-04-16 11:36:43+0100 received postgres stdout '.'

2014-04-16 11:36:44+0100 received postgres stdout '.'

2014-04-16 11:36:45+0100 received postgres stdout '.'

2014-04-16 11:36:46+0100 received postgres stdout '.'

2014-04-16 11:36:47+0100 received postgres stderr pg_ctl: could not start server

and then some lines below

calendarcommonextra: Apr 16 11:36:48 Service was not previous enabled

and the it stops, and keeps waiting forever…

Then I've tried to expermiment a little bit in the /Library/Server folder with renaming some folder to see if thsi could solve the problem. (Because the folders are getting recreated with default settings and data). So I've renamed "Calendar and Contacts" and tested: No success. I've renamed "PostgreSQL" and tested: No success. …

When I read some articles about these problems most of the time the problem seems to be related to some 3th party from specific software is installed, like when someone installed another version of Python instead of using Apple's. The upgrade process does not seem to like this and freezes.

A quick look in the Downloads folder of this specific server showed an installer of pgAdmin, used to configre/control PostGreSQL databases… so -in this case- this was installed by another external company to do somehting on that server which I don't know what it does 😟.

But for now, I've pinpointed the problem. The original PostGreS of OS X Server on this server is tampered/overwritten by another PostGreSQL and this will be the reason why the update does not work.

I have to phone that other company next week to see if they are aware of this issue, and hopefully they know how to fix this.

---

bottom line

reading the ServerSetup.log is the first thing to do!