[CalendarServer-users] Running CalendarServer on Mac OS X 10.8.5

[Bernhard Spinnler]

On 08.11.2013, at 00:15, Andre LaBranche <dre at apple.com> wrote:

> Hi,
> 
> It does indeed appear that run -i is still broken.
> 
> Even so, it's fine to just run the service in place, using the run script. Normally doing something like this would be a mess of fixing up environment variables and adding things to various paths, but our run script does this for you, no matter where you execute it from. I might recommend creating another user account to run the service, to isolate it from your own personal login session. It doesn't need to run as root.
> 
> For example:
> 
> andre at xomg[~] /Users/andre/work/icalserver/trunk/CalendarServer/run -n 
> Using system version of memcached.
> 
> Using system version of OpenLDAP.
> 
> Using system version of libffi.
> 
> Using system version of setuptools.
> 
> Unable to determine version for zope.interface.
> Using system version of pyOpenSSL.
> 
> Using system version of xattr.
> 
> Using system version of Twisted.
> 
> Using system version of python-dateutil.
> 
> Using system version of pytz.
> 
> Using python2.7 as Python
> 
> Starting server...
> Reading configuration from file: /Volumes/xomg/Users/andre/work/icalserver/trunk/CalendarServer/conf/caldavd-dev.plist
> 2013-11-07 14:56:41-0800 [-] Log opened.
> 2013-11-07 14:56:41-0800 [-] [twisted.application.app#info] twistd 12.2.0 (/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python 2.7.5) starting up.
> …
> 

I'm fine with running the service in place. Just thought I install it since it was recommended in the comment at the top of ./run itself. Also, so far I missed the switch -n and setup kicked in with every start, updated code from remote repositories, compiled and so on. I didn't want that. Thanks for the tip!

BTW: ./run -I chokes on the same error ./run -i does. ./run -b completes successfully, but when I start caldavd twisted fails for some reason. I could provide details in case of interest. For now I will just ./run -n in place.

> 
> You can integrate this with launchd as well; just make sure to not pass the -d option with run. One side effect of using run without -d is that no separate error.log is written; instead all that content goes to stdout. To get a separate error.log file, define StandardOutPath and StandardErrorPath in your launchd plist, with the desired path to the log file.

Cool. Will do that when I'm comfortable with my current manual setup.

Thanks again. Appreciate it.
	Bernhard