On the other hand, starting up the server with bin/run -n -t Slave gets a lot further.
On Jan 20, 2016, at 3:57 PM, Jacques Distler <distler@golem.ph.utexas.edu> wrote:
Here are the processes initiated when the CalendarServer starts up (PostgreSQL is already running):
PID TTY TIME CMD 70038 ttys000 0:01.85 CalendarServer 7.0 [Combined] 70135 ttys000 0:00.02 /usr/local/bin/memcached -U 0 -s /var/run/caldav/memcache.sock -u _calendar 70136 ?? 0:00.01 postgres: caldav caldav 127.0.0.1(56199) idle
Now, 44308 ttys000 0:01.46 CalendarServer 7.0 [Slave] (n.b.: no memcached started)
There's a database connection, about which "lsof -i" reports:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME python2.7 70038 root 9u IPv4 0x22e34989d8c573db 0t0 TCP localhost:56199->localhost:postgresql (ESTABLISHED)
Now it binds listeners to port 8443: python2.7 44308 root 3u IPv4 0x22e34989eb57dbc3 0t0 TCP *:pcsync-https (LISTEN) python2.7 44308 root 4u IPv6 0x22e34989eb58a33b 0t0 TCP *:pcsync-https (LISTEN) python2.7 44308 root 13u IPv4 0x22e34989ed97b3db 0t0 TCP localhost:51681->localhost:postgresql (ESTABLISHED)
That's the only TCP/IP connection the CalendarServer makes (in particular, it HAS NOT started a listener on port 8443, as it should).
But, of course, while the resulting Slave Server responds to requests, it always returns an error: 2016-01-23 13:18:53-0600 [HTTPChannel,0,nn.nn.nn.nn] [txweb2.server#info] GET /principals/ HTTP/1.1 2016-01-23 13:18:53-0600 [HTTPChannel,0,nn.nn.nn.nn] [txdav.who.cache#debug] Directory cache miss: shortName ('user', 'distler') 2016-01-23 13:18:53-0600 [HTTPChannel,0,,nn.nn.nn.nn] [txdav.dps.client#debug] Creating connection 2016-01-23 13:18:53-0600 [-] [txweb2.server#error] Exception rendering request: <GET /principals/ (1, 1)> Traceback (most recent call last): Failure: twisted.internet.error.ConnectError: An error occurred while connecting: 2: No such file or directory. Still, this seems like progress ... Jacques