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

Question

Upon opening Server after the update has installed, it simply hangs for hours on end (more than 5 hours) on the above screen, with the progress bar showing about 1/3 complete. Please help!

Answer 1

-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!